Czy Developer może zostać DevOpsem? Historia Mateusza Lubańskiego

Mateusz po blisko sześciu latach pracy na stanowisku Backend Developera został DevOpsem. Nie była to łatwa decyzja, bo w organizacji, w której pracował, był pierwszą osobą na tym stanowisku. Brakowało więc wypracowanej kultury DevOpsa, a przede wszystkim świadomości współpracowników, w jaki sposób może im pomóc rozwiązywać problemy. O pracy DevOpsa rozmawialiśmy z Mateuszem Lubański, DevOps & Software Engineer w ICE Mortage Technology.

Potrafiłbyś wskazać różnicę między projektem, w którym nie ma DevOpsa, a projektem, który powstał ze wsparciem DevOpsa?

PIerwszą rzeczą, na którą chciałbym zwrócić uwagę to to, że DevOps nie działa na poziomie pojedynczego projektu, lecz bardziej globalnie na poziomie firmy. W przypadku, gdy nie mamy takiego zespołu, to ta rola częściowo jest współdzielona przez SysOpsa oraz w konkretnym już projekcie Technicznego Lidera. SysOps wspomaga tutaj zespoły pod kątem DevOps-owym poprzez dostarczenie usług/serwisów, o które są mniej lub bardziej potrzebne podczas całego procesu wytwarzania oprogramowania. SysOps jednak poza zainstalowaniem często nie ingeruje już w pełną konfigurację czy kompleksową integrację z pozostałymi narzędziami należących do zespołów deweloperskich

I tutaj wkracza po części techniczny lider projektu, który bazując na doświadczeniu pomaga skonfigurować już część z tych narzędzi, aby usprawnić i zautomatyzować proces wytwarzania aplikacji (np. skonfigurowanie CI/CD w używanym przez firmę narzędziu jak Jenkins/GitLab/…).

Czy taki SysOps i/lub TTL mający na co dzień masę swoich obowiązków, będzie w stanie rzetelnie i kompleksowo dodatkowo wykonywał obowiązki DevOpsa?

Zespoły składają się z często bardzo zdolnych inżynierów to sobie zazwyczaj “jakoś” radzą. Dużo większym wyzwaniem jest natomiast sytuacja, gdy mamy wiele zespołów. Wtedy zazwyczaj każdy ma swoje rozwiązania, rzadko są one współdzielone między innymi zespołami i często dochodzi do sytuacji “wynajdywania koła na nowo”. Może ten sposób działałby, gdyby w organizacji pracował stały zespół, bez zmian jego członków. W takiej sytuacji wdrożenie osoby do projektu trwa zwyczajnie dłużej, a co za tym idzie, więcej kosztuje pracodawcę czy też finalnego klienta.

Kiedy po raz pierwszy miałeś styczność z pojęciem DevOpsa i poznałeś jakie zalety niesie w projekcie?

Praktycznie od samego początku mojej kariery jako Java Backend Developer, chociaż wtedy nie zdawałem sobie z tego sprawy. Projekty, które nie mają DevOps-a często mają w zespole technicznego lidera, który poza pisaniem kodu i wspomagania w tym zakresie innych, wraz ze współpracą z SysOps-ami pomaga zautomatyzować chociażby proces Continuous Integration czy Continuous Delivery.

Osobiście od samych początków zaczynałem się interesować dodatkowymi tematami, jak wspomniane wyżej CI/CD czy automatyzacją wdrażania aplikacji u klienta przy pomocy skryptów Ansible lub też przyśpieszeniem tworzenia łatwo odtwarzalnego lokalnego środowiska developerskiego przy użyciu VirtualBox-a i Vagrant-a.

DevOps jest potrzebny każdej firmie bez względu na branżę i rodzaj oprogramowania, które tworzy?

Zdecydowanie tak, DevOps niezależnie od branży jest w stanie wesprzeć proces wytwarzania oprogramowania jak:

• zespół developerski → zbudowanie automatyzacji wokół CI/CD, która szybko wykrywa czy nowo wprowadzone zmiany nie popsuły czegoś w aplikacji, którą rozwijają,
• dział security → wdrożenie narzędzi security na każdym poziomie: zaczynając od źródłowego aplikacji, poprzez używane biblioteki, system operacyjny, infrastrukturę czy interfejsy API przed typowymi exploitami internetowymi,
• Quality Assurance → dostarczyć zautomatyzowany sposób środowisko, które jest zbliżone najbardziej, jak tylko się da do produkcyjnego, gdzie regularnie będą wykonywane testy regresyjne czy wydajnościowe,
• klient → skrócenie cyklów wydawania nowych funkcjonalności, aby szybciej zmonetyzować swoją usługę czy przetestować swoją hipotezę (testy A/B).

