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

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?

Robimy planning właśnie, co nam będzie tutaj potrzebne i definiujemy całą infrastrukturę, serwery bazodonowe, serwery aplikacyjne, cały przepływ informacji, potem zaczynamy to implementować. No i właśnie jak już zaczynamy implementować tutaj, To wchodzą właśnie takie aspekty jak CI i CD, żeby usprawnić proces budowania już tych funkcjonalnych rzeczy, którymi zespół się będzie zajmował. Żebyśmy dodawali te wymagania funkcjonalne, żeby to było sprawne, żebyśmy mogli szybko pokazać, Nie wiem, product ownerowi, jak wygląda postęp pracy, żeby to nie było takie waterfallowe i dopiero po sześciu miesiącach, hej, zobaczcie, co my tutaj mamy, tylko żebyśmy to mogli tak co dwa tygodnie. Więc tutaj jest potrzebna praca, żeby ktoś na to spojrzał, żeby to było powtarzalne i łatwe przede wszystkim, żeby ktoś po prostu jakimś jednym przyciskiem mógł wywołać cały ten proces.

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ć.

No jasne. Łatwo jest się pomylić, stawiając nowy powiedzmy serwer, zapomnieć tak jak wspomniałeś o czymś albo po prostu potrzebujemy zmienić jedną rzecz, mieliśmy zmienić na czterech, zmieniliśmy na trzech serwerach. Dokładnie. Środowiska się zaczynają rozjeżdżać. To jest znany problem. Tak, więc tutaj niby jest Cloud, ale też można pójść w ślepą uliczkę. No i tutaj z pomocą przychodzą właśnie rozwiązania DevOpsowe. Mamy takie tule jak Terraform, które pozwalają nam za pomocą Infrastructure as a Code opisać, co my tak naprawdę potrzebujemy. Jeżeli potrzebujemy więcej instancji, po prostu odpalamy ten nasz skrypt Terraformowy z innymi parametrami i możemy replikować Na zażądaną ilość tych maszyn, tych usług, tak aby to było powtarzalne.

Jeżeli potrzebujemy coś zmienić, zmieniamy w kodzie, kod trzymamy w repozytorium, możemy śledzić kto zrobił zmiany, jakiego to były zmiany, kiedy one były, więc jest to łatwe do trzymania historii. Więc tutaj możemy powiedzieć, że to jest tak jakby ta pierwsza warstwa, budowanie infrastruktury, na którym nasz produkt będzie działał. Dalej pewnie chcielibyśmy już iść i budować naszą aplikację i tutaj usprawnić właśnie proces tak jakby deploymentu tej aplikacji na tej naszej infrastrukturze. No i tutaj wchodzi właśnie cały proces CI, Continuous Integration, który pozwala nam zbudować aplikację, CD, Continuous Delivery. który za każdym razem jak zrobimy zmiany, no możemy te zmiany wypromować na najnależniejszy serwer, powiedzmy jakiś tam deweloperski, gdzie możemy spojrzeć czy to wszystko działa w kooperacji z resztą zespołu.

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

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ą.

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.

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.

I tutaj może być sytuacja chociażby takiego już wspomnianego HTTPS-a. W jaki sposób osoba zaimplementowałaby API Endpoint z HTTPS-em na Kubernetesie. No i staramy się tak jakby zrozumieć, czy ktoś już wcześniej stykał się z tego typu problemem, zna rozwiązania, może jedno, może więcej i staramy się rozmawiać. Okej. Fajnie tutaj podałeś listę, jeżeli chodzi o te kompetencje twarde, powiedzmy narzędzia, które powinien znać DevOps. A co sądzisz o umiejętnościach miękkich? Jak już wspomnieliśmy gdzieś tam wcześniej, taka osoba na stanowisku DevOps współpracuje czasami z wieloma zespołami, więc wydaje mi się, że taka komunikacja jest tutaj kluczowa. Umiejętność zrozumienia problemu, umiejętność pomagania sobie nawzajem, rozumienie potrzeb innych działów.