Notatki z rozmowy między Kief Morris (ThoughtWorks) i Abby Bangser (Syntaso) podczas konferencji GOTO 2025. Wszystkie przedstawione przemyślenia, obserwacje i wnioski pochodzą od rozmówców.

TL;DR

Infrastructure as Code przeszło długą drogę od konfiguracji serwerów z Chef i Puppet do konteneryzacji i serverless
Morris nazywa obecne ograniczenia „snowflakes as code” – każde środowisko wymaga osobnego, statycznego kodu
Nowe narzędzia jak System Initiative odchodzą od tradycyjnego kodu na rzecz zarządzania strukturami danych
Lekcje z software development (domain-driven design, mikrousługi, TDD) mogą zrewolucjonizować infrastrukturę
AI może pomóc w coaching i troubleshooting, jednak grozi utworzeniem „AI-assisted click ops”
Infrastruktura nie jest „tylko hydrauliką” – wymaga ścisłego połączenia biznesu z technologią
Platform engineering staje się warstwą biznesową odpowiedzialną za unikalne potrzeby organizacji

Dekada zmian w Infrastructure as Code

Morris rozpoczął swoją przygodę z infrastrukturą już na początku XXI wieku od CF Engine, następnie przechodził przez Puppet i Chef. Pierwszy rozdział jego książki nosił znaczący podtytuł „servers on the cloud”, co odzwierciedlało ówczesny fokus na konfiguracji systemów operacyjnych. CloudFormation i Terraform dopiero się pojawiały.

Bangser podkreśla kluczową zmianę filozoficzną w podejściu do infrastruktury. Przejście od „pets to cattle” oznaczało odejście od długotrwałych serwerów z własnymi nazwami i osobowościami do krótkotrwałych, wymienialnych zasobów. Ta zmiana fundamentalnie przekształciła sposób myślenia o infrastrukturze.

Morris opisuje proces nawarstwiania abstrakcji, który następował stopniowo. Virtualizacja w chmurze oznaczała, że lokalizacja serwera przestała mieć znaczenie. Z kolei kontenery uwolniły od konieczności myślenia o konkretnym serwerze. Wreszcie serverless sprawił, że nawet kontener stał się nieistotny.

Według Morris, największą zmianą jest proliferacja dostępnych usług i dramatyczny wzrost złożoności. Współczesny projekt infrastrukturalny obejmuje znacznie więcej komponentów niż dekadę temu. Jak obrazowo stwierdza: „infrastruktura jest jak góra lodowa” – nawet najmniejsza funkcjonalność aplikacji wymaga budowania ogromnej infrastruktury pod spodem.

Problem „snowflakes as code”

Morris identyfikuje fundamentalny problem obecnych narzędzi Infrastructure as Code, nazywając go „snowflakes as code”. To podejście, gdzie kod definiuje statyczne środowisko, a każde nowe środowisko wymaga kopiowania i modyfikowania istniejącego kodu.

Główne ograniczenia obecnych rozwiązań:

Niska abstrakcja – narzędzia działają jako „cienka warstwa nad API chmur”
Kopiowanie kodu – każde środowisko wymaga duplikowania i dostosowywania
Niskopoziomowe zarządzanie – Terraform operuje na poziomie individual resources
Monolityczne deploymenty – terraform apply może trwać godziny, awaria oznacza restart

Morris opisuje przypadki, gdzie wykonanie terraform apply zajmuje godzinę lub dwie. Awaria w połowie procesu oznacza konieczność rozpoczynania od nowa. Pracowanie na tym poziomie staje się coraz trudniejsze, zwłaszcza gdy infrastruktura rozrasta się w geometrycznej progresji.

Nowe podejścia – od kodu do struktur danych

Morris wskazuje na innowacyjne rozwiązania jak System Initiative i Config Hub. Te narzędzia odchodzą od tradycyjnego kodu na rzecz zarządzania strukturami danych reprezentującymi infrastrukturę.

System Initiative, założone przez Adam Jacob (twórca Chef), wykorzystuje modele danych zamiast plików state znanych z Terraform. Morris wyjaśnia, że chociaż interfejs może przypominać GUI z drag-and-drop, jednak istota tkwi w zarządzaniu strukturami danych i ich wzajemnymi relacjami.

Bangser wprowadza koncepcję „progressive discovery”, którą definiuje jako możliwość łatwego wykonywania prostych zadań z opcją stopniowego zagłębiania się w szczegóły w miarę wzrostu potrzeb.

Morris nawiązuje do koncepcji „Mechanical Sympathy” autorstwa Martin Thompson. Chodzi o rozumienie warstw poniżej abstrakcji bez konieczności ciągłego o nich myślenia. Thompson używał przykładów z Java – znajomość architektury CPU i rozmiarów pamięci podręcznej pozwala definiować zmienne w sposób znacznie optymalizujący wydajność.

