Infrastructure-as-a-Code jako model budowy bezpiecznej i automatycznej platformy IT

Warunkiem transformacji infrastruktury w dużej, zwłaszcza regulowanej organizacji jest uporządkowanie środowiska legacy, modernizacja data center, szeroka wirtualizacja zasobów oraz zmniejszenie zależności od ręcznie zarządzanej infrastruktury. Dopiero na takim fundamencie można budować środowisko, które pozwala szybciej tworzyć, testować, bezpiecznie wdrażać i uruchamiać aplikacje.

W ważnym elementem tej transformacji staje się przejście dużej części portfela aplikacyjnego na kontenery. Nie jest to wyłącznie kwestia zmiany technologii. Konteneryzacja tworzy podstawę do standaryzacji, automatyzacji i przenośności środowisk, a więc także do lepszego zarządzania czasem dostarczania zmian oraz dostępnością usług.

Dwa, wzajemnie uzupełniające się środowiska IT

W tym modelu warto rozwijać dwa, wzajemnie uzupełniające się środowiska – chmurę prywatną i chmurę publiczną. Nie chodzi przy tym o ideologiczny wybór jednej z nich. Aplikacje powinny trafiać na platformę najbardziej efektywną pod względem kosztów, bezpieczeństwa, wymogów regulacyjnych i funkcjonalności. Organizacja nie powinna ani bezwarunkowo faworyzować, ani z góry blokować żadnego z modeli.

W dojrzałym środowisku hybrydowym istotna część workloadów może działać w chmurze prywatnej. Chmura publiczna obsługuje tymczasem wybrane scenariusze, w których wnosi realną wartość. Taki podział zazwyczaj wynika z praktyki: kosztów, wymogów bezpieczeństwa, istniejących kompetencji oraz bliskości własnych centrów przetwarzania danych.

Założenie jest proste: aplikacje – w ramach ustalonego frameworku – mają wybierać najbardziej efektywną platformę, a pion IT nie faworyzuje ani nie blokuje żadnego z podejść.

Kubernetes jako element strategicznej kontroli

Największą zaletą hyperscalerów jest przejęcie odpowiedzialności za fizyczne warstwy środowiska: sprzęt, chłodzenie, skalowanie infrastruktury i operacje data center. Dla organizacji, która nie ma własnej infrastruktury ani zespołów operacyjnych, może to być argument rozstrzygający. Sytuacja wygląda inaczej w dużej organizacji, która ma od lat dobrze poukładane, szybkie i przewidywalne procesy zarządzania usługami centrum danych.

Jeżeli dostarczenie serwera lub zasobów nie jest już wąskim gardłem. Kiedyś takie rzeczy potrafiły trwać miesiącami, dziś to kwestia dni. Kluczowe stają się problemy znajdujące się wyżej w stosie technologicznym: wdrażanie aplikacji, budowanie i niszczenie środowisk IT, wgrywanie nowych wersji, przenoszenie między platformami, aktualizacje oraz zapewnienie powtarzalności całego procesu.

W takich warunkach uzasadnione może być zbudowanie własnej chmury prywatnej opartej na Kubernetesie i rozwiązaniach open source, a nie na płatnej, „opakowanej” platformie. Decyzja nie musi wynikać wyłącznie z kosztów. Równie ważne są pełna kontrola nad platformą, niezależność operacyjna i rozwijanie kompetencji wewnątrz organizacji.

Warunkiem powodzenia jest wyspecjalizowany zespół platformowy. Jego zadaniem nie jest jedynie uruchomienie klastra Kubernetes, lecz także długofalowe utrzymanie środowiska, projektowanie jego odporności, zapewnienie standardów bezpieczeństwa i rozwijanie wspólnej platformy dla zespołów aplikacyjnych.

Własna platforma może osiągać bardzo wysoką dostępność, jeśli jest właściwie zaprojektowana i utrzymywana. Sam fakt korzystania z chmury publicznej nie eliminuje ryzyka przestojów po stronie dostawcy. Dlatego rzeczywiste SLA, zdolność do reagowania na incydenty i kontrola nad krytycznymi komponentami należy oceniać na podstawie praktyki, a nie wyłącznie deklaracji.