Dzięki temu każdy może skupić się dokładnie na wykonywanie swojej pracy, w najlepszy sposób czyniąc zespoły bardziej produktywnymi. Poprzez automatyzację oraz coraz to nowsze narzędzia DevOps będzie w stanie dostarczyć ekosystem, dzięki któremu firma będzie mogła przeprowadzać w kontrolowany i szybki sposób “eksperymenty”.

Kiedy DevOps powinien dołączyć do projektu? Opowiedz o najlepszej i najgorszej sytuacji.

Najgorszym scenariuszem będzie włączenie DevOps-a do rozwijanego już długi okres czasu projektu – mówimy o miesiącach, a nawet latach. W tym przypadku pierwszym etapem będzi próba zrozumienia systemu, jak działają zespoły oraz wszystkich zależności. Mając tę wiedzę, można zacząć wprowadzać usprawnienia i zmiany. Często tego typu projekt charakteryzuje się wysokim długiem technicznym, przez co dokonanie zmian może być jeszcze trudniejsze. Dodając do tego to, że zmiany trzeba wykonać na żywym organizmie może być jeszcze trudniejsze.

Innym błędem, z którym się często spotykam, jest to że projekt ma DevOps-ów, lecz nie są oni uwzględniani w planowaniu architektury aplikacji, a takie wsparcie często okazuje się niewspółmierne. DevOps często mają wiedzę z wielu narzędzi i rozwiązań, i które mogą pokryć sporą część wymagań niefunkcjonalnych. Dodatkowo od samego początku uwzględnione zostaną takie aspekty jak wysoka dostępność, wydajność i niezawodność

Najlepszą sytuacją jest, gdy firma posiada już wysoko rozwiniętą kulturę i narzędzia DevOps i gdy zaczyna nowy projekt. Wtedy dostarczenie już pierwszej wersji aplikacji może potrwać zaledwie kilka miesięcy lub nawet i tygodni!

Jak z Twojej perspektywy dzisiaj wygląda rynek DevOpsów?

Firmy zajmujące się wytwarzaniem oprogramowania stają się coraz bardziej świadome tego jak ważną rolę odgrywa DevOps w dzisiejszych czasach. Możemy obserwować, że Rynek DevOps rośnie z rokiem na rok coraz szybciej i nie wygląda, żeby miał zwolnić. Na podstawie ubiegłych lat prognozuje się wzrost wysokości 20% rocznie.

Główną przyczyną jest wartość, jaką DevOps przynosi firmom jak:

• pomaga skrócić czas wejścia na rynek czy skrócić cykl realisowy, co przekłada się na większe zadowolenie klienta,
• zwiększa wydajność zespołów,
• pomaga budować niezawodne i skalowalne usługi,
• pomoże obniżyć koszty poprzez automatyzację.

Gdzie początkujący zdobywają wiedzę? Jak bardziej zaawansowani podnoszą swoje umiejętności? Istnieje jakaś społeczność DevOpsów dzielących się wiedzą?

Najszybciej zdobywamy wiedzę, wykonując naszą pracę rozwiązując kolejne zadania i wyzwania oraz ucząc się od ludzi z projektów, w których uczestniczymy. Początkującym serdecznie polecam technikę Agile: “Pair Programming”, która jest znana wśród programistów, nieco mniej popularna w świecie DevOps. Można naprawdę dużo się nauczyć od drugiej osoby, podpatrzeć, z jakich pomocnych narzędzi korzysta, by wykonać swoje codzienne zadania. Metoda ta również pomaga zapobiegać silosom wiedzy czy szybciej zintegrować się z zespołem

W trakcie naszego rozwoju warto posiłkować się dodatkowo wiedzą z zewnętrznych źródeł takich jak:

