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

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.

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.

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.

Innym tutaj zagadnieniem też w tym kierunku jest, powiedzmy, nie wiem, samą Availability, czyli musielibyś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, nie wiem, Google versus AWS, bądź może niektóre firmy mają wymagania, żeby coś postawić on-prem, 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 Observability. 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.

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.

Doświadczenie z Kubernetesem, żeby taka osoba była w stanie postawić cluster samemu od zera. No i to są takie rzeczy, które 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 zbadać 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 DevOps'a, to np. przedstawiamy jakieś problemy, które gdzieś mieliśmy poprzednio. Problemy albo wyzwania, jak coś chcieliśmy zaimplementować.

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.

No 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óre musiałem się skupić i które rozumieć, to był Jenkins. Z czasem dochodziły właśnie Tokery, jakieś Kubernetes i tak dalej. Widzę, że rola takiego DevOpsa, żeby być dobrym DevOpsem, jest bardzo dużo narzędzi, których trzeba rozumieć, których trzeba się uczyć. Jak twoim zdaniem powinien wyglądać rozwój DevOpsa? Na czym się trzeba skupić? Czego się uczyć? Czego warto, czego nie warto? Ja bym tego nie ograniczał tylko do DevOpsa. Wydaje mi się, że w każdej roli software developera, frontend, backend, QA powinniśmy się uczyć się rozwijać.