Abstrakcja nie powinna ukrywać, ale zarządzać obciążeniem poznawczym. W praktyce oznacza to możliwość skupienia się na problemie biznesowym z dostępem do niższych warstw w przypadku problemów z wydajnością.

Praktyczny przykład: od Prometheusa do CloudWatch

Morris i Bangser opisują wspólny projekt organizacji przechodzącej do chmury. Zamiast mapować wszystkie funkcjonalności i budować je równocześnie, wybrali podejście przyrostowe.

Klient chciał używać Prometheus do monitoringu. Zamiast od razu budować całą infrastrukturę pod Prometheus, zespół rozpoczął od CloudWatch na AWS. Pozwoliło to szybciej uruchomić pierwszą aplikację w najprostszej możliwej wersji, nawet bez bazy danych.

Lekcje z software development

Morris podkreśla wartość doświadczenia ThoughtWorks jako firmy konsultingowej ds. dostarczania oprogramowania z silnym fokusem na architekturę. Problem polega jednak na tym, że specjaliści od infrastruktury, nawet pracując z zespołami Agile, nie stosowali tych samych koncepcji do budowania środowisk.

Koncepcje z architektury oprogramowania mają bezpośrednie zastosowanie w infrastrukturze. Domain-driven design, continuous delivery i mikrousługi sprawdzają się równie dobrze w świecie Infrastructure as Code.

Bangser dodaje kluczową obserwację o przewadze konsultantów. Określając siebie jako „gray braid rather than gray beard”, zauważa, że ona i Morris mają przewagę dostrzegania wzorców w różnych domenach znacznie szybciej niż osoby pracujące latami w tej samej organizacji.

Morris i Bangser są również zwolennikami Team Topologies – frameworka pomagającego tworzyć język do identyfikowania wzorców organizacyjnych. Jak zauważa Bangser, większość ich rozmów dotyczy „świata wokół technologii” bardziej niż samej technologii.

„Application-driven development” to podejście Morris, gdzie punkt wyjścia stanowią potrzeby aplikacji. Zamiast budować infrastrukturę odgórnie, zespoły najpierw modelują domeny biznesowe, następnie rozszerzają model o domeny techniczne jak monitoring, storage czy networking.

Morris dostrzega potrzebę przejścia od monolitycznych projektów infrastrukturalnych do mniejszych komponentów. Podobnie jak w software development, lepszy podział ułatwia testowanie, pipelines i zarządzanie.

Bangser zauważa jednak, że testowanie w Infrastructure as Code wciąż stanowi wyzwanie. Koszty tworzenia środowisk testowych, pętle sprzężenia zwrotnego i pytania o testowanie frameworka versus logiki biznesowej – wszystko to wymaga przemyślenia.

AI w Infrastructure as Code – obietnice i zagrożenia

Morris dostrzega znaczący potencjał AI w rozwiązywaniu problemów i agregacji informacji. Największe możliwości leżą w coaching i zadawaniu prowadzących pytań podczas konfiguracji infrastruktury.

Pytania jakie AI może zadać przy konfiguracji bazy danych

Morris wyobraża sobie scenariusz, gdzie developer potrzebuje bazę danych. AI może przeprowadzić wywiad kierowany zamiast zmuszać developera do myślenia o subnet routing i konfiguracji sieci:

Typ danych – co będzie przechowywane w bazie?
Compliance – czy dane zawierają informacje osobiste wymagające zabezpieczeń?
Strategia backup – czy wystarczy backup raz dziennie, czy potrzebny ciągły?
Transakcyjność – jak intensywne będzie wykorzystanie bazy?
Wymagania wydajnościowe – jakie są oczekiwania co do czasu odpowiedzi?
Dystrybucja geograficzna – czy dane muszą być dostępne w określonych regionach?
Wymagania trwałości – jak krytyczne są te dane dla biznesu?

Morris wyjaśnia, że AI może również analizować bazę kodu i automatycznie sugerować rozwiązania. Na przykład: „widzę, że przechowujesz informacje osobiste, myślę że powinieneś użyć tej opcji bezpieczeństwa”.

Komponenty infrastrukturalne powinny mieć wstępnie skonfigurowane opcje dla elementów istotnych dla developera, ukrywając jednocześnie złożoność niskopoziomowych szczegółów.

Morris ostrzega jednak przed naiwnym podejściem. „AI-assisted click ops” to pułapka, której należy za wszelką cenę unikać.

Morris przeprowadził interesujący eksperyment – wrócił do pierwszych rozdziałów swojej książki napisanych rok temu, sprawdzając czy zasady Infrastructure as Code nadal się sprawdzają w erze AI. Odkrył, że podstawowe zasady pozostają aktualne. Powtarzalność, modyfikowalność, spójność i verzjonowanie muszą być zachowane niezależnie od wykorzystania AI.

Business-technology alignment