Kluczowa warstwa: automatyzacja dostarczania aplikacji

Automatyzacja infrastruktury oferowana przez dostawców chmurowych jest wartościowa, lecz nie rozwiązuje za organizację całego procesu dostarczania oprogramowania. O przewadze operacyjnej i krótszym Time-to-Market decyduje przede wszystkim sposób, w jaki aplikacje są budowane, testowane, wdrażane, aktualizowane i przenoszone pomiędzy środowiskami.

Odpowiedzią jest podejście Infrastructure-as-a-Code. Wszystkie istotne elementy środowiska – od serwera i systemu operacyjnego, po konfigurację aplikacji – powinny być opisane w kodzie. Jeżeli zmiana przeszła wymagane akceptacje i testy, jej wdrożenie powinno następować automatycznie, w powtarzalnym pipeline’ie.

Zmienia to rolę administratorów. Nie polega ona na ręcznym logowaniu się do pojedynczych maszyn, kopiowaniu plików i wykonywaniu zmian na produkcji. Administratorzy zarządzają platformą, standardami, automatyzacją, wydajnością i zasobami. Zespoły aplikacyjne otrzymują zaś mechanizmy, które umożliwiają im samodzielne, kontrolowane wdrażanie zmian.

Taki model ogranicza ryzyko błędów manualnych, przyspiesza dostarczanie funkcjonalności o co najmniej 50% i pozwala obsługiwać rosnącą liczbę systemów oraz zmian bez proporcjonalnego zwiększania liczebności zespołów operacyjnych.

Transformacja jest przede wszystkim zmianą organizacyjną

W podobnych projektach można łatwo niedoszacować znaczenie czynnika ludzkiego. Platformy, frameworki i dokumentacja mogą być gotowe, lecz organizacja nie zmieni sposobu pracy automatycznie. Opór organizacyjny i przywiązanie do starego sposobu pracy są ogromne.

Administratorzy są przyzwyczajeni, że mają pełen dostęp do serwera, wszystko robią ręcznie i to działa. Przejście na model oparty na skryptach, repozytoriach, automatyzacji i kontrolowanych pipeline’ach jest dużą zmianą. Przez lata ręczne działania mogły działać poprawnie, dlatego samo polecenie zmiany nie wystarczy.

Niezbędne są komunikacja, szkolenia, wsparcie zespołów oraz spójny Governance. Szczególne znaczenie ma konsekwencja w egzekwowaniu standardów. Zespoły platformowe powinny mieć możliwość zatrzymania wdrożenia aplikacji, która nie spełnia wymogów jakościowych, np. nie posiada odpowiednich skryptów, automatyzacji czy wymaganych mechanizmów bezpieczeństwa.

W pierwszym okresie taki model oznacza zwroty, poprawki i czasem opóźnienia w projekcie. W długiej perspektywie prowadzi jednak do spójności, wyższej jakości i ograniczenia długu operacyjnego.

W momencie, gdy zmiana przejdzie całą ścieżkę formalną, deployment odbywa się automatycznie. W zależności od pipeline’u może wyglądać trochę inaczej. Ale idea jest ta sama. Ktoś uruchamia proces i dalej system sam buduje, testuje i wdraża.

Zespoły chmurowe i standardy wejścia

Budowę Infrastructure-as-a-Code warto rozpocząć od stworzenia zespołów odpowiedzialnych za platformy chmurowe. Zespół chmury prywatnej powinien dostarczać nie tylko Kubernetes i infrastrukturę dla kontenerów, lecz także pełen framework decyzyjny i wdrożeniowy. Składa się na niego dokumentacja, standardy, wymagania oraz procesy współpracy dla developerów i administratorów.

Zasada powinna być jednoznaczna! Rozwiązanie, które ma działać na platformie chmurowej, musi spełniać wymagania automatyzacji. Nie ma miejsca na ręczne wgrywanie zmian ani obchodzenie uzgodnionych procesów.

