Infrastruktura jako kod

Zaufali nam

Umów rozmowę odkrywczą

Co faktycznie obejmują usługi infrastructure as code

Infrastructure as code (IaC) to praktyka definiowania, aprowizowania i zarządzania zasobami chmurowymi za pomocą plików konfiguracyjnych czytelnych dla maszyn, zamiast ręcznych działań w konsoli. Usługa IaC obejmuje ten proces całościowo: od napisania pierwszego modułu, przez osadzenie zmian infrastruktury w pipeline'ach CI/CD, aż po automatyczne egzekwowanie polityk zgodności.

Alternatywa, klikanie w konsolach chmurowych, uruchamianie doraźnych skryptów czy poleganie na wiedzy jednego inżyniera, prowadzi do środowisk, które z czasem zaczynają się rozbiegać i których nie można wiarygodnie odtworzyć. Gdy środowisko stagingowe nie odpowiada produkcji, debugowanie staje się zgadywaniem. Gdy ten inżynier odchodzi, wiedza odchodzi razem z nim. Aprowizowanie sterowane kodem zastępuje te ryzyka jednym źródłem prawdy, które każdy członek zespołu może przeczytać, przejrzeć i ponownie wdrożyć.

Deklaratywne aprowizowanie

Piszemy definicje infrastruktury opisujące pożądany stan końcowy środowiska, łańcuch narzędzi sam wyznacza ścieżkę dojścia do tego stanu. Każdy zasób, sieć, obliczenia, pamięć masowa, jest od pierwszego dnia skodyfikowany i objęty kontrolą wersji.

Przepływy pracy GitOps

Zmiany infrastruktury przechodzą przez ten sam proces pull requestu, przeglądu i scalenia co kod aplikacji. Każda zmiana jest identyfikowalna, każde cofnięcie to revert, a żaden zasób nie powstaje poza zatwierdzonym przepływem pracy.

Wielokrotnego użytku moduły

Budujemy wielokrotnego użytku moduły dla typowych wzorców, VPC, klastry Kubernetes, warstwy baz danych, dzięki czemu twoje zespoły mogą szybko uruchamiać spójne, wcześniej zatwierdzone środowiska bez każdorazowego pisania konfiguracji od zera.

Wykrywanie dryftu

Automatyczne sprawdzenia stale porównują zadeklarowany stan infrastruktury z tym, co faktycznie działa w chmurze. Każde odchylenie jest sygnalizowane, zanim przerodzi się w incydent produkcyjny lub lukę w zgodności.

Zarządzanie multi-cloud i wielośrodowiskowe

Tak strukturyzujemy kod, by te same moduły działały na AWS, GCP i Azure oraz w środowiskach deweloperskich, stagingowych i produkcyjnych, zmienne specyficzne dla środowiska utrzymują konfigurację w porządku.

Policy as code

Reguły bezpieczeństwa i zgodności zapisujemy jako kod i egzekwujemy automatycznie przed zastosowaniem jakiejkolwiek zmiany infrastruktury. Dzięki temu sprawdzenia zgodności przenosimy w lewo, naruszenia są wykrywane w pipeline'ie, a nie dopiero podczas audytu po incydencie.

Jak pomogliśmy Nodus Medical bezpiecznie skalować usługi dla zespołów chirurgicznych w Europie

Nodus Medical prowadzi krytyczną platformę medyczną, na której polegają zespoły chirurgiczne w całej Europie. Wraz ze wzrostem popytu firma potrzebowała infrastruktury, która będzie skalować się bezpiecznie i niezawodnie, spełniając rygorystyczne wymogi zgodności przy jednoczesnym zagwarantowaniu wysokiej dostępności wymaganej w środowiskach klinicznych.

Zespół DevOps Netguru zmigrował infrastrukturę Nodus Medical do Amazon Web Services z wykorzystaniem AWS Fargate, tworząc bezpieczną architekturę wielostrefową z odpowiednią izolacją, szyfrowaniem i kompleksowym logowaniem. Efektem jest skalowalne, wysoko dostępne środowisko chmurowe z automatycznym odtwarzaniem po awarii i całościowym monitoringiem przez DataDog i CloudWatch, przy maksymalnym czasie przestoju wynoszącym zaledwie pięć minut w przypadku awarii strefy dostępności.

Since we operate in healthcare, where tolerance for critical issues is relatively low, we’re constantly improving the quality of our software.

Lukas Vogt

Former CEO at Nodus Medical

Przeczytaj opis projektu

Praca Netguru przełożyła się na wyższą średnią wartość zamówienia, większy rozmiar koszyka i rosnącą liczbę aktywnych użytkowników miesięcznie. Są proaktywni, zaangażowani i mają ogromne doświadczenie.
Ayman Kaheel
CTO, Breadfast

Nie zostawiają żadnego kamienia nieodwróconego, gdy chodzi o zrozumienie kontekstu biznesowego. Dzięki ich unikalnemu podejściu udało nam się zmniejszyć obciążenie zespołu operacyjnego, jednocześnie poprawiając doświadczenie użytkownika.
Tiago Goncalves Cabaço
VP of Design, Careem

Netguru to najlepsza agencja, z jaką do tej pory współpracowaliśmy. Potrafią projektować nowe umiejętności, funkcje i interakcje w naszym modelu, przykładając dużą wagę do szybkości wejścia na rynek.
Adi Pavlovic
Director of Innovation, Keller Williams

Wybieramy narzędzie odpowiednie dla twojego kontekstu, nie to modne

