#16 DevOps – kim jest i czym się zajmuje? Łukasz Kasprzak.

Anika to jakoś złączy, to o tym się nie przejmujesz. Ale nie moimi słowami muszę to też powiedzieć. To byłoby wyzwanie, jakbyś skleiła siebie jeszcze z naszymi wypowiedziami. Tyle. Cześć, z tej strony Nikodem. Witam w kolejnym podcaście DEVision. Dzisiaj w studio jest ze mną Łukasz Kasprzak, z którym będę rozmawiał o roli DevOpsa. Cześć, Łukasz. Cześć, Nikodem. Zanim przejdziemy do tematu, chciałbym żebyś opowiedział nam kilka słów o sobie.

Od 20 lat związany jestem z branżą IT. Zaczynałem jako developer PHP. Następnie spróbowałem swoich sił w Javie, w C-Sharpie. Następnie próbowałem troszeczkę więcej zaangażować się w zarządzanie i management. Zostałem engineering managerem. Od roku pracuję w firmie Satago jako head of engineering. Buduję zespoły, wprowadzam nowe rozwiązania. Niedawno pojawiła się potrzeba zatrudnienia pierwszego DevOpsa w firmie, więc opowiem Wam tutaj o moim doświadczeniu w tym procesie. Zaczynałem swoją karierę jako programista. W ogóle nie zdawałem sobie sprawy z czegoś takiego, że istnieje taka rola jak DevOps. Myślę, że przepracowałem swoje pierwsze dwa lata, po czym dowiedziałem się, że pracowałem na stanowisku DevOps.

Także czasami powiem Ci, że to nie jest takie jasne, na czym ta rola polega. Jakbyś opisał, co Twoim zdaniem znaczy być DevOpsem. No, spoko. Tutaj też może trzeba zacząć od tego, że DevOps to Development and Operations. Nie powinna być rola. To jest zestaw umiejętności, które dany pracownik powinien gdzieś wykonywać. Wspomagając zespół deweloperski. I co tutaj możemy robić? Możemy wspomagać właśnie cały proces Software Development Life Cycle tak, aby on był w miarę spójny i żebyśmy nie musieli przenosić tej pracy pomiędzy różnymi zespołami, a wykonywali wszystko W jednym zespole. No i nie wiem, pewnie jak byłeś tym devobsem, nie wiem na czym polegała tutaj ta twoja praca. Natomiast ja sobie wyobrażam, że kiedyś właśnie tutaj był bardziej jakiś system administratorzy, którzy gdzieś tam, nie wiem, budowali fizyczne serwerownie gdzieś na zapleczu, łączyli kablami te serwery, budowali sieci, routery i tego typu rzeczy i potem przekazywali dalej tą pałeczkę, nie?

No więc tutaj jak najbardziej ta osoba ze skillami DevOpsa ma pole do popisu. Jako osoba techniczna rozumiem, o czym mówisz, natomiast nie każdy z naszych widzów jest osobą techniczną, tak że jakbyś mógł tak troszkę bardziej ogólnie opowiedzieć o tym, jak wygląda ten proces cały, Day Zero, Day One i tak dalej. Jasne, a więc myślę, że możemy się cofnąć właśnie tutaj, zacząć jeszcze raz. Kiedyś, nie wiem kiedy, 20 lat temu, Bezpieczna data. Bezpieczna data, tak. Prawdopodobnie cały proces zaczynał się od jakiegoś kosztorysu, zbudowania planu, co będziemy potrzebować, jakiego typu serwerów, jakie one powinny mieć procesory, ile pamięci powinny mieć.

