Wdrożenie DevOps a time to market. Co Cię zaskoczy?

Skrócenie Time To Market – to zdanie prawie jak mantrę słyszymy już od dawna. Od dawna też staramy się skracać czas poszczególnych etapów wytwarzania oprogramowania. Pojawiają się kolejne trendy i zmiany na lepsze – architektura zorientowana na usługi (SOA), infrastruktura jako kod (IAC), mikroserwisy… A gdyby tak naprawdę pomóc w realizacji tego oczekiwania? Jakie kroki trzeba podjąć, aby móc powiedzieć: time-to-market został skrócony?

Efektem takiej zmiany mógłby być zoptymalizowany proces wytwórczy skupiony na realizacji wymagań biznesowych. Ten artykuł pomoże Wam w zrozumieniu ścieżki niezbędnej w skróceniu Time to Market dzięki transformacji DEVOPS. 

Dostarczanie wartości biznesowej

Po analizie Epic lub User Story w JIRA i groomingu decydujemy się jako zespół na wydzielenie nowej domeny i tym samym realizację tego wymagania w formie dedykowanego mikroserwisu. Taka forma realizacji sprawia, że zespół jest w stanie bardzo szybko pochwalić się wynikami swojej pracy na środowisku produkcyjnym. Zazwyczaj dzieje się to na koniec sprintu, co pozwala, na regularne i oczekiwane zmiany. To także najprostsza droga do uzyskania najbardziej wartościowego gracza, czyli minimalnego produktu dostarczającego wartość (MVP). Zespołom rozwojowym daje zdecydowanie więcej swobody i minimalizuje prace związane z synchronizacją z innymi obszarami. Aby jednak uzyskać maksymalną efektywność, wszelkie elementy niezbędne do wdrożenia od środowiska deweloperskiego do produkcyjnego muszą być gotowe na żądanie. Do tego celu służy odpowiednia platforma selfserwisowa. 

To tam właśnie znaleźliśmy miejsce, które doskonale łączy Dev i Ops w celu skrócenia Time-To-Market. Ops dostarcza nam platformy usługowe, a Dev w szybki sposób otrzymuje fundament wdrożenia funkcjonalności biznesowej. Ciągła współpraca tych dwóch ról powoduje, że usługi są na bieżąco dostosowywane do potrzeb, dochodzą nowe możliwości, wspólnie dostarczając wartość, która ma bezpośrednie przełożenie na skracanie czasu dostarczenia oprogramowania. Dla programisty pozostaje praca z kodem, zarówno w kwestii realizacji wymagań biznesowych jak i obowiązkowych testów automatycznych dla wytworzonej funkcjonalności.

Takie podejście, jest emanacją podejścia DEVOPSowego w nowoczesnej organizacji, gdzie praca wszystkich zespołów skupia się na tym, co najważniejsze - dostarczaniu wartości biznesowej na produkcję. DEVOPS wymusił transformację naszych zespołów Ops z grup realizujących zlecenia na infrastrukturę i zarządzanie nią, na zespoły dostarczające usługi i platformy selfsewisowe do zarządzania jej wszelkimi elementami niezbędnymi do wdrożenia. Samo powoływanie poszczególnych elementów infrastruktury odbywa się na żądanie, w momencie, kiedy zaistnieje taka potrzeba.

Składniki rozwiązania

Platforma selfserwisowa agreguje wszystkie usługi potrzebne do wdrażania i działania wytwarzanych systemów, pozwala ona na zarządzanie systemy na wielu pozioma. Docelowy zakres funkcjonalności został opisany w poniższych punktach:  

1. Rejestracja mikrousługi i przekazanie do organizacji wszystkich istotnych informacji na jej temat, począwszy od dokumentacji (pobieranej z repozytorium, wcześniej), informacji o dostępności – RPO, RTO, SLA, zastosowanych technologiach (potrzebnych do zarządzania długiem architektonicznym), zasobach infrastrukturalnych, źródłach danych, integracjach, a skończywszy na osobach odpowiedzialnych za utrzymanie
2. Zarządzanie namespace w prywatnym klastrze Kubernetes
3. Provisioning relacyjnych baz danych 
4. Przydzielenie zasobów dla namespace oraz bazy danych z dostępnych koszyków 
5. Provisioning automatycznego workflow zapewniającego proces CI/CD dla mikrousługi
6. Provisioning DNS w celu pozyskania adresu www dla mikrousługi
7. Provisioning topiców na Kafce
8. Utworzenie zestawu użytkowników technicznych 
9. Zarządzaniem testami automatycznymi
1. Funkcjonalne i regresyjne
2. Bezpieczeństwa
3. Wydajnościowe
10. Przygotowanie projektów systemowych w JIRA, WIKI

Mikrousługa i chmura prywatna

Samą mikrousługę, tworzymy na podstawie archetypu i wdrażamy na chmurę prywatną opartą o wewnętrznie zarządzany klaster Kubernetes. Dzięki temu zyskujemy spójność rozwiązania w ramach organizacji. Warstwa persystencji to relacyjna baza danych , a generyczny proces CI/CD wdraża na wszystkich rodzajach środowisk od deweloperskich do produkcji. W procesie uruchamiane są testy funkcjonalne, wydajnościowe i bezpieczeństwa, zapewniana jest też informacja audytowa. Do kompletu mamy monitoring infrastrukturalny i biznesowy oparty o stos Elasticsearch, Logstash i Kibana (ELK).