Żadne pojedyncze narzędzie IaC nie jest właściwą odpowiedzią dla każdego zespołu. Nasi inżynierowie pracują z głównymi rozwiązaniami i rekomendują je na podstawie twojego istniejącego stosu technologicznego, umiejętności zespołu, obecności w chmurze i wymagań dotyczących zarządzania, nie na podstawie tego, co akurat znają najlepiej.

Terraform to nasz najczęstszy wybór dla środowisk multi-cloud. Jego deklaratywna składnia HCL jest czytelna, ekosystem providerów rozległy, a model zarządzania stanem dobrze odpowiada zespołom, które chcą wyraźnie oddzielić infrastrukturę od kodu aplikacji.
Pulumi sprawdza się u zespołów inżynierskich, które wolą pisać infrastrukturę w języku ogólnego przeznaczenia, TypeScript, Python, Go, zamiast w języku domenowym. Naturalnie wpasowuje się w kodebazy, gdzie deweloperzy sami odpowiadają za infrastrukturę.
AWS CloudFormation ma sens, gdy zespół jest w pełni zaangażowany w AWS, chce natywnej integracji usług bez zarządzania osobnym backendem stanu i potrzebuje ścisłego dopasowania do natywnych narzędzi governance AWS, takich jak AWS Config i Service Control Policies.
Ansible należy do innej kategorii: jest imperatywny i bezagentowy, co czyni go dobrze dopasowanym do zarządzania konfiguracją i konfiguracji po aprowizowaniu, a nie do samego aprowizowania zasobów. Często używamy go równolegle z Terraform do obsługi konfiguracji na poziomie systemu operacyjnego, którą narzędzia deklaratywne pomijają.

Jeśli zainwestowałeś już w jedno z tych narzędzi, pracujemy w ramach tego wyboru. Jeśli zaczynasz od zera lub migrujesz od ręcznego aprowizowania, przeprowadzimy cię przez wszystkie kompromisy, zanim zostanie napisana jakakolwiek linia kodu.

Jak ryzykowna jest migracja od ręcznego aprowizowania do IaC?

Ryzyko jest realne, ale łatwe do opanowania, gdy migracja przebiega etapami. Zaczynamy od importowania istniejących zasobów do Terraform lub wybranego narzędzia, na tym etapie żadne zasoby nie są usuwane ani tworzone na nowo. Następnie kodyfikujemy infrastrukturę przyrostowo, zaczynając od środowisk o niższym ryzyku i stopniowo przechodząc do produkcji. Każda faza obejmuje punkt przeglądu, zanim cokolwiek zmieni się w środowisku produkcyjnym.

Czy po zakończeniu współpracy będziemy uzależnieni od konkretnego narzędzia lub dostawcy?

Nie. Wszystko, co tworzymy, moduły, pipeline'y, dokumentacja, należy do twojego zespołu i żyje w twoim systemie kontroli wersji. Piszemy czysty, dobrze skomentowany kod bez własnościowych nakładek, które utrudniałyby utrzymanie lub rozbudowę bez naszego udziału. Jeśli po początkowym zaangażowaniu chcesz przenieść zarządzanie do wewnątrz firmy, tak strukturyzujemy przekazanie projektu, aby twoi inżynierowie mogli przejąć odpowiedzialność z pełną pewnością.

Czy IaC pomaga w zgodności z SOC 2 lub ISO 27001?

Tak, na dwa konkretne sposoby. Po pierwsze, ścieżki audytu IaC dają audytorom pełną historię każdej zmiany infrastruktury, kto ją zaproponował, kto zatwierdził i kiedy została zastosowana, co spełnia wymagania kontroli zarządzania zmianami w obu frameworkach. Po drugie, narzędzia policy-as-code, takie jak Open Policy Agent czy Checkov, automatycznie egzekwują bazowe standardy bezpieczeństwa, dzięki czemu możesz wykazać, że kontrole są wymuszane przez proces, a nie przez ręczny przegląd.

Jak działa wykrywanie dryftu po zakończeniu migracji?

Konfigurujemy zaplanowane uruchomienia pipeline'u, które porównują aktualny stan środowiska chmurowego ze zadeklarowanym stanem w repozytorium IaC. Każdy zasób zmodyfikowany, dodany lub usunięty poza zatwierdzonym przepływem pracy wywołuje alert. W zależności od twojego modelu zarządzania alert może blokować wdrożenia, automatycznie otwierać zgłoszenie lub powiadamiać odpowiedni zespół, konfigurujemy odpowiedź tak, by pasowała do twoich procesów.

Ile realnie kosztuje bieżące zarządzanie IaC?

Koszt zarządzania zależy od rozmiaru infrastruktury, tempa zmian i tego, ile bieżącej pracy twój wewnętrzny zespół chce przejąć. Po początkowej kodyfikacji i konfiguracji pipeline'u wiele zespołów przechodzi na lżejszy retainer obejmujący aktualizacje modułów, ulepszenia łańcucha narzędzi i okresowe przeglądy zgodności. Zakres ustalamy na podstawie twoich rzeczywistych potrzeb podczas fazy oceny, bez niespodzianek.

Czy po naszej stronie potrzebny jest dedykowany inżynier DevOps?

Niekoniecznie. Pracowaliśmy zarówno z zespołami bez dedykowanej funkcji infrastrukturowej, jak i z tymi, które mają pełną grupę platform engineeringu. W pierwszym przypadku przejmujemy więcej codziennej pracy i inwestujemy więcej czasu w transfer wiedzy. W drugim pracujemy ramię w ramię z twoimi inżynierami. Odpowiedni model współpracy ustalimy podczas rozmowy odkrywczej.