W mojej opinii, tak jakby szukaliśmy optymalizacji w software, no i w czasach, kiedy mamy już rozwiązania cloudowe, nie ma potrzeby, aby te serwery fizycznie gdzieś trzymać. Możemy je sobie zażądać na żądanie, one będą gotowe dla nas po minucie. Więc to działa, to pomaga. W jaki sposób tutaj DevOps może pomóc? Oczywiście możemy użyć jakiejś konsoli AWS-owej, gdzieś sobie wyklikamy, że chcemy mieć serwer, on będzie stał, będzie gotowy, tylko że za chwilę możemy mieć potrzeby, aby postawić drugi taki sam serwer, z takimi samymi ustawieniami. No trzeci, czwarty. Jeżeli będziemy to wyklikiwać, bardzo szybko zapomnimy o jakichś ustawieniach, że coś zmieniliśmy, że coś tam było zmienione i no mamy te serwery w różnym stanie.

Jeżeli to funkcjonuje, możemy promować nasz obraz na wyższe środowiska, na przykład jakieś QA-owe, gdzie będziemy mieć zespół ... testerów, którzy będą już wykonywać większy zakres testów. No i następnie promujemy nasze zmiany już powiedzmy na staging bądź produkcję. No i wszystkie te etapy, one powinny być takie same, tak samo zbudowane. Więc tutaj już w tym poprzednim kroku to zbudowaliśmy, teraz właśnie budując ten cały nasz pipeline delivery, który jest też częścią właśnie roli DevOps. Pozwala nam zaoszczędzić i za pomocą jednego kliknięcia bądź nawet jednego commitu do repozytorium striggerować, wyzwolić taki proces i mieć to już tak jakby dostępne dla osób nietechnicznych, aby sobie mogli przetestować.

No to właśnie tak wyglądała mniej więcej moja rola jako devopsa. Jak przychodziłem do projektu, mieliśmy tak, że produkt, który tworzyliśmy, trzeba było ręcznie zbudować. Po tym jak, powiedzmy, deweloper skomitował swój kod, musieliśmy ręcznie uruchomić różnego typu komendy, żeby stworzyć, zbudować ten kod. Później trzeba było ręcznie wgrać na jakąś maszynę, na której znowu ręcznie uruchamialiśmy testy. I jednym z takich moich zadań było zautomatyzowanie całego tego procesu, czyli tworzyliśmy tzw. pipeline, po tym jak użytkownik wgrywa swój kod, uruchomić jakieś wstępne testy, zbudować paczkę, wgrać ją automatycznie na serwer i uruchomić automatycznie kolejne testy. Także cieszę się, że potwierdziłeś mi, że faktycznie byłem DevOpsem na początku.

Czy ten Day 2 jeszcze nie został opisany? Nie, Day 2 jeszcze nie został opisany. Więc Day 2 to już jest właśnie, gdy nasza aplikacja jest na produkcji, kiedy już ona działa. No i tutaj mamy inny znowuż zestaw problemów. Mamy np. coś takiego jak Observability, gdzie musimy obserwować, czy ta aplikacja faktycznie działa, w jaki sposób działa, czy nie brakuje pamięci, czy nie brakuje dysku, jaka jest przepustowość sieci, No, czy serwisy pomiędzy sobą się komunikują. No więc tutaj też jako osoba DevOps, aby ściągnąć tego typu niefunkcjonalne, powiedzmy to, wymagania położone na aplikacje, może wziąć na siebie i na infrastrukturę. No i tutaj np. z pomocą przychodzi nasz, dla nas cały Kubernetes, w którym aplikacje deployujemy i na naszym Kubernetesie możemy właściwie mieć zestaw narzędzi, który będzie uniwersalny do wszystkich aplikacji, które tam