Nasza chmura prywatna, czyli wspomniany wyżej klaster Kubernetes wraz z narzędziami do obsługi i monitoringu, to miejsce, gdzie zespoły wytwórcze w prosty sposób mogą osadzać swoje aplikacje, zarządzając infrastrukturą w sposób deklaratywny. Jej skalowanie odbywa się na podstawie monitorowania obecnej utylizacji i procesu capacity planningu, ale w kontekście całego klastra, a nie pojedynczych usług. Mikrousługi osadzone w namespace’ach są w odpowiedzialności zespołów rozwojowych, które na podstawie planów wykorzystania, lub empirycznych doświadczeń zarządzają zasobami takiej mikrousługi (CPU, storage, RAM). Dodatkowo standardem jest zdefiniowana polityka autoskalowania dla każdej z usługi, tak aby dynamicznie reagować na wzrost obciążenia i nie dopuścić do awarii.

Zasoby podzielone są na obszary biznesowe, do których przypisane są zespoły rozwojowe i na bieżąco zasilane wraz z definiowaniem wymagań biznesowych. Oczywiście każdy „koszyk” zasobów posiada odpowiedni bufor, aby bez czekania na fizyczne dostarczenie zasobów można było rozpoczynać pracę i np. wdrażać prototypy. Takie podejście do zarządzania zasobami infrastrukturalnymi sprawia, że łatwo zarządza się także finansami związanymi z infrastrukturą.

To przekłada się na transparentne przedstawianie rachunków dla konkretnego obszaru biznesowego. Niekiedy w dużych organizacjach takie podejście sprawia problemy, np.: gdy szukamy finansowania części infrastrukturalnej rozwiązań informatycznych. 

Platform team także dla monolitów

Platforma selfserwisowa zapewnia komplet usług, który sprawia, że próg wejścia w architekturę mikroserwisową staje się niski, ale wspiera ona również świat monolitów, gdzie mamy do czynienia z tradycyjną architekturą. Żeby jednak platforma miała konkretną ofertę, to Ops musi się przestawić na rozwiązania oparte na usługach. To, co do tej pory było solą pracy administratorów, staje się narzędziem w rękach programistów. Ops stają się twórcami automatów, usług i platform. Utrzymują je oraz rozszerzają o kolejne zmiany, które przynosi technologia.

Budowanie usług po stronie Ops stało się ogromnym wyzwaniem. Wymusza to uzyskanie dodatkowych kompetencji, ale także większe zaangażowanie w komunikację z Dev. Zbliżenie tych dwóch ról pozwoliło na zdefiniowanie oczekiwań oraz przygotowanie strategii na zmianę modelu na usługowy. Ta formuła pozwala dużym firmom na przeprowadzenie transformacji bez rewolucyjnych zmian organizacyjnych, a z drugiej strony jasno definiuje cel dla wszystkich w IT.

W duchu powyższych pryncypiów przy współpracy Dev i Ops został utworzony, i jest rozwijany wspomniany powyżej zestaw usług dla środowiska mikroserwisów. Ich zadaniem jest wsparcie codziennej pracy zespołów wytwórczych i ułatwienie dostępu do najbardziej potrzebnych funkcjonalności w procesie wytwarzania oprogramowania. Oprócz nich wytwarzane są też usługi, które optymalizują wewnętrzne działania Ops, np.: provisioning maszyn wirtualnych realizujący ideę IaC i standaryzujący środowisko pracy w zakresie infrastruktury monolitycznej oraz dostępnych technologii. 

Innymi przykładami są: zarządzanie ruchem sieciowym, backup na żądanie lub provisioning nazw DNS, co przekłada się na kolejne usługi dostępne w modelu self-service bezpośrednio dla potrzebujących Dev.

Weryfikacja/audyt

Cesarzowi co cesarskie - każda duża organizacja ma swoje procesy, procedury i wymagania audytowe, które często stają się dodatkowymi wymaganiami w procesie wytwarzania oprogramowania. Zbudowanie odpowiedniej platformy selfserwisowej oraz usług w niej serwowanych powinno być zgodne z oczekiwaniami organizacji. W tym kontekście możemy wskazać kilka zachodzących zmian:

• Rejestr aplikacji, z którego organizacja raportuje do organów zewnętrznych operując na rynku regulowanym
• Zapewnienie informacji zarządczej dotyczącej właścicielstwa systemów, osób odpowiedzialnych za rozwijanie i utrzymanie oraz dostępności systemu
• Zarządzanie użytkownikami technicznymi w kontekście ról i uprawnień 
• Zarządzenie dostępem do danych (Kafka, uprawnienia do mikro)
• Zarządzanie zasobami infrastrukturalnymi i ich finansowaniem 

Commit;

Efektem transformacji DEVOPS jest stworzenie środowiska, w którym „dobre” oprogramowanie może powstawać bez oczekiwania na infrastrukturę, skomplikowanego procesu wdrażania czy zbędnych formalności, które mogą blokować szybkie dostarczanie wartości biznesowej. Optymalizacja tego strumienia prac ma na celu ustandaryzowanie i przyspieszenie wdrażania zmian oraz podniesienie jakości dostarczanych rozwiązań i ich stabilności. DEVOPS opiera się o partnerstwo w relacji pomiędzy programistami i administratorami – dlatego komunikacja, współpraca i integracja w codziennym działaniu to efekt udanej transformacji.  

Zespół Transformacji DEVOPS