Wiemy, że potrzeba dopracowanej usługi by klienci ją naprawdę pokochali. Dlatego w Angry Bytes oferujemy drobiazgowe konsultacje dla startupów, które pomogą zbudować solidne techniczne fundamenty. Przez ostatnie lata wielokrotnie udowodniliśmy, że jesteśmy w stanie włączyć się w proces na dowolnym etapie. Czasem włączamy się na etapie Proof of Concept, by przygotować solidną infrastrukturę tuż przed rozmowami z inwestorem, czasem to inwestorzy sugerują, by poprosić nas o pomoc – głównie, gdy trzeba zacząć skalować biznes.

Niestety, wiemy też, że większość założycieli uważa, że na samym początku nie muszą planować infrastruktury IT długoterminowo. Zazwyczaj rozbudowują istniejącą infrastrukturę wraz z rosnącymi potrzebami, często bez udziału administratora serwerów, zrzucając to na ramiona programistów. Z czasem okazuje się, że taki twór nie działa sprawnie i ogranicza możliwość rozwoju. Wtedy warto sięgnąć po profesjonalną optymalizację infrastruktury, tak by nie marnować żadnych zasobów.

Jak wygląda rozpoczęcie współpracy?

 

  1. Startup odzywa się do nas ze swoimi pomysłami, zazwyczaj na rundzie finansowania seed, kiedy potrzebują wsparcia technologicznego by zbudować PoC lub MVP.
  2. Przygotowujemy wstępny projekt architektury serwerowej na potrzeby środowisk developerskich i produkcyjnych.
  3. Uruchamiamy środowisko CI/CD przy użyciu Terraforma, Kubernetes, Jenkinsa i Ansibla.
  4. Przygotowujemy dogłębny monitoring środowiska, przy użyciu Zabbixa, Datadoga, Sentry, ELK i Prometheusa z Grafaną.
  5. Wspieramy też w optymalizowaniu dotychczasowej infrastruktury IT – wykonujemy audyt, który pozwoli nam znaleźć wąskie gardła.
Etap 1: doprecyzowanie pomysłu

Masz pomysł i masz zapewnione finansowanie. Pytanie, czy Twój zespół ma wystarczające kwalifikacje, by dostarczyć produkt. Jeśli nie, to zostają Ci dwie opcje – albo zatrudnić brakujące osoby, albo zgłosić się do firmy outsourcingowej, by zapewniła potrzebne wsparcie. Pierwsza opcja zapewnia większą kontrolę, ale znalezienie odpowiednich osób może być trudne i nieopłacalne, my natomiast mamy kilkanaście lat doświadczenia przy tworzeniu MVP dla różnych branż i jesteśmy w stanie przewidzieć kiedy wystąpią problemy, zanim w ogóle pomyślisz, że coś takiego może mieć miejsce

Etap 2: budowanie infrastruktury

Gdy mamy już zebrane wszystkie cele biznesowe naszego klienta I jego oczekiwania, sporządzamy listę rzeczy które będą niezbędne do osiągnięcia celu. Czasem wykorzystujemy infrastrukturę, która już była u klienta i wystarczy tylko nieco poprawić konfigurację, ale znacznie częściej sugeruję oranie wszystkiego do zera – włącznie z wymianą starych, kilku(nasto) letnich maszyn. Szczególnie, że zawsze staramy się dążyć do możliwie dużej energooszczędności na standby i dużej mocy obliczeniowej gdy jest potrzebna.

We do it by following the IaC (Infrastructure as Code) concept, where all environment settings are codified in Terraform and Kubernetes manifests, stored within the Version Control System. This means that any environment can be easily and automatically provisioned when the need arises.

Etap 3: Konfiguracja pipeline’ów CI/CD

