W dzisiejszym odcinku Nikodem rozmawia z Łukaszem Kasprzakiem, Head Of Engineering w Satago, o roli DevOpsa w organizacji. Dowiesz się m.in.:
🟠 Kim jest DevOps?
🟠 Czym zajmuje się DevOps?
🟠 Jakie narzędzia są potrzebne w codziennej pracy DevOpsa?
🟠 Jak zostać DevOpsem i gdzie znaleźć cenną wiedzę?
________________________________________________________
Nikodem: Anika to jakoś złączy, tym się nie przejmuj.
Anika: Ale nie moimi słowami musisz to coś powiedzieć. 😅
To byłoby wyzwanie, jakbyś skleiła siebie jeszcze z naszymi wypowiedziami.
Łukasz: 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 jak deweloper PHP, następnie spróbowałem swoich sił w Javie, w C#, następnie próbowałem troszeczkę więcej zaangażować się w zarządzanie i management, zostałem engineering menadżerem, 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.
Zaczynając 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 tak jakby przenosić tej pracy pomiędzy różnymi zespołami, a wykonywali wszystko w jednym zespole. No i nie wiem, pewnie jak byłeś tym devopsem, 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ę. Czy na takim stanowisku gdzieś pracowałeś, czy może jeszcze wyżej?
Jeśli chodzi o moje doświadczenie to było bardziej budowanie procesu CI/CD i głównie pracowaliśmy z Jenkinsem, ustawianie wszystkich jakiś flow pod każde repozytorium, takiego typu rzeczy. Później w momencie, w którym firma zaczęła bardziej korzystać z nowszych technologii, to też dockerem się zajmowaliśmy, bardzo przenosiliśmy wszystkie aplikacje w stronę dockera i konfiguracja wszystkich nexusów i tak dalej.
Więc ja myślę, że to jest właśnie fajny model, tutaj pokazuje, że można podzielić tak jakby ten proces na kilka etapów. Są takie takie, nie wiem, key word’y typu day zero, day one, day two, w których na innym momencie czasu zajmujemy się innymi rzeczami. Na takim day zero robimy planning właśnie, co nam będzie tutaj potrzebne i definiujemy całą, nie wiem, infrastrukturę, serwery bazodanowe, serwery aplikacyjne, cały przepływ informacji, po tym zaczynamy to implementować i właśnie jak już zaczynamy implementować tutaj to wchodzą właśnie takie aspekty jak CI/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ć product ownerowi, jak wygląda postęp prac, żeby to nie było takiego 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 no 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. No kiedyś, nie wiem, kiedy, 20 lat temu… Bezpieczna data. Bezpieczna data, tak. Prawdopodobnie cały proces zaczynał się od jakiegoś kosztorysu, zbudowania nie wiem, planu, co będziemy potrzebować, jakiego typu serwerów, jakie one powinny mieć procesory, ile pamięci powinny mieć i ktoś zazwyczaj szacował to do góry, był tworzony zakup, mieliśmy jakichś sieciowców, którzy to wszystko łączyli, jak to było gotowe było to przekazywane dalej, prawdopodobnie po tym jakieś security tutaj budowało jakąś własną warstwę zabezpieczeń, żeby nikt do tej sieci się nie mógł dostać, żeby to było bezpieczne. No i potem kolejne przez różne warstwy, aż na samym końcu gdzieś byli software deweloperzy, którzy tworzyli już to oprogramowanie i chcieli je tam zdeployować i uruchomić. Cały ten proces prawdopodobnie jest bardzo długi i skomplikowany, jeżeli chcemy coś zrobić szybko, jeżeli chcemy coś dostarczyć na już i pokazać, wymagał tutaj wielu kroków, więc w mojej opinii tak jakby szukaliśmy optymalizacji w software, i w czasach, kiedy mamy już rozwiązania cloudowe nie ma potrzeby, aby te serwery fizycznie gdzieś trzymać. Możemy je sobie zarządać na żądanie, one będą gotowe dla nas po minucie, więc to działa, tu pomaga i teraz w jaki sposób tutaj devops może pomóc? Bo oczywiście możemy użyć jakiejś konsoli AWS-owej, gdzieś sobie wyklikamy, że chcę mieć serwer, on będzie stał, będzie gotowy, tylko że za chwilę możemy mieć potrzebę, aby postawić drugi taki sam serwer z takimi samymi ustawieniami, trzeci, czwarty, jeżeli będziemy to wyklikiwać, bardzo szybko zapomnimy o jakichś ustawieniach, że coś zmieniliśmy, że coś tam było zmieniane i no mamy te serwery w różnym stanie.
Ł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, środowiska się zaczynają rozjeżdżać, to jest znany problem.
Tak, więc tutaj niby jest cloud, ale no też można pójść w ślepą uliczkę, i tutaj z pomocą przychodzą właśnie rozwiązania devopsowe, mamy takie toole jak Terraform, które pozwalają nam za pomocą IaC 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, jakie 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órej 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, możemy te zmiany wypromować na najbliższy serwer, powiedzmy jakiś tam deweloperski, gdzie możemy spojrzeć czy to wszystko działa w kooperacji z resztą zespołu, 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 stage’ing bądź produkcję 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 nie technicznych, 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ć, bo po tym, jak, powiedzmy, deweloper commitował swój kod, musieliśmy ręcznie uruchomić różnego typu komendy, żeby stworzyć, zbudować ten kod, później trzeba było go 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 tak zwane pipeline’y 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.
Tak.
Czy ten day 2 jeszcze nie został opisany?
Nie, day 2 jeszcze nie został opisany, więc day two 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 na przykład coś takiego jak observability, gdzie musimy obserwować, czy ta aplikacja faktycznie działa, w jaki sposób działa, czy nie wiem, nie brakuje pamięci, czy nie brakuje dysku, jaka jest tam przepustowość sieci, czy serwisy pomiędzy sobą się komunikują, 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ę. I tutaj na przykład z pomocą przychodzi dla nas cały Kubernetes, w którym aplikacje deploy’emy i na tym naszym Kubernetesie możemy właściwie mieć zestaw, który będzie uniwersalny do wszystkich aplikacji, które tam zdeploy’ujemy, czyli w czym to może pomóc? Na przykład w zbieraniu 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 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 aplikacji, mamy ich wiele, może wystąpić jakiś problem, potrzebujemy sprawdzić gdzie to się działo, więc tak wchodząc na każdą 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ł i jaki był problem. 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, mam na myśli w projekcie i będzie potrzebna taka osoba faktycznie, bo to jednak trzeba śledzić, w momencie, w którym coś się wali, trzeba szybko reagować, płatać dziury.
Jeszcze są inne aspekty tutaj pewnie, które devops będzie musiał pomagać, no wszystko, co jest związane nie wiem, z security na przykład. W dzisiejszych czasach trudno sobie wyobrazić aplikację, która na przykład nie supportuje HTTPS’a tak, 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. 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, 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 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ędzie mieć osobę devops, ale będziemy mieć tam również QA, frontend engineera, backend engineera i taki zestaw różnych skillsetów razem jako zespół powoduje, że ten zespół jest samowystarczalny, że on może zbudować UI, może zbudować backend, 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ć tam, 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 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ę, 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 deweloperów albo frontend engineeró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ć, no i wtedy same sobie to zrobią. Zazwyczaj są to może jakieś mniejsze firmy, które tam zatrudniły pięć 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 uczyć nowych technologii, na przykład Kubernetesa, 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ć, 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 te Terraformem, ale wszystkim dookoła, które się dzieje. I to pomaga, samo na przykład takie zainteresowanie, co możemy uzyskać z tego Kubernetesa, w czym on nam może pomóc, 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 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 AWS-ie 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órą uważasz, że dobry devops powinien znać i rozumieć?
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 to się nazywa GitOps. Nie wiem, czy korzystałeś właśnie z Argo CI/CD, czy też z Argo Workflows, ale tutaj właśnie to jest taka osobna metodologia, podejście do problemów, w jaki sposób te deploymenty mają wyglądać, czyli tutaj odwracamy troszeczkę sytuację, że już nie jako zespół my tak jakby robimy deployment na klaser, tylko staramy się trzymać stan klastra w Git i klaster sam sobie sprawdza, czy tam się pojawiły jakieś zmiany, klaster sam stara się doprowadzić do tej sytuacji, żeby on był up to date. To jest o tyle fajne, że jeżeli w przyszłości na przykład cały klaster nam padnie i my będziemy musieli postawić nowy, tylko wskazujemy, że tutaj jest repozytorium ze stanem całego klastra i on sobie to wszystko pobierze i doprowadzi do takiego stanu, jaki był, nie wiem, w poprzednim klastrze, nie musimy tutaj dbać i po kolei robić deploymentów poszczególnych aplikacji. Więc to jest bardzo fajne podejście wykorzystywane. Ogólnie też jest taki koncept, nie wiem, Pets i Cattle, nie wiem, czy spotkałeś się z czymś takim, właśnie tak jakby poprzedni model funkcjonowania software’u opierał się na takiej ideologii Pets, czyli mamy takie zwierzątka domowe, nadajemy im nazwy, kochamy je, każdy ma swoją jakąś tam książeczkę szczepień, wiemy, na jakim etapie, 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 software. Mieliśmy jakąś tam bazę danych, nazywaliśmy ją tam Alfa 1, wiedzieliśmy, że w przyszłym tygodniu musimy ją update’ować, albo że tam zaczyna jej brakować miejsca no i tak dbaliśmy. Jest to problematyczne o tyle, że to się nam nie skaluje. 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 nie mają imion, mają w uchu plakietkę z numerkiem 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, tutaj myślę, że właśnie kierunek taki infrastructure as a code, czyli trzymanie całej Infrastruktury w kodzie 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ć deployment, 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 jakiś providerach cloudowych, czyli AWS, w jaki sposób tam możemy uruchomić taki klaster. Innym tutaj zagadnieniem też w tym kierunku jest powiedzmy samo availability, czyli chcielibyśmy, żeby nasz serwis był dostępny w kilku regionach, jak coś takiego osiągnąć, czyli dobra znajomość powiedziałbym dostawców cloudowych, co oferuje Google versus AWS, bądź może niektóre firmy mają wymagania, żeby coś postawić On-Premises, więc tutaj też dobrze jest mieć świadomość jak takiego Kubernetesa zainstalować na takich własnych systemach. Innymi narzędziami jest powiedzmy cały stack observeability, to jest, jak dla mnie dosyć mocna rzecz, czyli tutaj Prometheus, Grafana, narzędzia, które potrafią nam zbierać metryki z naszych aplikacji, zbierać logi, umożliwić programistom przeszukiwanie tych logów, przeszukiwanie tych metryk, na podstawie metryk generować alerty, nie wiem, integracja 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 wydzwaniać, więc w kierunku takiego właśnie observeability 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, czy 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 ten nasz rachunek za clouda 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 małym doświadczeniu wśród 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.
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ła 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 i jak widzisz rodzaj obowiązków, który będzie pełni devops w takiej strukturze?
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 deploy’ować na AWS-ie, tutaj chcemy wejść troszeczkę w 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 miały z tym do czynienia wcześniej, nie wiedzą, jak to funkcjonuje. Prawdopodobnie tutaj możemy popełnić wiele błędów i będziemy musieli ten cały proces powtarzać. Zdecydowaliśmy się na zatrudnienie osoby na stanowisku devops, tak, żeby wprowadzić, zacząć powiedzmy od samego Kubernetesa jako platformy, na której będą uruchamiane nasze aplikacje. Tak więc pierwszym wyzwaniem dla osoby, która u nas była zatrudniona jako devops, było postawienie właśnie Kubernetesa, tak, ż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 i one muszą być w takim samym stanie i muszą być automatycznie też update’owane, jeżeli dodajemy jakieś nowe funkcjonalności, to automatycznie to się dzieje na wszystkich tych klastrach.
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 na przykład kodować w Javie, JavaScripcie, w React, 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 frontend deweloperami versus backend deweloperzy. 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, więc tutaj ja bym traktował devopsa na równi z programistami, to jest tak samo osoba, która gdzieś tam koduje, po prostu wykorzystuje inne narzędzia, inne języki, ale w sumie razem, jak ich połączymy, to mamy zgrany zespół, który jest w stanie dowieźć całość.
Na co zwracasz uwagę, kiedy rekrutujesz jakąś osobę do zespołu?
Nasza organizacja jest relatywnie niewielka, więc tutaj mamy dosyć jasno określone wymagania, które gdzieś stawiamy dla osoby na stanowisku devops, więc staramy się tak jakby dopasować umiejętność i poprzednie doświadczenie z tym, co my chcemy osiągnąć. Dla mnie na przykład bardzo ważne jest doświadczenie z cloudem, z AWS-em, doświadczenie z Terraformem, żeby taka osoba już wcześniej korzystała z tego typu narzędzi, doświadczenie z Kubernetesem, żeby taka osoba była w stanie postawić klaster samemu od zera i to są takie rzeczy, których wymagamy. Reszta to jest coś, co można się nauczyć i pewnie rozwijać się i szkolić.
Jeżeli biorę udział w rozmowie rekrutacyjnej jako programista, to łatwo bardzo jest zweryfikować moją wiedzę, można na przykład przygotować jakieś zadanie dla takiego programisty, żeby coś zrobił, żeby wytłumaczył, dlaczego w taki sposób chciałby to zaimplementować albo złapać po prostu w jakiś sposób dana osoba myśli, czy podobnie jest u was?
Jeżeli zatrudniamy kogoś na stanowisko programisty to tak, natomiast jeżeli zatrudniamy kogoś na stanowisko devopsa, no to na przykład przedstawiamy jakieś problemy, które gdzieś mieliśmy poprzednio, problemy, albo wyzwania i jak coś chcieliśmy zaimplementować no i tutaj może być sytuacja, chociażby właśnie 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 czasem 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. Może być jakiś dział security i oni mogą mieć jakieś wymagania data governance albo właśnie jakieś wolne availability i umiejętność znalezienia gotowych rozwiązań, gotowych narzędzi, które pozwolą nam w łatwy sposób na przykład katalogować zasoby, których używamy, tak, żeby tamta osoba może nie musiała używać jakiegoś Excela, albo tego typu rzeczy.
Wielokrotnie już wspominałem w podcastach, że temat testowania jest bardzo mi bliski, dlatego chciałbym też poruszyć taką kwestię, jak to wygląda wśród devopsów, czy wy macie okazję przetestować coś, zanim wdrożycie swój produkt albo zanim podbijecie wersję jakiejś aplikacji, z której korzystacie?
Staramy się.
Okej, to jest bardzo dyplomatyczna odpowiedź, ja też się zawsze staram testować wszystko, co robię.
Tak, ale odpowiadając na twoje pytanie, to tak, między innymi dlatego mamy powiedzmy kilka klastrów, nie tylko jeden, tylko właśnie klaster deweloperski, który jest taki czasami eksperymentalny, gdzie wrzucamy zmiany, tam ma prawo coś nie działać, staramy się to naprawić.
Tak, ale z mojej perspektywy jako dewelopera, często też korzystam z tego środowiska, żeby testować swoje zmiany i jeżeli dostałbym taką informację, że moje środowisko nie będzie działać przez jakiś czas to byłbym dosyć smutny, czy to jest tak, że wy korzystacie z tego samego środowiska, z którego korzystają deweloperzy, czy macie jeszcze jakieś swoje osobne gdzieś na boku, z którego korzystają tylko devopsi?
Nie mamy, natomiast jeżeli jakaś zmiana jest taka dosyć duża i wielka, wydaje mi się, że jesteśmy w miarę łatwo w stanie stworzyć takie środowisko poprzez właśnie tego Terraforma, którego mamy, możemy go odpalić, stworzyć całkowicie nowe, sprawdzić, czy to tam będzie funkcjonować i dopiero wtedy zacząć implementować zmiany już na tym deweloperskim. Kiedyś mieliśmy taką sytuację właśnie, że testowaliśmy cert-managera właśnie do certyfikatów HTTPS i zużyliśmy całą pulę dostępnych certyfikatów dla klastra dev i wszystkie serwisy nie działały. Nawet to nie było dla klastra dev, tylko dla kilku klastrów i kilka serwisów nie działało tam przez parę dni, ponieważ musieliśmy czekać aż się ta pula uzupełni, więc czasami takie testowanie na produkcji, które jest też dev’em, powoduje problemy i frustracje deweloperów.
Fajnie, że podzieliłeś się takim doświadczeniem, czy masz jeszcze jakieś inne, ciekawe przypadki ze swojej kariery?
Kiedyś mieliśmy taką sytuację, że właśnie w skryptach Teraformowych trzymaliśmy listę repozytoriów dockerowych i ona była nie alfabetyczna, więc jedna z osób stwierdziła, że zrobi kod ładniejszy niż był i posortowała je alfabetycznie. W tym momencie Terraform nam zastosował technikę, że skasuje wszystkie i stworzy od początku, co wiązało się z utratą wszystkich naszych obrazów dockerowych, które gdzieś tam były przechowywane i braku do nich dostępów i tutaj trzeba było dosyć wykazać się sprytem, aby te obrazy w jaki sposób odzyskać z działających klastrów i z powrotem je tam wgrać.
Jak zaczynałem pracę jako devops, w sumie jedynym narzędziem, na którym musiałem się skupić i które rozumieć to był Jenkins. Z czasem dochodziły właśnie dockery. jakiś Kubernetes i tak dalej. Widzę, że rola takiego devopsa, żeby być dobrym devopsem, jest bardzo dużo narzędzi, które trzeba rozumieć, których trzeba się uczyć, a jak twoim zdaniem powinien wyglądać rozwój devopsa, na czym się trzeba skupić, czego się uczyć, czego warto, a czego nie warto?
Ja bym tego nie ograniczał tylko do devopsa, wydaje mi się, że w każdej roli software dewelopera, frontend, backend, QA powinniśmy się uczyć i się rozwijać.
To na pewno i to cały czas, często pytamy naszych gości, czego powinniśmy się uczyć, bo to tak jak mówisz, cały czas branża idzie do przodu, rozwija się, warto się uczyć, tylko chodziło mi o to, jak twoim zdaniem powinien wyglądać rozwój devopsa?
Powinien wykazywać jakieś zainteresowanie właśnie nowymi rozwiązaniami, warto śledzić fundację CNCF, która aprobuje narzędzia, które są w standardzie cloudowym, pojawia się dużo nowości, nowych rozwiązań, kierunków, pewnie warto też śledzić konferencję CubeCon, międzynarodowa, bardzo dużo można się nauczyć kierunku, w którym zmierza całe środowisko cloudowe, oczywiście pewnie można obserwować YouTube, czytać jakieś artykuły.
Dziękuję ci Łukaszu, że zgodziłeś się nas odwiedzić i opowiedzieć o roli devopsa, tak jak wspomniałem zaczynałem swoją karierę jako devops, ale od tamtej pory sporo się zmieniło, także fajnie było usłyszeć o nowinkach.
Dzięki Nikodem za okazję do fajnej pogaduchy, fajnie było.
Dziękuję również naszym słuchaczom i widzom, mam nadzieję, że odcinek się podobał. Pamiętajcie, że widzimy się już za dwa tygodnie i jak zawsze zachęcam do pozostawienia lajków, subskrypcji i komentarzy, cześć!
Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉
💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK
🌏 Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox
Obserwuj nas na social media: 🚀
LinkedIn: https://bit.ly/3PxlHFQ
🎧 Spotify: https://spoti.fi/39xU0fm
🎧 iTunes: https://apple.co/3PsjhrQ
Jeśli Ci się temat spodobał, subskrybuj nasz kanał, bo dopiero się rozkręcamy z gorącymi tematami! 🙂