• blogi – mamy dzisiaj masę wpisów opisujących konkretne narzędzia, rozwiązania konkretnego problemu, czy tak zwane “tutki”,
• książki – tutaj mam bardziej kompleksowe i obszerne podejście do danej tematyki jak w porównaniu z blogami. Należy jednak pamiętać, że typowo techniczne książki mogą się dosyć szybko stać nieaktualne. W tematyce DevOps serdecznie polecam The Phoenix Project oraz już bardziej techniczną kontynuację The DevOps Handbook,
• konferencje – jest to bardzo dobry sposób na sprawdzenie, co się dzieje na rynku, jakie narzędzia zyskują na popularności. Sesje na konferencjach są zazwyczaj relatywnie krótkie, więc nie wyczerpują kompleksowo tematu. Dlatego staram wybrać się z konferencji jedno zagadnienie/narzędzie, które wydaje mi się przynieść potencjalnie największe korzyści (tutaj możemy sobie zobaczyć kilka propozycji)
• szkolenia VOD – obecnie mamy coraz więcej platform szkoleniowych, które mają naprawdę świetną jakość. Osobiście regularnie korzystam z A Cloud Guru / Linux Academy czy Udemy,
• szkolenia stacjonarne – coraz częściej firmy mają przeznaczony budżet szkoleniowy, który można wykorzystać na specjalistyczne szkolenia. Poza samą wiedzą z konkretnego zagadnienia wartością dodaną jest bezpośredni kontakt z prowadzącym i pozostałymi uczestnikami szkolenia.

Niezależnie jakie źródło dodatkowej wiedzy wybierzesz, należy pamiętać o tym, że jeśli ktoś używa narzędzia X i sprawdza się u niego, nie jest to równoznaczne z tym, że sprawdzi się ono również u nas. Nawet najlepsze narzędzie wykorzystywane w zły lub nieświadomy sposób przyniesie zazwyczaj więcej problemów jak korzyści.

Oferty pracy z

Dlaczego podjąłeś decyzję o tym, że będziesz pracował jako DevOps? Przez lata pracowałeś jako Software Engineer.

Zgadza się, przez wiele lat pracowałem jako Backend Developer i pełniłem też często rolę takiego technicznego lidera, więc częściowo wykonywałem już obowiązki DevOpsa. Na początku podejmowałem się pojedynczych pomniejszych zadań jak np. skonfigurowanie dla własnego projektu CI/CD w Jenkinsie, integracja projektu z statyczną analizą kodu, automatyzacja instalacji naszego oprogramowania skryptami ansible.

Jednym słowem szukałem sposobów jak usprawnić pracę swojego zespołu poprzez automatyzację powtarzających się czynności wdrażanie CI/CD, aby wykrywać problemy na jak najwcześniejszym etapie czy też szukałem znalezienie sposobu na polepszenie jakości naszego softu poprzez wdrożenie statycznej analizy kodu.

Ciekawe jest tutaj to, że z początku nie wiedziałem, że istnieje coś takiego jak DevOps i nie bardzo potrafiłem nazwać swoje zainteresowanie. Wiedziałem, że nie jest to typowe stanowisko Developer czy SysOps. Zdawałem sobie sprawę, że potrzebuję nabyć trochę wiedzy SysOpsa. Po drodze będąc wciąż w roli Software Engineera przyjmowałem dodatkowe role jak ScrumMaster czy Release Engineer, lecz żadna z nich nie była w pełni tym co chciałem robić.

Co było zatem punktem zwrotnym w Twojej ścieżce kariery?

Punktem zwrotnym była praca w Wiedniu, gdzie bazując na poprzednich doświadczeniach, zacząłem wdrażać powoli wszystkie udoskonalenia, które widziałem, że potencjalnie przyniosą korzyści i dobrze się wpasują. Ludzie w zespole byli bardzo zadowoleni z rezultatów, jako że widzieli zdecydowaną poprawę. W firmie planowano wystartowanie kilku podobnych projektów a mój były szef, do którego doszły słuchy o moich usprawnieniach, zapytał się mnie czy chciałbym się tym zająć na pełen etat. W tym momencie już wiedziałem, że ta rola to DevOps (o czym dowiedziałem się na którejś z konferencji oraz po przeczytaniu książki Projekt Feniks) więc stało się! W styczniu 2017 zostałem oficjalnie “DevOpsem”.

