1 godzina temu
Platform engineering nie zaczyna mieć sensu przy określonej liczbie programistów, ale wtedy, gdy firma coraz częściej odkrywa, iż kilka zespołów osobno rozwiązuje ten sam problem, buduje podobne pipeline’y, konfiguruje podobne środowiska i ponownie przechodzi przez te same uzgodnienia z infrastrukturą, bezpieczeństwem czy operacjami.
Właśnie z takiej powtarzalności wyrasta cała idea. Zamiast pozostawiać każdemu zespołowi pełną swobodę w budowaniu własnego sposobu wdrażania aplikacji, organizacja tworzy wspólną warstwę usług i standardów, która pozwala programistom szybciej przejść od kodu do działającego środowiska. W dobrze zaprojektowanym modelu developer nie musi znać wszystkich szczegółów konfiguracji chmury, polityk bezpieczeństwa czy infrastruktury jako kodu. Dostaje gotową, przewidywalną ścieżkę, a złożoność zostaje ukryta tam, gdzie rzeczywiście ma to sens.
Problem pojawia się wtedy, gdy sama platforma zaczyna rosnąć szybciej niż potrzeba, którą miała rozwiązać.
Produktywność zespołu to nie to samo co tempo całej organizacji
Badanie DORA z 2024 roku pokazało ciekawą sprzeczność. Korzystanie z wewnętrznych platform deweloperskich było związane z wyższą deklarowaną produktywnością pojedynczych programistów, zespołów i całych organizacji, ale jednocześnie z niższą przepustowością dostarczania systemu oraz słabszą stabilnością zmian.
To rozróżnienie jest fundamentalne, bo pokazuje, jak łatwo pomylić wygodę pracy z efektywnością całego systemu.
Developer może szybciej uruchomić środowisko, łatwiej wdrożyć usługę i rzadziej angażować zespół infrastruktury, a mimo to firma jako całość nie musi dostarczać systemu szybciej. jeżeli platforma dokłada kolejne warstwy konfiguracji, polityk, abstrakcji i zależności od centralnego zespołu, część zysku znika po drodze. Złożoność nie znika, ale zostaje przesunięta z jednego miejsca do drugiego.
Dlatego coraz więcej uwagi przywiązuje się nie do samego faktu posiadania platformy, ale do tego, czy realnie zwiększa ona samodzielność zespołów. DORA wskazuje, iż możliwość wykonania zadania bez konieczności angażowania zespołu wspierającego wiąże się z wyższą produktywnością. To znacznie bardziej praktyczne kryterium niż liczba funkcji w portalu czy liczba obsługiwanych technologii.
Skala nie zawsze oznacza liczbę pracowników
Nie istnieje wiarygodny próg, po którego przekroczeniu platform engineering automatycznie zaczyna się opłacać. Organizacja zatrudniająca 30 programistów może mieć bardziej złożone środowisko niż firma dwa razy większa, jeżeli rozwija kilkadziesiąt usług, działa w kilku chmurach i utrzymuje dużą liczbę zależności między zespołami.
Znacznie lepszym wskaźnikiem jest częstotliwość powtarzania tych samych czynności.
Holenderski Wehkamp doszedł do platform engineering właśnie w ten sposób. Przy niemal stu wdrożeniach tygodniowo manualne operacje infrastrukturalne zaczęły tworzyć kolejki, więc poszczególne zespoły tworzyły własne mechanizmy automatyzacji. Z czasem firma nie miała już jednego sposobu rozwiązywania problemu, ale wiele wariantów Terraformu, Ansible i lokalnych praktyk dotyczących dostępu, tagowania czy zarządzania zasobami.
Co istotne, odpowiedzią nie było zbudowanie rozbudowanego portalu deweloperskiego. Firma zaczęła od prostszych mechanizmów, które pozwalały automatycznie generować odpowiednie zmiany infrastrukturalne na podstawie wcześniej przygotowanych modułów. Operacja wymagająca wcześniej udziału zespołu platformowego mogła zostać wykonana samoobsługowo w ciągu około minuty.
To dobrze pokazuje, gdzie rzeczywiście znajduje się ekonomika platform engineering. Największa wartość często nie wynika z nowego interfejsu, ale z usunięcia powtarzalnych uzgodnień, kolejek i ręcznych operacji.
Brex pokazuje koszt źle postawionego problemu
Inny przypadek daje Brex. Firma wraz z szybkim wzrostem zespołu inżynierskiego zaczęła rozwijać centralną platformę opartą na Backstage, która miała uporządkować codzienną pracę developerów i zapewnić jeden punkt dostępu do narzędzi oraz usług.
Technicznie był to logiczny kierunek. Dopiero późniejsze badania pokazały jednak, iż jednym z największych problemów developerów nie był brak funkcji w portalu, ale wolne lokalne środowisko deweloperskie. Po przesunięciu uwagi na ten konkretny problem poziom satysfakcji z local development wzrósł według osoby odpowiedzialnej za developer productivity z 30 do 60 punktów na 100.
Ten przykład jest bardziej wartościowy niż wiele historii sukcesu, bo pokazuje coś znacznie bardziej typowego dla dojrzałych organizacji: można zbudować dobre narzędzie, które rozwiązuje problem o drugorzędnym znaczeniu.
Platforma również tworzy koszt
Internal developer platform sama staje się produktem. Wymaga utrzymania, aktualizacji, dokumentacji, integracji, kontroli bezpieczeństwa i zespołu, który będzie reagował na potrzeby użytkowników. Każda warstwa upraszczająca życie developerom tworzy więc po drugiej stronie nowy fragment systemu, który ktoś musi rozwijać i rozumieć.
W średniej firmie ta granica jest szczególnie istotna, bo koszt kilku dodatkowych specjalistów czy utrzymywania własnych komponentów może być relatywnie większy niż w dużej organizacji technologicznej.
Dlatego najbardziej dojrzała wersja platform engineering często wygląda znacznie mniej efektownie, niż sugeruje sama nazwa. Wspólne moduły Infrastructure as Code, ujednolicony CI/CD, automatyczne tworzenie środowisk i kilka dobrze zaprojektowanych mechanizmów samoobsługowych mogą przynieść większość korzyści bez budowania rozbudowanego ekosystemu.
Prawdziwym pytaniem nie jest więc, czy firma jest już wystarczająco duża, żeby mieć platformę. Znacznie ważniejsze jest to, czy koszt powtarzania, koordynacji i oczekiwania stał się na tyle wysoki, iż standaryzacja zaczyna być tańsza niż dalsze działanie po staremu.
Jeżeli tak, platform engineering przestaje być modnym projektem technologicznym i staje się narzędziem porządkowania kosztów. o ile nie, może bardzo gwałtownie stać się kolejnym systemem, który organizacja będzie utrzymywać głównie dlatego, iż kiedyś zdecydowała się go zbudować.
