W dzisiejszym świecie technologii coraz częściej słyszymy o konieczności wdrażania kompetencji DevOps w projektach. Ale co to właściwie oznacza? Czy DevOps zawsze działa tak samo w każdej firmie? W artykule określę kluczowe filary DevOps, przedstawię koncepcję DevOpsSup (jako odpowiedź na zmieniające się potrzeby projektów) oraz omówię, kiedy warto zastanowić się nad przejściem do modelu Platform Engineering.
Podczas realizacji każdego projektu, dochodzimy do fazy, kiedy nasz produkt, mniej lub bardziej gotowy, musi zostać wdrożony na produkcję i tym samym udostępniony użytkownikom. Pozornie to właśnie tutaj pojawia się potrzeba włączenia do projektu kompetencji DevOps. DevOps w założeniu połączenie kompetencji programistycznych i operacyjnych brzmi, również pozornie, jak precyzyjnie zdefiniowany zakres kompetencji. Moim zdaniem jednak tak nie jest, i to nawet pomimo tego, że hasło DevOps pojawia się w przestrzeni już od wielu lat.
„Obecnie DevOps przypomina bardziej ruch filozoficzny, a nie precyzyjny zbiór praktyk, opisowych czy normatywnych”
Gene Kim
Idea DevOps
DevOps w moim rozumieniu tego pojęcia, jest to zbiór kompetencji potrzebnych do:
- skutecznego wsparcia developerów – zapewnienia im środowisk i narzędzi do realizacji backlogu produktu, nie do pisania kodu samej aplikacji,
- realizacji elementów backlogu projektu – dedykowanych do obszaru DevOps, opisanych poniżej w ramach modelu DevOpsSup,
- elastycznego operowania środowiskami – np. na potrzeby realizacji testów przez obszar QA projektu,
- odpowiedzialności za produkt – dostarczania go i utrzymywania na wymaganych środowiskach, aby zapewnić jego dostępność dla użytkowników (zarówno wewnętrznych – projektowych, jak i zewnętrznych – docelowych).
W jednym z polskich software house’ów budowałem od podstaw framework usługi DevOps i zespół go realizujący. Zdefiniowałem wtedy pojęcie rozszerzonego podejścia DevOps, czyli DevOpsSup, gdzie kompetencje podzieliłem na trzy obszary:
- Dev – tworzenie architektury rozwiązań, czyli automatyzacja budowy środowisk (IaC np. Terraform), procesów ciągłej integracji i dostarczania (CI/CD np. Jenkins) z wykorzystaniem języków sktyptowych (np. Bash, Python),
- Ops – zarządzanie rozwiązaniami, czyli faktycznego wdrożenia środowisk i produktów (przygotowanych przez obszar Dev), konfiguracja monitoringu rozwiązań, budowa bazy wiedzy oraz proaktywność (hypercare),
- Sup – wsparcie rozwiązań, czyli zapewnienie w trybie ciągłym wsparcia operacyjnego, z uwzględnieniem rozwiązywania incydentów, identyfikacji problemów, zarządzaniem zmianą (ITIL) – oraz – dostarczaniem danych/logów/raportów do obszarów Dev i Ops, oraz do samego projektu.
DevOps jest właśnie, frameworkiem, który możemy elastycznie dostosować do wymagań projektów, jakie obecnie realizujemy. Nie udało mi się dotychczas zidentyfikować dwóch firm, w których zarówno rozumienie, jak i wdrożenie tego obszaru wyglądałoby identycznie. Nawet drobne różnice, powodują, że zapewnienie optymalności przyjętych rozwiązań, wymusza ich różnorodność. Inżynier DevOps w jednej firmie może mieć zupełnie inny zakres kompetencji, obowiązków i wiedzy, niż w innej, nawet podobnej organizacji. Te różnice mogą (a czasami wręcz powinny się pojawić) nawet w przypadku dużego zróżnicowania projektowego w ramach jednej organizacji.
Wyzwania DevOps w cyklu życia projektu
Realizując w ramach działalności organizacji jeden projekt, bardzo trudno jest efektywnie zaalokować kompetencje DevOps w ramach jego cyklu życia (SDLC). Kierownik Projektu stara się dostarczyć wartość, balansując w ramach trójkąta ograniczeń projektowych. W przypadku kompetencji DevOps, stany idealne dla poszczególnych jego elementów wyglądałyby następująco:
- czas – posiadanie nieograniczonych i zawsze dostępnych kompetencji DevOps, aby minimalizować czas potrzebny do dostarczenia wartości,
- zakres – precyzyjny i niezmienny zakres zadań dla kompetencji DevOps, aby precyzyjnie zaplanować zapotrzebowanie tych kompetencji,
- jakość – posiadanie najwyższego poziomu seniority kompetencji DevOps, aby móc dostarczyć możliwie wysoką jakość wynikającą z realizacji tych zadań,
- koszt – angażowanie kompetencji DevOps w tak niewielkim zakresie, w jakim jest to możliwe do dostarczenia wartości.
Oczywiste jest, że nie da się jednocześnie osiągnąć wszystkich tych elementów. Potrzebny jest optymalny kompromis pomiędzy poszczególnymi elementami oraz efektywne zarządzanie związanymi z tym ryzykami. W przypadku jednego projektu lub kilku mniejszych projektów będzie to utrudnione. Jako organizacja musimy zapewnić te kompetencje, pomimo tego, że zapotrzebowanie na nie może być mocno zmienne, w zależności od etapu projektu, na którym jesteśmy. Zupełnie inaczej będzie to wyglądało na etapie planowania lub analizy (ograniczony zakres zadań, stosunkowo łatwe do określenia zaangażowanie obszaru DevOps), inaczej na etapie realizacji projektu (w przypadku realizacji projektu metodykami zwinnymi zarówno zakres zadań jak i zaangażowanie czasowe może charakteryzować się wysoką zmiennością), a etap utrzymania finalnego rozwiązania może być wręcz niemożliwy do oszacowania na samym początku projektu (chociażby dlatego, że nie wiemy jakiej zmienności zostanie poddany początkowy zakres projektu oraz jakiej jakości będzie finalny produkt).
Jeśli jednak nasza organizacja realizuje wiele projektów, warto rozważyć stworzenie osobnego obszaru kompetencyjnego DevOps, i na zasadzie shared center, współdzielić te kompetencje między projektami. Manager tego obszaru będzie mógł, mając obraz wymagań wszystkich projektów, odpowiednio zbudować te kompetencje, jak i elastycznie nimi zarządzać w czasie. Pozwoli to na optymalizację kosztów, poprawę jakości oraz niezawodności dostarczanych produktów. Nie jest to zadanie łatwe. Wymaga ono dużego zaangażowania lidera tego obszaru oraz efektywnej współpracy całej organizacji. Finalnym efektem może być zespół, który wspierając wiele projektów jednocześnie w ramach różnych technologii, może również rozwijać się kompetencyjnie i budować nowe rozwiązania, zarówno dla organizacji, jak i dla jej klientów.
Posiadając pełną dojrzałość tego obszaru (w stosunku do potrzeb organizacji i jej projektów), warto rozważyć wdrożenie bootcamp’u, który zapewniłby napływ nowych osób. Juniorzy wyszkoleni wewnętrznie w ramach tego programu przejmowaliby proste zadania od osób bardziej doświadczonych. To może zapewnić tym osobom przestrzeń do wcześniej wspomnianego rozwoju kompetencji, jak i całej organizacji.
Platform Engineering, czyli ewolucja DevOps
DevOps w wyżej opisanym modelu może się dobrze sprawdzać w wielu organizacjach. Jednakże w sytuacji, kiedy portfolio projektów i tym samym liczba wspieranych przez obszar DevOps rozwiązań systematycznie się zwiększa, może to być sygnał do rozważenia kolejnego kroku. Sygnał do ewolucji modelu rozwoju DevOps w model Platform Engineering. O ile DevOps jest bardziej skupiony na projektach i procesach, o tyle Platform Engineering skupia się na centralizacji infrastruktury, narzędzi i środowisk. Zespoły projektowe, w uproszczeniu, zamiast agregowania w nich kompetencji DevOps, otrzymują gotowe rozwiązania od zespołu Platform Engineering. Rozwiązania takie są zunifikowane i zoptymalizowane, co pozwala na ich bardziej efektywne utrzymanie, rozwój i wsparcie. Oczywiście, wybór finalnej drogi, rozwiązań i podejścia jest uwarunkowany potrzebami konkretnej organizacji. Nie w każdym przypadku model DevOpsSup sprawdzi się idealnie, jest on jednak na tyle elastyczny, że można od niego zacząć, i dopasować go zarówno na poziomie pojedynczego projektu, jak i całego portfolio danej organizacji.
Menedżer z doświadczeniem w zarządzaniu projektami, produktami i procesami, koncentrujący się na efektywności i jakości. W pracy kładzie duży nacisk na współpracę zespołową, uznając ją za kluczowy czynnik sukcesu. Uwielbia dzielić się wiedzą i inspirować innych do rozwoju. Posiada doświadczenie w budowaniu i rozwijaniu obszaru kompetencji DevOpsSup, który wykraczał poza standardowe ramy DevOps. W trakcie tego procesu opracował model usług DevOps nastawiony na skuteczność i przyszły rozwój.