Nie była to dla mnie łatwa decyzja. Z jednej strony wiedziałem, że mnie to bardzo interesuje i lubiłem wykonywać obowiązki na tej pozycji. Z drugiej strony w obecnej firmie nie istniała kultura DevOps, niewiele osób wiedziało czym jest DevOps i zdawałem sobie sprawę, że będzie to przecieranie szlaków w nieznane. Dodatkowo dochodzi kwestia, że mając wtedy 6 lat doświadczenia na pozycji Backend Developer miałem pozycję seniorską a tutaj zaczynam od nowa!?

Prywatnie moją pasją są różnego rodzaju aktywności sportowe, gdzie regularnie próbuję nowych rzeczy jak np. kajakarstwo górskie, crossfit, squash od tego roku chodzenie po górach zimą. Dodatkowo zawodowo próbowałem już swoich sił na innych stanowiskach jak ScrumMaster czy Release Engineer więc zdecydowałem się podjąć wyzwanie!

Tak zazwyczaj wygląda ścieżka kariery DevOpsa? Większość DevOpsów było Engineerami?

Z mojego doświadczenia DevOps-i wywodzą się zazwyczaj z pozycji developera lub SysOpsa. Żadna z tych pozycji chyba nie ma znaczącej przewagi nad drugą, ponieważ rozwijając się jako DevOps musimy zapoznać się z całym procesem wytwarzania oprogramowania. Pozycja ta jest bardzo wymagająca i wymaga zdecydowanie już wcześniejszego doświadczenia.

Ciekawa zmiana, którą obserwujemy to, że niektóre firmy przestały zatrudniać już typowych SysOps-ów. Pewnie zapytacie się jak to możliwe? Wraz z rozwojem narzędzi i coraz bardziej popularnemu modelu IasS (Infrastructure as a Service) oraz PaaS (Platform as a Service) pozwala nam znacząco uprościć tworzenie i zarzadzanie infrastruktura. Rzeczy, które kiedyś wymagały wielu miesięcy, a nawet lat doświadczenia dzisiaj jesteśmy w stanie zbudować przy pomocy jednego z Cloud Providerów (AWS, Azure, GCP, …) w przeciągu godzin lub dni. Dlatego uważam, że coraz ważniejsza będą stawały się umiejętności pracy w “chmurze” oraz znajomość jednego z narzędzi IaC (Infrastructure as a Code) jak np. Terraform.

DevOps to nie tylko praca z narzędziami i technologią, ale także kultura więc, aby odnieść sukces, musisz również zdobyć umiejętność nawiązywania przyjaźni i wpływania na ludzi.

Jakie możliwości rozwoju stoją przed Tobą? Więcej opcji ma Software Engineer czy DevOps?

Myślę, że dobrym zobrazowaniem mogłoby być porównanie lekarz czy chirurg. Jedna z drugą rolą są powiązane. Medycyna również ciągle się rozwija. Zarówno lekarz (np. dietetyk, laryngolog, psychiatra) i chirurg (plastyczny, onkolog, neurochirurgia) mają wiele specjalizacji, na których rozwojowi można spokojnie spędzić nawet i całe życie.

Patrząc na to jak dynamicznym rynkiem jest rynek IT: coraz to nowsze języki oprogramowania, stale powiększająca się liczbę narzędzi, pojawiające się coraz to nowe firmy to jestem przekonany, że wybierając którąkolwiek z tych profesji, nie będziesz nudził!

Co Twoim zdaniem świadczy o tym, że zawód DevOpsa będzie nadal pożądany za rok, trzy czy pięć lat?

Po pierwsze dynamicznie rozwijający się rynek IT, bo powstają nowe firmy, które potrzebują ekspertów. Po drugie zwiększająca się świadomość firm jak ważną rolą jest DevOps. A to jak ogromne korzyści wnosi DevOps do organizacji, przekonały się już: Netflix, Amazon, Uber i wiele innych. Moim zdaniem idziemy w kierunku, gdzie powoli firm nie będzie stać na to aby nie inwestować u siebie w “DevOps”.

---

Mateusz Lubański. Senior DevOps Engineer w ICE Mortgage Technology. Od ponad 10 lat w branży IT, były Java Backend Developer oraz posiadacz certyfikatów AWS (Solution Architect, DevOps Engineer, Developer, SysOps) Na co dzień skupiający się na tym jak usprawniać, skalować i automatyzować proces wytwarzania oprogramowania. W wolnym czasie podróżnik oraz zwolennik aktywnego wypoczynku, można go spotkać na szlaku górskim lub trasie rowerowej.