Zdeployujemy. Czyli w czym to może pomóc? Na przykład zbieraniem logów z poszczególnych aplikacji. Tutaj jako programista aplikacji nie musimy się martwić, gdzie te logi trafią, w jaki sposób będziemy je czytać, tylko po prostu piszemy wymagania funkcjonalne, biznesowe. Natomiast sam Kubernetes potem zbiera nam logi, Przesyła je w jakieś miejsce, no i tym zajmuje się DevOps. No i tutaj możemy je przesyłać teraz właśnie w cloudzie, gdy mamy potrzebę skalowania, gdy mamy już nie tylko jedną instancję z aplikacją, mamy ich wiele, no i może wystąpić jakiś problem, potrzebujemy sprawdzić, gdzie to się działo, więc tak wchodząc na każdy z tych maszyn, która działa, która ma uruchomioną aplikację, może to być ciężkie do Znalezienia.

Więc taki agregator właśnie logów nam tutaj pomaga, że on zbiera te logi ze wszystkich tych naszych instancji, wysyła w jedno miejsce, no i tam sobie możemy poprzez ładne UI zadać zapytanie, przeszukać, sprawdzić, jak wyglądała komunikacja, skąd przyszedł request, gdzie dalej on poszedł, no i jaki był problem. Więc to jest też taki właśnie observability tutaj, które pomaga nam w utrzymaniu tej aplikacji, żeby ona faktycznie działała i żebyśmy byli tego pewni, że ona działa. Tym samym odpowiedziałeś na moje kolejne pytanie, mianowicie planowałem zapytać Cię, czy rola DevOpsa kiedyś się kończy w projekcie, czy jak ustawimy już powiedzmy cały Continuous Integration, Continuous Delivery czy Deployment, czy jest coś jeszcze do zrobienia dla DevOpsa, ale rozumiem, że to jest taka rola, która będzie bardzo długo jeszcze.

Mamy się w projekcie i będzie potrzebna taka osoba praktycznie, bo to jednak trzeba śledzić. W momencie, w którym coś się wywali, trzeba szybko reagować i nie kłatać dziury. To są jeszcze inne aspekty tutaj, pewnie, które DevOps będzie musiał pomagać. Wszystko, co jest związane z security na przykład. W dzisiejszych czasach trudno sobie wyobrazić aplikację, która na przykład nie supportuje HTTPS. Nie wiem, pewnie kiedyś trzeba było te certyfikaty samemu gdzieś kupić, dbać o to, kiedy one wygasną, pilnować, żeby tutaj nie było problemów. No tutaj właśnie taką rzecz możemy gdzieś przerzucić na DevOps. Możemy skorzystać z takich serwisów jak Let's Encrypt i wtedy jest to częścią naszej infrastruktury, tak jakby requestowanie świeżego certyfikatu, dbanie o to, że ten certyfikat jest ciągle up-to-date, rotowanie go.

No i jako programista kompletnie się tym nie przejmujesz, natomiast jest to zrzucone na tą infrastrukturę i jeżeli to jest zautomatyzowane, no to jako DevOps w sumie też nie powinieneś się tym przejmować. Może powinieneś mieć jakiś alerting, monitoring, właśnie cały stack observability, żeby wykryć wcześniej, czy faktycznie to wszystko nam działa. Ale to pomaga i zdejmuje powiedzmy z deweloperów pewne takie rutynowe czynności albo powtarzające się czynności, które nie są związane z aplikacją, którą budujemy. Zastanawiałem się jeszcze na czym polega rola właśnie DevOpsa, kim jest ta osoba. Szukałem jakichś Artykuł w internecie i trafiłem na jeden taki, który tłumaczył, że rola devopsa w ogóle może różnie wyglądać, w zależności od firmy, nawet w jednej firmie w różnych zespołach inaczej będzie wyglądała ta rola i były przedstawione takie różne modele, przykładowo zespół,