Zautomatyzowanie rutynowych zadań jest niezbędne, jeśli chcesz przyśpieszyć dostarczenie produktu na rynek. Pozwoli Ci też zaoszczędzić wydatki, które przeznaczasz na infrastrukturę IT i pensje pracowników, robiących rutynowe, powtarzalne rzeczy, zamiast rozwoju produktu. Pipeline CI/CD są procesami i przepływami pracy, które umożliwiają programistom uruchomienie w ramach testowania kodu środowisk developerskich i testowych, bez konieczności uzyskiwania wsparcia ze strony osób odpowiedzialnych za infrastrukturę serwerową. To samo tyczy się wydawania nowych wersji i umieszczania ich na produkcji.

(CI) or Continuous Integration to praktyka tworzenia kodu w małych partiach, które nieustannie są testowane automatycznymi testami jednostkowymi i po ich zaliczeniu dodawane do głównej gałęzi kodu. W ten sposób ryzyko błędów i niekompatybilności jest zredukowane niemal do zera, a co za tym idzie czas poświęcony na usuwanie błędów jest niewielki, co pozwala na szybsze ukończenie produktu i dostarczenie go na rynek.

(CD) or Continuous Delivery to praktyka konfigurowania różnych narzędzi takich jak Circle CI, GitLab CI, Jenkins,  Ansible, Terraform i Kubernetes do wykonywania konkretnych akcji w przypadku wystąpienia ustalonych wcześniej okoliczności. Pozwala to programistom na uruchomienie środowisk developerskich i stworzenie serwerów testowych przy użyciu jednego polecenia, uruchamiając manifest Terraforma. W ten sposób proces dostarczania oprogramowania jest znacznie bardziej produktywny i mniej kosztowny czasowo. W identyczny sposób działa aktualizowanie serwerów i dostarczanie nowych funkcji — automatyzujemy wszystko co jesteśmy w stanie, wykluczając jak najbardziej czynnik ludzki.

Krok 4: Monitorowanie środowisk produkcyjnych

Gdy usługa trafia na rynek, musi być ona dokładnie monitorowana, żeby zapewnić płynne działanie w środowisku produkcyjnym. Wiemy z doświadczenia,  że istnieje bardzo dużo miejsc, często mało oczywistych, które mogą mieć wpływ na wydajność działania infrastruktury. Dlatego też przygotowaliśmy wielopoziomowy system monitoringu, który pozwala nam szybko zweryfikować przyczynę problemu.

Krok 5: Optymalizacja i wsparcie w zakresie infrastruktury IT

To również jest jeden z popularniejszych aspektów jaki pojawia się w trakcie naszego consultingu. Zazwyczaj wzrost przebiega inaczej niż się planowało i trzeba opierać się na zasobach i systemach, które się ma na miejscu. Stąd też często w razie potrzeby programista przygotowuje kolejny serwer, byleby tylko wstał do rana. Niestety, często okazuje się, że firmy korzystają ze starych, energożernych, mało wydajnych maszyn, które możnaby wymienić na znacznie tańsze i lepsze rozwiązanie.

Dlatego jednym z aspektów które poruszamy jest optymalizacja i konserwacja infrastruktury IT. Oceniamy bieżącą sytuację, identyfikujemy możliwe wąskie gardła, problemy z bezpieczeństwem i złe praktyki i wdrażamy rozwiązania, które obniżą koszt infrastruktury, a jednocześnie sprawią, że będzie bardziej wydajna i stabilna.

Krok 6: Migracja do chmury, z chmury, albo między chmurami

Niezależnie od tego, czy startup zaczynał działalność w chmurze, czy zdecydował się zmigrować do niej potem, albo z niej uciec, decyzja o zmianie dostawcy jest zawsze bardzo trudna. Trzeba wziąć pod uwagę wiele czynników, być może rozważyć całkowity redesign systemu, żeby nie przenosić obecnych problemów na nową platformę. Dlatego też zmiana dostawcy jest procesem który wymaga dogłębnego planowania i dużej wiedzy fachowej, by przeszła niezauważona.