Chmura i infrastruktura
Projektujemy, budujemy i utrzymujemy infrastrukturę, na której działają aplikacje. Stawiamy na infrastrukturę jako kod, automatyczne wdrożenia i monitoring, żeby system był przewidywalny, a koszty pod kontrolą.
Z CZYM PRZYCHODZĄ KLIENCI
- Wdrożenia są ręczne, a każde z nich to ryzyko przestoju.
- Rachunek za chmurę rośnie szybciej niż ruch w aplikacji.
- Nikt nie wie dokładnie, jak skonfigurowane są serwery, bo konfiguracja nie jest nigdzie zapisana.
- O awariach firma dowiaduje się od użytkowników, a nie z monitoringu.
- Kopie zapasowe istnieją, ale nikt nie sprawdził, czy da się z nich odtworzyć system.
ZAKRES PRAC
- Audyt obecnej infrastruktury, bezpieczeństwa i kosztów.
- Architektura w chmurze, np. AWS, dobrana do skali aplikacji.
- Konteneryzacja w Dockerze i orkiestracja w Kubernetes tam, gdzie ma to sens.
- Infrastruktura jako kod w Terraform.
- Potoki CI/CD i kontrolowany rollout nowych wersji.
- Kopie zapasowe i sprawdzona procedura odtwarzania.
- Monitoring, logi, alerty i optymalizacja kosztów.
Infrastruktura to wszystko, na czym działa aplikacja: serwery albo usługi w chmurze, bazy danych, sieć, potoki wdrożeń, kopie zapasowe i monitoring. Gdy działa dobrze, nikt o niej nie myśli. Gdy działa źle, objawia się przestojami, nieudanymi wdrożeniami i rachunkami, których nikt nie umie wyjaśnić. Projektujemy, budujemy i utrzymujemy infrastrukturę tak, żeby była przewidywalna.
01Od czego zaczynamy
Jeśli infrastruktura już istnieje, zaczynamy od audytu. Sprawdzamy, jak skonfigurowane są serwery i usługi, jak wyglądają wdrożenia, gdzie są kopie zapasowe, co jest monitorowane i na co idą pieniądze. Przy okazji przeglądamy bezpieczeństwo: dostępy, klucze, otwarte porty, aktualizacje. Najczęstsze luki zebraliśmy w artykule cloud security checklist.
Wynikiem audytu jest opis stanu obecnego i lista zmian uporządkowana według ryzyka. Część poprawek, np. brakujące alerty albo nieprzetestowane kopie zapasowe, wprowadzamy od razu. Większe zmiany planujemy etapami, tak żeby nie zatrzymywać działającego systemu.
02Architektura dobrana do skali
Nie każda aplikacja potrzebuje rozbudowanej chmury. Dla wielu wystarczy jeden dobrze skonfigurowany serwer z kontenerami, kopiami zapasowymi i monitoringiem. Kubernetes, wiele stref dostępności czy autoskalowanie proponujemy wtedy, gdy skala i wymagania dostępności uzasadniają ich koszt utrzymania.
Najczęściej pracujemy z AWS, a aplikacje uruchamiamy w kontenerach Docker. Kontenery sprawiają, że aplikacja działa tak samo na komputerze programisty, na środowisku testowym i na produkcji. O tym, kiedy warto sięgnąć po orkiestrację, piszemy w artykule o Dockerze i Kubernetes, a wybór dostawcy chmury omawiamy we wpisie AWS, Azure czy Google Cloud.
03Infrastruktura jako kod i automatyczne wdrożenia
Konfigurację infrastruktury zapisujemy w kodzie, najczęściej w Terraform, i trzymamy w repozytorium. Każda zmiana jest widoczna, przejrzana i odwracalna. Nowe środowisko, np. testowe dla kolejnego klienta, powstaje z tego samego opisu, a nie z pamięci osoby, która kiedyś konfigurowała serwer.
Wdrożenia prowadzimy przez potoki CI/CD: kod przechodzi testy, jest budowany do obrazu kontenera i trafia na kolejne środowiska. Nowe wersje udostępniamy w sposób kontrolowany, z możliwością szybkiego wycofania, jeśli coś pójdzie nie tak. Wdrożenie przestaje być ryzykownym wydarzeniem i staje się rutyną.
04Monitoring, kopie zapasowe i koszty
Monitoring ma odpowiadać na trzy pytania: czy system działa, czy działa szybko i co się stało, gdy przestał. Zbieramy metryki, logi i alerty, żeby o problemie wiedzieć przed użytkownikami. Kopie zapasowe nie tylko ustawiamy, ale też regularnie sprawdzamy, czy da się z nich odtworzyć system.
Koszty chmury analizujemy na podstawie danych z monitoringu: dopasowujemy rozmiar zasobów do ruchu, usuwamy nieużywane usługi i ustawiamy alerty budżetowe. Monitoring, kopie zapasowe i regularne aktualizacje są też podstawą WPWard, naszej platformy usług utrzymaniowych dla stron na WordPressie.
05Utrzymanie
Po zbudowaniu albo uporządkowaniu infrastruktury możemy ją dalej utrzymywać: aktualizować systemy i zależności, reagować na alerty, planować zmiany pod rosnący ruch i dbać o koszty. Wszystko, co robimy, zostaje opisane w repozytorium, więc infrastruktura nie jest czarną skrzynką ani dla nas, ani dla zespołu po stronie klienta.
Masz infrastrukturę, która wymaga uporządkowania, albo planujesz przenosiny do chmury? Opisz nam, na czym dziś działa Twoja aplikacja, a zaproponujemy, od czego zacząć.
JAK PRACUJEMY
- 01ODKRYCIECele biznesowe, ograniczenia, audyt techniczny.
- 02STRATEGIAZakres, kierunek architektury, plan realizacji.
- 03DESIGNSystem interfejsu, przepływy, zweryfikowane prototypy.
- 04ROZWÓJIteracyjne wdrożenia względem działającego środowiska.
- 05TESTYAutomatyczne pokrycie testami, testy obciążeniowe i bezpieczeństwa.
- 06WDROŻENIEPotoki CI/CD, monitoring, kontrolowany rollout.
- 07SKALAWydajność, koszty i rozbudowa możliwości.
TECHNOLOGIE
NAJCZĘSTSZE PYTANIA
Czy każda aplikacja potrzebuje Kubernetes?
Nie. Dla wielu aplikacji wystarczą prostsze usługi zarządzane albo kontenery na jednym serwerze. Kubernetes proponujemy, gdy skala i liczba usług uzasadniają jego koszt utrzymania.
Czy możecie przejąć infrastrukturę zbudowaną przez kogoś innego?
Tak. Zaczynamy od audytu i opisania obecnej konfiguracji, a potem przenosimy ją stopniowo do infrastruktury jako kod.
Jak ograniczacie koszty chmury?
Analizujemy wykorzystanie zasobów, dobieramy ich rozmiar do ruchu, porządkujemy nieużywane usługi i ustawiamy alerty budżetowe. Decyzje opieramy na danych z monitoringu.
Czy pomagacie w migracji do chmury?
Tak. Najpierw opisujemy obecne środowisko i zależności, potem przygotowujemy docelową architekturę w kodzie i przenosimy usługi etapami, z planem wycofania na wypadek problemów.
Z jakimi dostawcami chmury pracujecie?
Najczęściej z AWS. Dostawcę dobieramy do wymagań projektu i tego, z czego firma już korzysta. Dzięki infrastrukturze jako kod i kontenerom aplikacja nie jest mocno przywiązana do jednego dostawcy.