Kilku deweloperów, wśród których jedna osoba to jest DevOps. Inny model był taki, że cały zespół składał się z DevOpsów, albo jeszcze inny model, w którym DevOps był dzielony między trzy różne zespoły. Coś mógłbyś powiedzieć na ten temat? Tak, no to jest... Powiedzmy, różne modele budowania zespołów. Tutaj w zależności od tego, ile potrzebujemy pracy poświęcić, pewnie na zbudowanie naszej infrastruktury, możemy przyjąć inne modele. W mojej opinii najbliżej mojemu sercu jest właśnie taka osoba, która współpracuje z zespołem i budowanie takich zespołów cross-funkcyjnych, czyli nie tylko będziemy mieć osobę DevOps, ale będziemy mieć również QA, Front-end inżyniera, back-end inżyniera i taki zestaw różnych skillsetów razem jako zespół powoduje, że ten zespół jest samowystarczalny.

On może zbudować EUI, może zbudować back-end, może zbudować infrastrukturę, ulepszyć proces CI. I wszystko przetestować na koniec. Tak, i wszystko przetestować. Nie musi chodzić, nie musi prosić, nie musi pytać, czy ktoś ma moce przerobowe, kiedy mu to zrobią, tylko sam to robi. No więc pewnie u nas w firmie tak staramy się zbudować zespoły. Natomiast no też jestem sobie w stanie wyobrazić, że gdy mamy jakieś takie bardziej skomplikowane infrastruktury, które potrzebujemy zbudować i te osoby DevOps potrzebują ze sobą też rozmawiać i oni kooperować, Może być potrzeba zbudowania osobnego zespołu właśnie DevOpsowego. No nie wiem, możemy tutaj sobie zastanowić się po jakieś takie machine learningowe zestawy, gdzie procesujemy dużą ilość danych i może nie mamy samych takich deweloperów, tylko potrzebujemy całą tą infrastrukturę mieć taką dobrze skalowalną i wtedy

Może nie potrzebujemy tak dużo java developerów albo frontend inżynierów, ale potrzebujemy właśnie tych skillów, które na jakimś tam cloudzie nam pozwolą łatwo skalować aplikacje, które będziemy tam uruchamiać. Czy twoim zdaniem DevOps jest potrzebny w każdym zespole? Myślę, że nie, ponieważ są zespoły pewnie dojrzałe, które są samowystarczalne już na takim etapie i wiedzą, jak zbudować tam infrastrukturę, jak jej używać i wtedy same sobie to zrobią. Zazwyczaj są to może jakieś mniejsze firmy, które zatrudniają pięciu osób. No i tak jakby łatwo jest określić, czego potrzebują.

Natomiast gdy firma się rozrasta, gdy potrzebujemy zacząć korzystać z rozwiązań, które są na rynku i zacząć się uczyć nowych technologii, na przykład Kubernetesa, no to może to być dosyć duży próg wejścia dla osób, które nie wiedzą, jak to funkcjonuje, aby takie coś wprowadzić w firmę. Więc tutaj taka osoba DevOps, która już ma do czynienia z taką technologią, która wejdzie do firmy i która pokaże, jak tego używać, no na pewno jest to pomocne. Zazwyczaj takie osoby zainteresowane tą ścieżką DevOps, one się interesują całym tym systemem dookoła, już nie tylko powiedzmy Terraformem, ale wszystkim dookoła, które się dzieje. No i to pomaga, samo na przykład takie zainteresowanie, co możemy uzyskać z tego Kubernetesa, w czym on nam może pomóc, no bo możemy powiedzieć, że to pomoże nam tylko uruchamiać obrazy dockerowe i tutaj skalować się horyzontalnie.

Ale tam jest mnóstwo innych funkcji. No i nie wiem, teraz zapoznanie się z tym wszystkim od zera jest ciężkie. Zgadzam się. Jako programista raczej nie mam na tyle czasu, żeby siąść i wszystkie na przykład serwisy na AWSie też prześledzić, zrozumieć o co w nich chodzi i korzystam z takiego, które jest mi najwygodniejsze, dla mnie najwygodniejsze, a nie prześledziłem. Być może jest jakieś, które lepiej by pasowało do naszej sytuacji. Tak jak mówiłem, zaczynałem pracę jako DevOps i jednym z takich narzędzi, którego musiałem się nauczyć, był Jenkins. Później z czasem doszedł jakiś Docker, troszeczkę Kubernetesa, jakieś inne narzędzia podobne do Jenkinsa, na przykład korzystaliśmy z Argo. Jestem ciekaw, jakich narzędzi teraz powinien się uczyć DevOps.

