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

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.

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.

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.

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.

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.

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. No ale w sumie razem, jak ich połączymy, no 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 AWSem, doświadczenie z Terraformem, żeby taka osoba już Wcześniej korzystała z tego typu narzędzi.

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ę, że testowaliśmy cert-managera do certyfikatów HTTPS i zużyliśmy całą pulę dostępnych certyfikatów dla klastra DEV. Wszystkie serwisy nie działają. Nawet to nie było dla klastra DEV, tylko dla kilku klastrów. Kilka serwisów nie działało tam przez parę dni, ponieważ musieliśmy czekać, aż ta pula uzupełni.

Czasami takie testowanie na produkcji, która jest też devem, 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 terraformowych trzymaliśmy listę repozytoriów dockerowych. No i ona była niealfabetyczna, więc jedna z osób stwierdziła, że zrobi kod ładniejszy niż był i posortowała je alfabetycznie. W tym momencie Terraform 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ępu.