Podobny model powinien obowiązywać w chmurze publicznej. Zespół odpowiedzialny za to środowisko definiuje zasady wejścia do Landing Zones, czyli przygotowanych, bezpiecznych i zgodnych z politykami organizacji przestrzeni dla aplikacji. Również tam nie da się skalować ręcznej obsługi każdego rozwiązania.

Transformacja przebiega iteracyjnie. Część zespołów będzie zgłaszać aplikacje monolityczne, bez skryptów i bez przygotowania do pracy w modelu automatycznym. Takie projekty trzeba kierować do poprawy. Z czasem organizacja zbuduje katalog powtarzalnych problemów, wzorców i dobrych praktyk, a nowe zespoły mogą korzystać z doświadczeń wcześniejszych wdrożeń.

Governance zmian bez rezygnacji z szybkości

W organizacjach regulowanych każda zmiana musi być zarejestrowana, zaakceptowana i przetestowana. W wielu przypadkach konieczne są także testy bezpieczeństwa. Te zasady pozostają fundamentem działania. Automatyzacja nie oznacza rezygnacji z kontroli.

Zmiana następuje po przejściu formalnej ścieżki. Gdy wymagania Governance zostały spełnione, deployment może odbywać się automatycznie. Poszczególne pipeline’y będą różnić się szczegółami – zależnie od technologii – ale zasada jest wspólna. Proces inicjuje człowiek, a następnie system sam buduje, testuje i wdraża rozwiązanie wg wcześniej zdefiniowanych reguł.

Administratorzy nadal odgrywają istotną rolę. Natomiast odpowiedzialność pozostaje podzielona między zespoły rozwoju i infrastruktury. Ich praca nie polega już jednak na ręcznym „dopychaniu” pojedynczych zmian do produkcji. Koncentrują się na utrzymaniu platformy, standardach, zasobach i niezawodności całego środowiska.

Chmura publiczna pod kontrolą FinOps

Dla niewielkiej, nieregulowanej firmy chmura publiczna jest często najlepszym sposobem szybkiego wejścia na rynek. Pozwala uruchomić aplikację bez budowania własnego data center i rozległych zespołów operacyjnych. Nawet wyższy koszt jednostkowy może być uzasadniony krótszym czasem realizacji. Duża, regulowana organizacja ma jednak inne uwarunkowania. Zwykle posiada rozbudowane systemy legacy, wysokie wymagania bezpieczeństwa oraz obowiązki związane ze zgodnością regulacyjną.

W jej przypadku zbudowanie Landing Zones spełniających te potrzeby jest znacznie bardziej złożone, niż sugerują typowe materiały sprzedażowe. Wymaga zaprojektowania konfiguracji, kontroli przepływu danych, modeli dostępu i mechanizmów zgodności.

Drugim wyzwaniem jest przewidywalność kosztów. Cenniki chmurowe bywają skomplikowane, a źle zaprojektowany proces lub nieuważne zapytanie może wygenerować znaczące, nieplanowane wydatki. Konieczny jest więc dedykowany model FinOps, który stale monitoruje użycie zasobów, rozlicza koszty, identyfikuje nieefektywności i optymalizuje środowisko.

Chmura publiczna powinna być traktowana jako ważny element architektury hybrydowej, ale wybierany tam, gdzie daje wyraźną przewagę biznesową albo funkcjonalną. Jeżeli środowisko prywatne zapewnia korzystniejszą dostępność, przewidywalność kosztów i spełnia wymagania aplikacji, może być naturalnym wyborem dla znacznej części workloadów.

AI: wzrost efektywności wymaga nowych zabezpieczeń

Sztuczna inteligencja może zmienić sposób tworzenia i dostarczania oprogramowania w skali porównywalnej z poprzednimi przełomami technologicznymi. Dotyczy to zarówno pracy zespołów developerskich, jak i procesów biznesowych.