Czy masz jakąś taką listę, która uważasz, że dobry DevOps powinien znać i rozumieć? No, to pewnie zależy od wymagań firmy, ale tak jak już wspomniałeś, tutaj samo Argo, jest to ciekawy koncept powiązany z czymś takim, co się nazywa GitOps. Nie wiem, czy korzystałeś właśnie z Argo CI-CD, czy też z Argo Workflow. No, ale tutaj właśnie to jest taka Osobna metodologia, podejście do problemu, w jaki sposób te deploymenty mają wyglądać. Czyli tutaj odwracamy troszeczkę sytuację, że już nie jako zespół my robimy deployment na klaster, tylko staramy się trzymać stan klastra w Gitie i klaster sam sobie sprawdza, czy tam się pojawiły jakieś zmiany i klaster sam stara się doprowadzić do tej sytuacji, żeby on był up-to-date.

No więc, jak coś się stanie z tym naszym zwierzakiem, no to wiemy, jak go uleczyć, musimy o niego dbać. Tak samo było, powiedzmy, w softwareze. Mieliśmy jakąś tam bazę danych, nazywaliśmy ją tam Alpha 1. Wiedzieliśmy, że w przyszłym tygodniu musimy ją zaupdate'ować albo, że tam zaczyna jej brakować miejsca. No i tak dbaliśmy. Jest to problematyczne o tyle, że to się nam nie skaluje, tak? Musimy bardzo mocno dbać, musimy przyporządkować jakiegoś opiekuna do każdego takiego naszego serwera. No i tutaj DevOps też przychodzi właśnie z takim kolejnym rozwiązaniem, czyli Cattle, czyli to jest bardziej takie zwierzęta hodowlane typu tam, nie wiem, stado krówek, które no nie mają imion, mają w uchu plakietkę z numerkiem, no i łatwo jest je tak jakby traktować w ten sam sposób.

Więc tak samo właśnie w IT dąży się do tego, żeby te zasoby, którymi kontrolujemy, żeby one były w pełni automatyczne, żebyśmy mogli je łatwo podmienić. Jeżeli coś nie działa, podmieniamy, resetujemy i tak jakby operacyjnie wracamy do stanu. Czy są jakieś narzędzia? Bez których nie wyobrażasz sobie, że DevOps mógłby pracować? Tak, no tutaj myślę, że właśnie kierunek taki Infrastructure as a Code, czyli trzymanie całej infrastruktury w kodzie. No i już wspomniany Terraform, bądź jakieś inne rozwiązania. Natomiast dla mnie to jest podstawa właśnie, aby trzymać całą naszą infrastrukturę w kodzie, żebyśmy mogli łatwo ją rozszerzać. Następnie pewnie znajomość innych modeli bądź narzędzi, do których możemy robić deployments, czyli sam Kubernetes, ale też Kubernetes nie od strony takiej operacyjnej, jak on funkcjonuje, ale też w jaki sposób zainstalować go, uruchomić nawet na jakichś providerach cloudowych, czyli AWS, w jaki sposób tam możemy uruchomić taki klaster.

Nie wiem, integracja z systemami typu PagerDuty, że ktoś ma on-calla, że jest notyfikowany, że coś nie działa, wzywanie, ale też jakieś właśnie takie self-healing, narzędzia typu zresetuj dany pod, może się uda go postawić i nie trzeba będzie nikomu dzwonić. Więc w kierunku takiego właśnie observability i monitoringu. Chyba też tutaj właśnie security, tylko że security to jest też bardzo obszerne i to prawdopodobnie zależy od wymagań firmy. Natomiast jakieś skanowanie obrazów dockerowych, tak żeby sprawdzić co działa na naszym klastrze, czyli jeżeli pojawią się nam tutaj jakieś zagrożenia, aby to szybko wykryć, stwierdzić stan naszego klastra, to jest też częścią tak jakby pracy DevOpsa.

