Idea Playbook Engineering powstała, aby zredukować do minimum codzienne „wrzutki” i skupić się na dowożeniu dużych celów. Pod hasłem „you code it, you test it, you ship it” skupiamy się teraz na dostarczaniu narzędzi i procesów tak, aby każda domena biznesowa mogła samodzielnie, sprawnie dostarczać funkcjonalności i poprawki. Po pół roku tutaj z dumą mogę stwierdzić, iż się nam to udaje – mówi Jakub Zięba.
Cześć! Na początek chciałabym Cię spytać o specyfikę modelu biznesowego Playbook Engineering. Co ją wyróżnia? Jak ten model wpływa na zarządzanie infrastrukturą oraz kulturę DevOps w firmie?
Playbook to dostawca platform iGaming, działający stricte business to business — nie jesteśmy klasyczną firmą utrzymującą jedną dużą aplikację czy sklep internetowy. Nasi klienci to tzw. „operatorzy”, czyli przedsiębiorcy i firmy posiadający licencje na prowadzenie tego typu działalności. Dla naszej devopsowej rzeczywistości implikuje to konieczność zarządzania bardzo dużą ilością takich platform, a co za tym idzie — środowisk. Nie mamy tutaj zatem do czynienia z klasycznym „dev, stage, prod”.
Warto też dodać, iż nie jest to typowe podejście single-tenant — każde nasze „środowisko” może mieć wdrożone wiele platform. Wynika to m.in. z rygoru przepisów w danej części świata. Platformy te współdzielą komponenty, odpowiedzialne na przykład za blokowanie kont graczy. Konieczność elastycznego dostosowania platformy do potrzeb różnych klientów powoduje, iż możemy podzielić platformę na „rdzeń” oraz wymienne komponenty odpowiedzialne za dopasowanie jej kształtu pod operatora.
Tak wysoka modułowość i elastyczność naszej platformy to zasługa architektury mikroserwisowej. Mamy też kilka systemów dostarczających dane do wszystkich platform jednocześnie. Stajemy się firmą działającą na globalną skalę, co przyniesie interesujące wyzwania w rozwijaniu ich.
Jak wygląda proces budowania infrastruktury w Playbook Engineering? Jakie narzędzia są używane do tego celu i skąd taki dobór?
Wszystkim zarządzamy poprzez kod, bazując na dogmatach Infrastructure as Code i GitOps. Jak wcześniej wspomniałem, zamiast posiadania kilku typowych „warstw” środowisk, musimy dostarczać i zarządzać wieloma podobnymi. Służy nam do tego Terraform, Ansible, a także ArgoCD.
Dzięki odpowiedniemu budowaniu modułów w Terraformie, a także ról w Ansible wymuszamy, aby ogólny kształt wszystkich środowisk był identyczny. Zmieniają się jedynie szczegóły, które parametryzujemy zmiennymi. ArgoCD z kolei służy nam do zarządzania aplikacjami wdrażanymi na klastry GKE (Google Kubernetes Engine). Ciekawostką jest, iż zdecydowaliśmy się wdrażać po jednym Argo na klaster: spowodowane jest to brakiem możliwości skalowania horyzontalnie ApplicationSet controllera, co przy setkach aplikacji i tysiącach podów ma krytyczne znaczenie.
Czy możesz przedstawić ogólny przegląd stosu technologicznego wykorzystywanego w Playbook Engineering?
Ogólnie patrząc, nasza platforma składa się z mikroserwisów pisanych w Scali i Rust — każdą nową funkcjonalność staramy się implementować właśnie w Rust. Kafka jest event-busem dla całej platformy.
Być może wielu z Was w tym miejscu nasunie się pytanie: „Dlaczego Kafka, skoro budując na GCP mamy pod ręką Pub-Suba?”. Gdy podejmowano tę decyzję, przeważyły funkcjonalności Kafki i łatwość implementacji, ale to miało miejsce dawno temu.
Następnie warstwa baz danych i przechowywania danych: PostgreSQL, Scylla, Elasticsearch oraz GCS. Z bardziej devopsowej strony poza wymienionymi ArgoCD i Terraformem interesujące są: GitLab, Helm, Istio, Grafana Loki, OTEL (jako standard i też narzędzie), OX security jako narzędzie do SAST. Mamy też trochę ciekawych wdrożeń technologii na tapecie na nadchodzący kwartał.
Co dla ciebie wyróżnia Playbook Engineering na tle innych projektów, w których pracowałeś?
Myślę, iż balans pomiędzy sprawnością pracy a jej ustrukturyzowaniem. Zarówno ja jak i inni principale dokładamy wszelkich starań, żeby budować techniczne standardy i procesy tak, aby nie rzucać nikomu „biurokratycznych kłód” pod nogi. Wiadomo, iż dużą rolę odgrywa też tutaj rozmiar organizacji, nie jesteśmy korporacją.
Niemniej zdarzyło mi się pracować w organizacjach o podobnym rozmiarze, gdzie wprowadzenie nowej technologii potrafiło trwać ponad pół roku. Dlaczego? Ponieważ każdy zainteresowany menedżer czy architekt musiał „przybić swoją pieczątkę z ziemniaka” w ściśle sformalizowanym procesie. Tutaj wprowadzenie podobnego narzędzia od koncepcji do rozpoczęcia wdrożenia zajęło około kwartał.
Jak w praktyce sprawdza się metodyka DevOps Playbook Engineering? Możesz pochwalić się sukcesami w tym obszarze?
Tutaj odrobina historii dla tła. Gdy przychodziłem do Playbooka, trwała tu restrukturyzacja naszego departamentu. Wcześniej istniały dwa osobne teamy: Infra i DevOps. Infra zajmowała się stricte budowaniem środowisk w chmurze — sieci, zasoby obliczeniowe itd. DevOps był odpowiedzialny za wsparcie engineeringu, czyli takie rzeczy jak SDLC, ad-hocowe problemy i zarządzanie Kubernetes. Działało to niezbyt dobrze, w związku z czym powstał jeden team odpowiedzialny za całość, w którym każdy członek jest (lub staje się) specjalistą w którymś elemencie naszego stosu.
Ponadto dla całej organizacji zaczęliśmy wdrażać idee Platform Engineeringu, aby zredukować do minimum codzienne „wrzutki” i skupić się na dowożeniu dużych celów. Pod hasłem „you code it, you test it, you ship it” skupiamy się teraz na dostarczaniu narzędzi i procesów tak, aby każda domena biznesowa mogła samodzielnie, sprawnie dostarczać funkcjonalności i poprawki. Po pół roku tutaj z dumą mogę stwierdzić, iż się nam to udaje i obranie takiej strategii to była najlepsza możliwa decyzja.
A jakie wyzwania niesie ze sobą dynamiczny wzrost firmy, zwłaszcza w kontekście infrastruktury i zarządzania nią?
W wielu firmach biznes czy dział operations nie rozumie, jak dokładnie przekłada się praca teamów czy departamentów odpowiedzialnych za infrastrukturę lub DevOps na ich sukces. Pod kątem rozumienia i implementacji funkcjonalności jesteśmy najdalszym zespołem w stosunku do typowych zespołów produktowych. Od nas jednak zależą najważniejsze czynniki takie jak:
- Sprawność łańcucha dostarczania funkcjonalności,
- Dostarczanie infrastruktury, na której te funkcjonalności mają się znaleźć,
- Zapewnianie stabilności i bezpieczeństwa produktu oraz tolerancji na awarie.
Gdy firma oferująca PaaS lub SaaS znajduje się w punkcie, w którym celem jest 2-,3-, czy 10-krotny wzrost, wiele rozwiązań sprawdzających się w małej skali przestaje mieć rację bytu. Nie inaczej jest w tym przypadku, gdzie w dość krótkim czasie musieliśmy przestać traktować kolejne platformy jako indywidualne byty idące własnym torem. Gdy taki sam team zaczyna być odpowiedzialny za 3-4 razy tyle środowisk, co rok wcześniej, konieczne jest, aby skupić się na zarządzaniu całą flotą jednocześnie, a nie każdym środowiskiem z osobna.
Jak wyglądała Wasza droga od zarządzania kilkoma środowiskami do zarządzania flotą środowisk?
Pipeline do aktualizacji repozytoriów „cluster-state” utworzyliśmy jako job w Gitlabie, dla wszystkich nowego środowiska automatycznie dodawany był nowy job, który uruchamiano manualnie.
Już na pierwszy rzut oka widać, iż nie skaluje się to wraz z organizacją. Konieczne stało się obudowanie całego tego kawałka dodatkową logiką, aby ktokolwiek mógł wdrożyć nową wersję swojego serwisu na wszystkie docelowe dla niego środowiska na raz.
Podobnie ma się kwestia zarządzania infrastrukturą: przepisujemy nasz codebase tak, aby składał się z modułów maskujących większą logikę biznesową. Moduł u nas ma nie tylko redukować kopiowanie kodu, ale też stanowić sztywne ramy każdego „kawałka” środowiska. Gwarantuje to spójność środowisk oraz łatwość propagacji zmian.
Kolejnym krokiem jest automatyzacja samego wdrażania zmian na infrastrukturze. Tutaj z pomocą przychodzą nam narzędzia takie jak Atlantis — wykorzystanie go pozwala zacieśnić nam szare strefy wykonania zmiany na infrastrukturze do zera. Każdy terraform apply ma być wykonany zdalnie, a nie z komputera inżyniera.
Jakie są główne wyzwania związane z wdrażaniem systemu dla wielu środowisk jednocześnie?
Największe wyzwanie, to jak w ogóle ugryźć ten problem. Już związaliśmy się z logiką ArgoCD, co narzuca na nas ostateczną formę wdrożenia na każdym środowisku — poprzez zmianę w repozytorium przechowującym stan środowiska. Wyklucza to nam wiele tradycyjnych narzędzi do wdrożeń na K8S, ponieważ takie zorientowane są na aktualizację zasobów rezydujących na klastrze, kolidując z ArgoCD. Zostaje nam zatem utworzyć pipeline, który będzie operował na repozytoriach, a nie adekwatnych klastrach.
Tak, jak wspomniałem wcześniej, mamy mikroserwisy-rdzeń oraz takie, które dodajemy lub nie, w zależności od oczekiwanego kształtu platformy. Rodzi to problem niejednorodności środowisk, który znacznie utrudnia zarządzanie CD.
Na koniec: możesz podzielić się swoim osobistym spojrzeniem na to, czym jest rola inżyniera DevOps i jakie są główne cele tego stanowiska?
DevOps to taki specjalista-majster od problemów wszelakich, żartobliwie mówiąc. A już całkiem poważnie, to funkcja przenosząca obszar zarządzania infrastrukturą i wdrożeniami w erę automatyzacji procesów i systemów. To, co kiedyś było zestawem maszyn z Linuksem, fizycznym firewallem itd., staje się teraz API wirtualnej usługi. Zestawem wysokich technologii oferujących swoje abstrakcje i unikalne funkcjonalności.
Inżynier DevOps to specjalista wykorzystujący wiedzę z tych zagadnień, aby usatysfakcjonować cele biznesowe takie, jak:
- Możliwie najsprawniejszy, najszybszy proces technologiczny
- Automatyzacja systemów i zadań
- Wsparcie przy problemach związanych z infrastrukturą
- Budowanie środowisk w oparciu o wcześniej wspomniane wysokie technologie
- Rozwój systemu — Development i niegdysiejsza inżynieria systemów: Infrastructure Operations zacierają się w tym podejściu. Stąd branżowy skrót DevOps.
Dodam też, iż nasza dyscyplina bardzo gwałtownie ewoluuje, obserwujemy nowe obszary specjalizacji, które z niej wynikają:
- Site Reliability Engineering — specjaliści od stabilności usługi
- DevSecOps — ludzie wplatający bezpieczeństwo w automatyzację organizacji
- Platform Engineering — dyscyplina skupiająca się całkowicie na budowaniu automatycznych narzędzi i procesów dla innych departamentów, aby mogły samodzielnie dostarczać swoje rozwiązania.
Jakub Zięba. Principal DevOps Engineer w Playbook Engineering. Zawodowo linuksiarz, specjalista od infrastruktury, SDLC i SRE. Prywatnie trochę sportowiec, trochę fotograf, trochę fan szwendania się po górach i lasach. Jak w pasji tak i w życiu i pracy wyznaję zasadę „nigdy nie przestawaj poszukiwać”.
Zdjęcie główne pochodzi z Envato Elements.