Morris obserwuje niebezpieczną tendencję traktowania infrastruktury jako „tylko hydrauliki”. Liderzy biznesowi wolą nie myśleć o infrastrukturze, podczas gdy technicy budują standardowe „landing zones” bez kontekstu biznesowego.

Symptomy problemów z infrastrukturą

Długie czasy provisioningu – tworzenie środowisk trwa tygodnie lub miesiące
Skargi programistów – brak dostępu do zasobów testowych
Powtarzające się pytania – „dlaczego infrastruktura zawsze blokuje projekty?”
Brak self-service – konieczność zgłaszania ticketów na każdą zmianę
Długie lead times – od pomysłu do wdrożenia mija zbyt dużo czasu

Rezultatem są ciągłe problemy bez zrozumienia ich źródła. Morris podkreśla konieczność połączenia wartości biznesowej z implementacją infrastrukturalną.

Morris zauważa kluczowy wzorzec: „nie bez powodu mamy teraz platform engineering”. Wcześniej nazywano to DevOps, potem developer experience, obecnie platform engineering – to różne nazwy tego samego fundamentalnego problemu. Biznes wciąż musi myśleć o infrastrukturze na poziomie wyższym niż generyczne usługi chmurowe.

Bangser dodaje, że platform engineering musi koncentrować się na tym, co unikalne dla danego biznesu. Platform teams muszą rozumieć domenę biznesową i budować rozwiązania wspierające specyficzne potrzeby organizacyjne.

Morris stwierdza jednoznacznie: „wciąż musisz myśleć o tym, co jest właściwe dla twojego biznesu i tego, co próbujesz osiągnąć w swojej domenie. Jakie są w tym warianty? Na tym poziomie to nie jest generyczne„.

Morris zauważa, że poziom abstrakcji, na którym infrastruktura może być traktowana jak utility, znajduje się znacznie niżej niż powszechnie sądzimy. W praktyce kończy się na warstwie cloud providerów – AWS, Azure, Google Cloud. Wszystko powyżej wymaga customizacji biznesowej.

Bangser nawiązuje do Wardley mapping i koncepcji „floating platforms” Gregor Hope. W świecie technologii ciągle commoditizujemy różne warstwy. Pięćdziesiąt lat temu power cycling i chłodzenie centrów danych były krytyczne dla wszystkich pracujących w technologii. Obecnie 99% nie myśli o tym na co dzień, jednak ta 1% wciąż istnieje i zarządza tym z poziomu poniżej naszej linii widoczności.

Przyszłość Infrastructure as Code

Morris szczerze przyznaje, że Infrastructure as Code może „umrzeć”, ale nie ma to znaczenia. Ważne są zmiany w abstrakcji, automatyzacji i zarządzaniu infrastrukturą. Narzędzia będą ewoluować, jednak podstawowe potrzeby pozostaną.

Bangser zauważa coś charakterystycznego dla ich rozmowy: „tak wiele z tego ma bardzo mało wspólnego z technologią, a dotyczy świata wokół technologii”. Dlatego obaj stali się zwolennikami Team Topologies – frameworka skupiającego się na wzorcach organizacyjnych bardziej niż na czystej technologii.

Kluczem jest nauka z software development – domain modeling, lepsze abstrakcje i mniejsze deployable units. Morris podkreśla szczerze, że jako branża „wciąż się uczymy jako branża, jak robić to dobrze”. Koncepcje z software engineering mają zastosowanie w infrastrukturze, często jednak w różny sposób i wciąż eksperymentujemy z najlepszymi praktykami.

Bangser konkluduje, że przyszłość leży w lepszym łączeniu świata biznesu z technologią. Platform teams muszą rozumieć unikalne potrzeby swojej organizacji i budować rozwiązania je wspierające, zamiast kopiować generyczne wzorce.

Kluczowy insight

Mikrousługi dla infrastruktury

Standardowo myślimy: Infrastructure as Code to jeden duży projekt Terraform z modułami, który deployujemy jako całość.

W praktyce okazuje się, że: Potrzebujemy rozbić infrastrukturę na małe, niezależne, szybko deployowalne komponenty – tak jak zrobiliśmy to z aplikacjami.

Dlaczego to jest istotne: Morris opisuje projekty gdzie terraform apply trwa godzinę lub dwie, a awaria w połowie oznacza restart od zera. To jest dokładnie ten sam problem, który rozwiązywaliśmy w software development przechodząc od monolitów do mikrousług.

Test na jutro: Następnym razem gdy będziesz mieć monolityczny projekt Infrastructure as Code trwający ponad 15 minut, zamiast dodawać kolejne moduły spróbuj rozbić go na mniejsze, niezależnie deployowalne części i sprawdź jak bardzo skróci to pętlę sprzężenia zwrotnego.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je w transkrypcie rozmowy Kief Morris i Abby Bangser z konferencji GOTO 2025.

Tag: Domain Driven Design

Ewolucja Infrastructure as Code – czy nadszedł czas na nowe podejście? #EN158