Analiza wszelkiego ruchu wewnątrz klastra, optymalizacja kosztów też może być tutaj dosyć istotna, jeżeli będziemy mieć dużo danych. Nasz rachunek za klauda może szybko być wysoki, więc musimy być w stanie sprawdzić, dowiedzieć się, co nam generuje te koszty i próbować to zaatakować. Skojarzyło mi się od razu, w momencie, w którym wspominałeś o Terraformie, I w moim doświadczeniu programistów kojarzę, że moje pierwsze właśnie jakieś wpisy do Terraforma nie były optymalne dla klienta, jeżeli chodzi o koszta. Okazuje się, że były lepsze rozwiązania. Także myślę, że faktycznie fajnie by było, jeżeli DevOps zwracałby na takie rzeczy uwagę i rozumiałby, czym się różnią różne opcje naliczania kosztów.

Tak, tak. Padło stwierdzenie, że DevOps nie musi być w każdym zespole. Jeżeli mamy jakiś mały projekt albo jest w ogóle ma firma, ten DevOps nie będzie na tyle wymagany. Natomiast załóżmy taką sytuację, że projekt się udał, firma się rozrasta, projekt się rozrasta i w pewnym momencie potrzebujemy tego DevOpsa. DevOps dołącza do zespołu. Jak widzisz rodzaj obowiązków, który będzie pełnił DevOps w takiej strukturze? Więc dokładnie w takiej sytuacji ja jestem teraz, w firmie, do której ja dołączyłem. Tam nie było stricte DevOpsa. Takie obowiązki właśnie DevOpsa pełnił cały zespół deweloperski. Rozwijał swoje narzędzia, aby aplikacje deployować na AWS-ie. Tutaj chcemy wejść w troszeczkę nowy zestaw narzędzi, tak jakby właśnie w Kubernetesa.

No i tutaj pojawiał się właśnie challenge dla firmy. W jaki sposób zaimplementować poprawnie Kubernetesa? Mając na pokładzie osoby, które nie mają z tym do czynienia wcześniej i nie wiedzą, jak to funkcjonuje, jest dosyć ciężkim. Prawdopodobnie tutaj możemy popełnić wiele błędów i będziemy musieli ten cały proces powtarzać. Zdecydowaliśmy na zatrudnienie osoby na stanowisku DevOps, tak żeby wprowadzić, zacząć powiedzmy od samego Kubernetesa jako platformy, na której będą uruchamiane nasze aplikacje. Pierwszym wyzwaniem dla osoby, która u nas była zatrudniona jako DevOps, było postawienie Kubernetesa, żeby on funkcjonował. Następnie staraliśmy się to przeskalować na różne poziomy.

Czyli tak jak już wspominałem, że mamy klaster deweloperski, klaster integracyjny, klaster produkcyjny. One muszą być w takim samym stanie i muszą być automatycznie też update'owane. Jeżeli dodajemy jakieś nowe funkcjonalności, to automatycznie się to dzieje na wszystkich Co z programistami? Czy ich praca jakoś się zmienia, kiedy DevOps dołącza do zespołu? Myślę, że mogą się skupić na tym, co lubią robić, czyli np. kodować w Javie, Javascriptie, Reactie. Nie muszą się przejmować właśnie takimi wynalazkami jak Terraform, który nie każdemu odpowiada. Tutaj tak samo jest na przykład z front-end developerami versus back-end developerzy. Każdy ma jakiś tam swój świat, swoje zainteresowania i w sumie fajnie, jeżeli pracuje w tym obrębie, wtedy są najbardziej produktywni.