Od strony infrastruktury organizacje rozwijają własne zasoby GPU dla wewnętrznych rozwiązań GenAI oraz korzystają z usług AI dostępnych w chmurach publicznych. Infrastruktura AI jest jednak kosztowna, a brak kontroli nad wykorzystaniem zasobów może szybko prowadzić do nieefektywności. Od pierwszego etapu wdrożeń potrzebne są więc mechanizmy Governance i FinOps.

Duży potencjał mają narzędzia dla programistów: asystenci kodu, generowanie fragmentów aplikacji oraz refaktoryzacja. Ich wdrażanie wymaga jednak zaprojektowania jasnych zasad. Widać ogromny potencjał wzrostu efektywności deweloperów, ale też konkretne ryzyka: zalew kodu różnej jakości, nowe wektory podatności, niekontrolowane koszty tokenów.

Na obecnym etapie nie należy zakładać, że AI będzie samodzielnie wykonywać operacje na produkcyjnej infrastrukturze organizacji regulowanej. Modele muszą najpierw stać się bardziej deterministyczne, przewidywalne i możliwe do kontrolowania. Dopiero wtedy można bezpiecznie przesuwać je głębiej w łańcuchu dostarczania oprogramowania.

Docelowy model: automatyzacja i mobilność workloadów

Długofalowym celem jest maksymalne ograniczenie ręcznego administrowania dzięki pełnej automatyzacji procesów operacyjnych. Równie istotna jest mobilność aplikacji: zdolność do sprawnego przenoszenia workloadów między własnymi data center i różnymi chmurami.

Taka mobilność wzmacnia odporność cyfrową, ale ma także znaczenie dla jakości architektury oraz dojrzałości zespołów. Wymusza budowanie aplikacji w sposób bardziej przenośny, powtarzalny i niezależny od pojedynczej platformy.

Natomiast w obszarze AI celem powinno być zwiększanie efektywności, skracanie Time-to-Market i obniżanie kosztu wytwarzania oprogramowania przy zachowaniu wysokiego poziomu bezpieczeństwa. Wymaga to nowych narzędzi, rozwijania kompetencji oraz zmiany myślenia o roli infrastruktury.

Infrastruktura nie jest już wyłącznie zapleczem utrzymującym systemy. Staje się platformą umożliwiającą innowację. Organizacje, które uznają, że ta zmiana wydarzy się sama, ryzykują utratę konkurencyjności w kolejnych latach.

Nowy biznes może być w 100% chmurowy i wyizolowany

Doświadczenia z porządkowania środowisk legacy i budowania chmury prywatnej są uzasadnione tam, gdzie istnieją wieloletnie zaszłości i własne data center. Jednak z perspektywy nowego biznesu powielanie tego modelu byłoby błędem. Rozsądniejsze jest myślenie o architekturze Cloud-Native i w pełni wyizolowanej.

W mojej bieżącej pracy operujemy w środowisku wyłącznie chmurowym. Tworzymy wysoce transakcyjną platformę o globalnym zasięgu, która w czasie rzeczywistym komunikuje się z operatorami telekomunikacyjnymi rozsianymi na całym globie. W takim scenariuszu jakiekolwiek powiązanie z fizycznym data center jest po prostu niemożliwe.

Żadna własna infrastruktura nie zapewni punktów obecności w sąsiedztwie sieci telekomunikacyjnych jednocześnie w Azji, Afryce czy Ameryce Północnej. Tylko globalna chmura publiczna oferuje wieloregionowość i niski poziom opóźnień niezbędne przy dużej transakcyjności. Daje też gotowe mechanizmy skalowania i odporności na awarie, których budowa we własnym zakresie byłaby nieuzasadniona kosztowo.

Brak obciążeń systemami legacy to największa przewaga nowego projektu. Wyizolowane środowisko chmurowe pozwala od pierwszego dnia bazować na pełnej automatyzacji i Infrastructure-as-a-Code, skupiając zespół na logice biznesowej zamiast na utrzymaniu sprzętu.

O ile dla dużych organizacji hybryda bywa etapem przejściowym, to warto budować pewne części biznesowe tylko w chmurze. O ile pozwala na to wyizolowanie nowego projektu od legacy.

Aleksander Gawroński, Head of IT, Aduna Global