To jest 121. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o tym, jak zostać i rozwijać się jako inżynier DevOps.

Przypominam, że w poprzednim odcinku rozmawiałem o automatyzacji i programowaniu w świecie infrastruktury. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/121.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego, jest między innymi ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

Jednocześnie bardzo dziękuję moim obecnym patronom.

A teraz życzę Ci już miłego słuchania.

 

Odpalamy!

 

Cześć! Dzisiaj w podcaście moimi gośćmi są: Jacek Biernat, prezes zarządu, CEO, Solution Architect i DevOps w LCloud oraz Tomasz Skibiński, inżynier DevOps i Chief Technology Officer w LCloud.

Jacku, Tomku, cześć! Bardzo miło mi gościć Was w podcaście.

 

Tomasz Skibiński: Cześć!

 

Jacek Biernat: Cześć, Krzysztofie! Dzięki za zaproszenie.

 

Przyjemność po mojej stronie. Wiele razy padło tutaj słowo DevOps i to będzie jeden z głównych tematów, głównych wątków naszego dzisiejszego podcastu. Będziemy rozmawiać o tym, jak zostać, jak pozostać i jak rozwijać się właśnie w roli inżyniera DevOps.

Na początku jednak zadam Wam standardowe pytanie, które zadaje każdemu, kto rozmawia ze mną w podcaście. Mianowicie, czy słuchacie podcastów? Czy to medium jest Wam bliskie?

 

J.B.: Ok, to może ja odpowiem. Tak, słucham, ale nie ograniczam się tylko do podcastów, raczej do wszelkich nagrań z social mediów czy audiobooków, w których mogę znaleźć więcej informacji na konkretny temat, który mnie właśnie zaciekawił. Nie będę ukrywał, że większość nagrań jest w języku angielskim, z kilku dziedzin, niekoniecznie IT. Ale jeśli mamy dzisiaj rozmawiać o DevOps, to może bym sobie pozwolił wymienić jeden polskojęzyczny kanał z technologii cloud, który ostatnio zadebiutował jako zapowiedź fajnej serii nagrań. Jest to YouTube od AWS Polska, dostawcy chmurowego, który podsumowuje nowości cloud u tego dostawcy z ostatniego miesiąca. Na pewno jest to fajna pigułka wiedzy dla każdego DevOps, który chce specjalizować się w tej konkretnej technologii, być na bieżąco i znać nowe trendy, rozwiązania u lidera tego dostawcy chmurowego.

 

Tomku, a jak u Ciebie to wygląda?

 

T.S.: Szczerze mówiąc, ja rzadko słucham podcastów, co jest uzależnione od ilości posiadanego czasu. Od czasu do czasu słucham, staram się słuchać najnowszego podcastu The Cloudcast. Jest to angielskojęzyczny podcast. A tak przeważnie raczej śledzę i oglądam jakieś materiały na YouTube czy innych platformach, na których prezentowane są konkretne rozwiązania. I tak to wygląda, tak naprawdę, u mnie.

 

Świetnie. Dzisiaj między innymi będziemy rozmawiać o rozwoju w roli DevOpsa, więc z pewnością zapytam Was jeszcze trochę głębiej o materiały czy źródła wiedzy. Ale myślę, że na początku dobrze byłoby wyjaśnić taki podstawowy temat, czyli kim jest DevOps. Albo czym, bo mam wrażenie, że trwa taka dyskusja, czy to jest bardziej filozofia, czy to jest bardziej rola. Więc gdybyście mogli powiedzieć, jaki zakres obowiązków według Was wykonuje inżynier DevOps, jeśli tak już mamy nazwać rolę, jakie zadania na co dzień wykonuje? W jakich projektach można taką rolę znaleźć, a w jakich niekoniecznie?

 

T.S.: Zacznijmy od tego, że samo pojęcie DevOps jest przede wszystkim kulturą organizacyjną promującą współpracę pomiędzy działami wytwarzania oprogramowania, czyli development oraz zarządzania systemami, czyli operations. Stąd DevOps skupia się na płynnej komunikacji pomiędzy zespołami technicznymi odpowiedzialnymi za rozwój i dostarczanie produktu do klienta końcowego, zmniejszając jednocześnie tarcia pomiędzy tymi różnymi zespołami.

 

DevOps jest przede wszystkim kulturą organizacyjną promującą współpracę pomiędzy działami wytwarzania oprogramowania, czyli development oraz zarządzania systemami, czyli operations. Stąd DevOps skupia się na płynnej komunikacji pomiędzy zespołami technicznymi odpowiedzialnymi za rozwój i dostarczanie produktu do klienta końcowego, zmniejszając jednocześnie tarcia pomiędzy tymi różnymi zespołami. 

 

Jako inżynier, DevOps jest w pewien sposób łącznikiem pomiędzy światem programistów oraz administratorów. Z jednej strony zajmuje się instalacją, konfiguracją oraz administracją systemami operacyjnymi i różnymi usługami, jednocześnie automatyzując te prace, pisząc nieraz skomplikowane skrypty w Bashu, PowerShellu czy Pythonie lub wykorzystując inne narzędzia do zarządzania konfiguracją czy opisując w konkretnym języku całe infrastruktury. Przygotowuje i rozwija ścieżki ciągłej integracji, dostarczając i wdrażając oprogramowanie, ułatwiając w ten sposób życie programistom i pomagając im w pewien sposób w spełnieniu oczekiwań biznesowych. DevOps jest często kojarzony i niejako zamykany w ujęciu chmury obliczeniowej, takiej jak AWS czy GCP. Jednak według mnie nie powinniśmy o nim myśleć tylko w ten sposób.

Współpraca pomiędzy działami programistów i administratorów oraz automatyzacja procesów wykracza daleko poza tylko ten wycinek IT. Chmura oczywiście z jednej strony ułatwia, a z drugiej w pewien sposób wymusza wykorzystywanie praktyk DevOps poprzez oferowanie różnych funkcjonalności. Jeżeli mamy do dyspozycji jakąś funkcjonalność czy API, które pomaga nam na przykład w przyspieszeniu wdrażania nowych wersji aplikacji czy podnosi bezpieczeństwo systemu, grzechem jest z tego nie skorzystać. 

Jedna z zabawniejszych definicji inżyniera DevOps, która zapadła mi w pamięci, opisuje go jako kogoś, kto rozwiązuje problemy, o których nie wiedziałeś, że je masz w sposób, którego nie rozumiesz. Jestem w stanie w pewien sposób się z tym zgodzić. Zaawansowany inżynier DevOps stale poszukuje nowych rozwiązań problemów, z którymi mógł mieć do czynienia już wielokrotnie. Chodzi o to, aby stale poprawiać i usprawniać to, co jest możliwe do poprawy i usprawnienia z wykorzystaniem innych lub nowych rozwiązań, które odkryło się w między czasie.

 

Czy na bazie Twoich doświadczeń z LCloud, z klientami, z którymi współpracujecie można powiedzieć, że jest jakiś typ projektów albo kilka typów projektów wielkościowych czy technologicznie zorientowanych, w których taka rola ma sens, a w innych nie ma? Czy raczej ciężko wyznaczyć takie granice i tak naprawdę każdy projekt będzie czerpał jakąś wartość z podejścia DevOpsowego?

 

J.B.: Wszystko zależy od projektu i zastosowanego rozwiązania technologicznego w tym projekcie, ponieważ jest to też uzależnione od wymagań, jakie stawia przed nami klient. I oczywiście, jeśli jest to na tyle prosta infrastruktura, że nie wymaga zbyt skomplikowanych rozwiązań od strony infrastruktury czy dostarczania aplikacji poprzez deployments CI/CD, to wtedy tak, może być taka sytuacja, że developer czy administrator systemowy, tak zwany SysOps, może w takim projekcie być wystarczający, jeśli poznał usługi cloudowe, tę technologię, w której ma wykonać rozwiązanie. Tak myślę. 

 

Jasne. Myślę, że to jest bardzo dobra odpowiedź. Mnie z kolei bardzo bliski jest świat startupowy. Często startuje się tam z jakąś ideą, z jakimś pomysłem, z jakimś NVP, które należy zweryfikować, walcząc z czasem i z kosztami. Więc oczywiście taka rola jest dodatkowym kosztem, niekoniecznie nawet uzasadnionym technologicznie, tak jak Jacku powiedziałeś. Nie wiem, czy się ze mną zgodzicie, że taka rola czy taka osoba inżyniera może dołączyć w późniejszym etapie, kiedy już ten projekt, ta firma dojrzewa, chce pewne procesy, pewną komunikację usprawnić i wtedy ten DevOps nie musi być od samego początku na pokładzie. Dołączając w późniejszej fazie również może wnieść znacząco dużo wartości.

 

J.B.: Może bym do końca się jednak nie zgodził z tą opinią.

 

Ok, świetnie.

 

J.B.: Wszystko zależy od projektu, ponieważ ja się bardzo często spotykam z tym, że w startupach jednak jest aspiracja zbudowania dużej infrastruktury, która będzie docelowa dla klienta. Jeśli już na początku zaniedbamy pewne dobre praktyki, które powinniśmy rozpocząć od tworzenia infrastruktury czy też zaprojektowania aplikacji w ten sposób, żeby się na przykład poprawnie skalowała i żeby później programiści mogli w dobry sposób rozwijać aplikację, która będzie miała taką możliwość zwiększania trafficu z Internetu, to później może być po prostu z tym problem, ponieważ zmiany mogą być dla kogoś kosztowne, a wręcz firma może stwierdzić, że ten cloud nie jest taki idealny, ponieważ może jest i droższy, tak patrząc od strony kosztowej, niż jakieś rozwiązanie on-premise.

Myślę, że DevOps nie będzie potrzebny, jeśli wykorzystamy aplikacje, na przykład e-commerce, która jest już standardowa, monolityczna, która już od dziesięciu czy dwudziestu lat jest wdrażana. Jeśli klient chce prostą konfigurację, wtedy faktycznie DevOps nie jest potrzebny, ponieważ administrator może przygotować konfigurację jeden do jeden na cloudzie, tak jakby to przygotował on-premise. Ale wtedy nie wykorzystujemy tych wszystkich dobrodziejstw rozwiązań chmurowych.

Jasne, rozumiem. Myślę, że z jednej strony to podejście DevOpsowe jest całkiem młode, nawet jak na naszą branżę, to jest de facto kilka lat, kiedy mówi się i rozwija to podejście. Z drugiej strony, nie ma uniwersytetów, które kształcą w tym kierunku, więc ci ludzie muszą się skądś brać. Jak się spojrzy na ścieżkę kariery zawodowej inżyniera DevOps, to zazwyczaj miał on swoje początki w różnych aspektach IT, niekoniecznie na przykład w administracji serwerami, co wydaje się najbardziej oczywiste, ale to nie zawsze jest w ten sposób. Czy możecie zdradzić, jak to wyglądało w Waszym przypadku? Jakie drogi Was doprowadziły do roli czy odpowiedzialności DevOpsa? Jak wyglądał Wasz rozwój zawodowy?

 

T.S.: Może na moim przykładzie. Moja historia kariery zawodowej jako DevOpsa w pewien sposób zaczęła się już na etapie liceum oraz studiów inżynierskich. Początkowo kierowałem się w stronę kariery jako programista, z uwagi na duży nacisk położony na kwestie programowania i algorytmiki w liceum, do którego uczęszczałem. Mogę powiedzieć, że miałem to szczęście trafić na nauczyciela, który zainteresował mnie programowaniem w C++, dzięki czemu zdobyłem podstawy i nabrałem dobrych nawyków, które przekładają się na inne języki, z którymi mam większą styczność. 

Następnie, na etapie studiów inżynierskich skierowałem się bardziej w stronę administracji systemami Linux i sieciami, z uwagi na brak profilu typowo programistycznego w ofercie uczelni, którą wybrałem. Myślę, że to złożyło się w pewien sposób na dobre podstawy pod mój przyszły rozwój jako DevOps. Jednocześnie muszę powiedzieć, że nie ograniczałem się tylko do zadań otrzymywanych od wykładowców, ale spędzałem również długie godziny i wieczory nad poszerzaniem zdobytej wiedzy oraz testowaniem różnych innych języków, rozwiązań, konfiguracji czy narzędzi dostępnych na rynku.

W trakcie studiów, zacząłem też pracę w małej firmie hostingowej, która umożliwiła mi nabycie większego doświadczenia jako administrator. Popełniłem w tym czasie wiele różnych skryptów, które automatyzowały wybrane części konfiguracji istniejącej i nowej części infrastruktury. Tego typu zadania sprawiały, że widziałem sens w tym, co robię i nie muszę spędzać wielu godzin na powtarzaniu tych samych czynności i konfiguracji. W tym czasie, nie wiedziałem jeszcze, że to skieruje mnie na drogę DevOpsa.

Następnie zdecydowałem się na dołączenie do LCloud jako administrator systemów, który będzie miał okazję pracować z chmurą AWS. Pierwsze projekty, w które zostałem zaangażowany, sprawdzały moją wiedzę pod kątem administracji systemami Linux oraz krok po kroku umiejętności automatyzacji różnych aspektów konfiguracyjnych. Wtedy właśnie Jacek zauważył moje predyspozycje do roli DevOpsa i wyjaśnił mi wszystkie założenia oraz wymagania, które musiałbym spełnić. I tak zacząłem zagłębiać się w ten świat pracując nad różnymi projektami, poznając nowe zagadnienia teoretyczne oraz chmurę AWS i metody automatyzacji od praktycznej strony.

 

Myślę, że kluczowe są tu różnorodne, bogate doświadczenia, bo jednak w podejściu DevOpsowym chodzi o to, żeby usprawniać komunikację. W związku z tym trzeba przykładać ucho do różnych ruchomych części systemu, rozmawiać z różnymi działami w firmie. Różnorodność doświadczeń, nie tylko administracyjnych, ale i programistycznych, nieraz i testerskich jest tu jak najbardziej na plus. Jeśli popatrzymy na tę wstęgę DevOpsową, to mamy przynajmniej kilka różnych odpowiedzialności i fajnie jest, jeśli inżynier DevOps ma jakieś doświadczenia przynajmniej z kilkoma, bo to pozwala mu lepiej w tym modelu działać.

Umiejętności miękkie to jest też bardzo ważny aspekt, ponieważ inżynier DevOps z założenia musi usprawniać komunikację. O tym jeszcze będę chciał z Wami za chwilę porozmawiać. Ale wyjdźmy od tego, co jest niezbędne w tej roli, co też, mam wrażenie, jest najczęściej sprawdzane na rozmowach rekrutacyjnych, czyli od twardych umiejętności merytorycznych. Powiedzieliśmy, że chmura w dzisiejszych czasach to jest już minimum, niezbędna rzecz, która, przynajmniej jedna, w jakimś stopniu powinna być opanowana przez inżyniera DevOps. Czy coś jeszcze z twardych umiejętności, kompetencji technicznych przychodzi Wam do głowy, jeśli chodzi o umiejętności DevOpsa?

 

J.B.: Na pewno w wybranych projektach ciągle DevOps musi administrować systemami operacyjnymi, jak już powiedzieliśmy, Linux czy Windows, więc to na pewno się przydaje jako doświadczenie. Wiele zadań wymaga prac nad automatyzacją różnych procesów, więc w tym wypadku dochodzi doświadczenie w programowaniu, z czym niekoniecznie każdy administrator wcześniej miał do czynienia. To jest rzecz, którą musi nabyć lub którą po prostu wykorzystywał być może w pracy, będąc trochę programistą, trochę administratorem. Teraz jest to u DevOpsa jednak niezbędna rzecz. 

Ważnym aspektem, na który jest teraz kładziony duży nacisk jest, aby każde rozwiązanie cloudowe było bezpieczne jako środowisko, stąd ważne jest, żeby rozumieć działania sieci i mieć znajomość zagadnień związanych z bezpieczeństwem. Nową technologią, która pojawiła się z DevOpsem i w którymś momencie z chmurami obliczeniowymi jest konteneryzacja rozwiązań Docker Kubernetes. W tym momencie stało się to również niezbędnym rozwiązaniem, które można nabyć w tym momencie lub już wcześniej, nie wykorzystując jeszcze nawet rozwiązań chmurowych. 

Poza wiedzą techniczną ważne jest doświadczenie procesowe, bo DevOps to nie jest już tylko technologia, ale też kultura pracy i ważnym aspektem jest standaryzacja rozwiązań na poziomie całej firmy czy projektów w zakresie narzędzi czy technologii, którą DevOps czy grupa DevOpsów wykorzystuje do codziennej pracy.

 

Jacku, powiedziałeś o językach programowania i jeśli mogę coś to dodać, to widziałbym tutaj pewne rozróżnienie. Z jednej strony, to jest faktycznie znajomość języka programowania w stopniu umożliwiającym pisanie skryptów automatyzujących, a z drugiej strony, nie wiem, czy się ze mną zgodzicie, coś, co leżało trochę u podstaw powstania podejścia DevOpsowego. Czyli zbliżenie części deweloperskiej i części operacyjnej z założeniem, że taka osoba zna w jakiś sposób stack technologiczny, rozwiązania programistyczne, żeby móc je testować, coś w nich usprawniać czy właśnie modyfikować albo wpływać jakoś na security tych rozwiązań. Czy według Was jesteśmy właśnie w tym punkcie? Czy obecnie inżynier DevOps w jakiś sposób jest częścią zespołu programistycznego i powinien znać na przykład język czy też stack technologiczny projektu? Czy też nie jest to niezbędne i na co dzień jest po prostu nieprzydatne?

 

T.S.: Według mnie DevOps niekoniecznie musi być programistą. DevOps nie jest rozszerzoną rolą programisty. Oczywiście nie oznacza to, że programiści nie mogą być DevOpsami, mam tu na myśli to, że DevOps ma zupełnie inne zadania, wyzwania i cele niż tworzenie oprogramowania. Tak więc DevOps nie jest programowaniem, ponieważ są to po prostu różne kultury. To różnica, która jest dosłownie częścią nazwy DevOps, czyli rozwój i operacje. DevOps nie jest według mnie także zaawansowanym programistą, chociaż posiadane doświadczenie programistyczne może mu pomóc w wielu kwestiach.

 

DevOps nie jest rozszerzoną rolą programisty. Oczywiście nie oznacza to, że programiści nie mogą być DevOpsami, mam tu na myśli to, że DevOps ma zupełnie inne zadania, wyzwania i cele niż tworzenie oprogramowania. Tak więc DevOps nie jest programowaniem, ponieważ są to po prostu różne kultury. To różnica, która jest dosłownie częścią nazwy DevOps, czyli rozwój i operacje. DevOps nie jest według mnie także zaawansowanym programistą, chociaż posiadane doświadczenie programistyczne może mu pomóc w wielu kwestiach. 

 

Są też inżynierowie DevOps, którzy nigdy wcześniej nie pełnili funkcji jako programista, a mają doświadczenie głównie jako administrator systemów i sieci i potrafią się odnaleźć lepiej w takiej roli niż programista z wieloletnim doświadczeniem.

 

Tak, ja w swoich projektach też mam do czynienia z osobami, które mają i jeden i drugi background, tak jak Tomku powiedziałeś, i faktycznie widzę ich mocne strony w innych aspektach. To się da zauważyć dosyć szybko.

Mamy mniej więcej zarysowany obszar merytoryczny, za chwilę będę chciał go trochę pogłębić. Natomiast inną bardzo ważną cechą w zmniejszaniu barier komunikacyjnych jest posiadanie pewnych umiejętności miękkich, o których coraz szerzej, coraz więcej się mówi w IT. Czy według Was jest jakiś zakres umiejętności, nad którymi DevOps powinien pracować, które mu na co dzień mogą pomóc w pracy?

 

J.B.: Tak, nad niektórymi umiejętnościami możemy pracować, ale są też umiejętności zawarte w charakterze osoby. Na pewno chęć poszerzania wiedzy, motywacja, żeby poszerzać tę wiedzę, ponieważ rozwiązania chmurowe rozwijają się bardzo szybko i dynamicznie. Z każdym dniem pojawiają się nowości, które mogą zasugerować lepsze, efektywniejsze rozwiązanie w danym projekcie, czego jeszcze wczoraj byśmy nie wymyślili sami albo bez tego rozwiązania, które się dzisiaj akurat pojawiło. Stąd DevOps musi wykazywać dużą ciekawość pojawiających się nowych rozwiązań. 

Dzięki temu, że dostawcy chmurowi przygotowują swoje usługi, cloud DevOps ma możliwość użycia wielu gotowych technologii, skonfigurowanych już pod wykorzystanie. Dlatego też nie może być zamknięty na jedno rozwiązanie, ponieważ ma możliwość łatwego wdrażania różnych usług w szybkim czasie. Powoduje to, że te rozwiązania mogą być bardziej efektywne, dostosowane do danego etapu projektu od strony tworzenia aplikacji. 

Inną ważną umiejętnością jest zwinność i elastyczność podejścia do realizowania zadań i projektów. Jest to bardzo ważne, aby DevOps mógł szybko zebrać informacje zwrotne, naprawić błędy na wczesnym etapie budowania aplikacji, inspirować deweloperów o dalszym kierunku budowania aplikacji.

 

Tak, to jest bardzo ważna rzecz. A czy z Waszej praktyki wynika, że DevOps jest trochę dalej od klienta końcowego, użytkownika końcowego niż na przykład deweloper i feedback, informacja zwrotna może do niego nie trafiać? Nie macie takiego wrażenia?

 

J.B.: Na pewno klient końcowy jest skupiony głównie na aplikacji i to też jest kwestia tego, na ile on ma świadomość, żeby nie skupiać się tylko na informacji od dewelopera, w jaki sposób aplikacja będzie ładnie wyglądała od strony front-endu, ale brać pod uwagę budowanie profesjonalnej aplikacji, która wykorzysta wszystkie dobrodziejstwa chmury. Jednak ma też obok DevOpsa i jego zdanie nie jest pomijane.

 

Myślę sobie, że w narzędziowniku inżyniera, niezależnie od tego, czy to jest inżynier budownictwa, oprogramowania czy DevOps, jest pewien zestaw narzędzi, które powinny być przez niego opanowane i używane w codziennych projektach. Czy jest taki toolset, zestaw narzędzi w roli inżyniera DevOps, który według Was jest pewnym standardem, który powinien być przez niego opanowany? Istnieje coś takiego?

 

T.S.: Według mnie ciężko jest wymienić konkretne narzędzia czy technologie wykorzystywane przez inżyniera DevOps, ponieważ one mogą się różnić znacznie w zależności od projektu, w którym będzie zaangażowany. W ramach różnych dostępnych obszarów jest szereg różnych narzędzi, z których każdy ma swoje plusy i minusy. DevOps nie jest ograniczony do jednego stacka technologicznego według mnie. 

 

Według mnie ciężko jest wymienić konkretne narzędzia czy technologie wykorzystywane przez inżyniera DevOps, ponieważ one mogą się różnić znacznie w zależności od projektu, w którym będzie zaangażowany. W ramach różnych dostępnych obszarów jest szereg różnych narzędzi, z których każdy ma swoje plusy i minusy. DevOps nie jest ograniczony do jednego stacka technologicznego według mnie. 

 

Od kilku lat popularne jest na przykład budowanie mikroserwisów i ich konteneryzacja, zapewniająca między innymi ich niezależny rozwój i przenośność. Aktualnie natomiast coraz bardziej popularne stają się rozwiązania oparte o Serverless, które w dużym stopniu wykorzystują języki programowania, takie jak node.JS czy Python. Tak naprawdę, poprawnym rozwiązaniem jest to, które unika rozwiązań monolitycznych, a daje możliwość niezależnego skalowania różnych warstw, jak front-end, back-end czy baza danych.

Spróbuję może podać kilka przykładów popularniejszych narzędzi, jednak muszę zaznaczyć, że będzie to tylko moja subiektywna opinia na dzień dzisiejszy, na podstawie doświadczeń moich i LCloud. Zacznijmy może od takiego podstawowego zestawu umiejętności obowiązkowych, które powinien prezentować DevOps. Wyróżniłbym w tym miejscu na pewno umiejętność pracy z repozytorium kodu i rozumienie procesu wytwarzania oprogramowania. Każdemu DevOpsowi przyda się również umiejętność programowania. Jako DevOps często musimy przygotowywać bardziej złożone skrypty, czasem takie, których napisanie w Bashu czy PowerShellu nie będzie miało większego sensu. Myślę, że w takim wypadku Python jest dobrym kierunkiem dla DevOpsa, ponieważ jest wszechstronny i względnie łatwy do nauczenia się. 

Jednym z głównych obszarów pracy DevOpsa jest przygotowanie i zarządzanie infrastrukturą oraz konfiguracją. Automatyzacja zarządzania tym obszarem pozwala na wyeliminowanie częstych błędów i problemów związanych z ręcznymi konfiguracjami, a także jest jednym z podstawowych elementów planu ekspansji czy odzyskiwania po awarii. Myślę, że warto jest wyróżnić takie narzędzia, jak Terraform, które wykorzystywane jest do zarządzania infrastrukturą jako kodem niezależnie od usług chmurowych, z których korzystamy oraz Ansible czy Chef, których podstawowym założeniem jest automatyzacja zarządzania konfiguracją.

Jeżeli pracujemy z konkretnym dostawcą usług chmurowych, warto jest także poznać przynajmniej podstawowe narzędzia, które udostępnia w swoim asortymencie. Na przykładzie AWS będzie to usługa Cloudformation, która jest odpowiednikiem Terraform czy Systems Manager, która w ramach dostarczanych funkcjonalności ułatwia zarządzanie konfiguracją serwerów.

Drugim z głównych obszarów jest automatyzacja procesów integracji, dostarczania i wdrażania, czyli tak zwane CI/CD. Dobrze zorganizowane procesy realizujące budowanie, testowanie i wdrażanie aplikacji znacznie skracają czas wytwarzania oprogramowania oraz umożliwiają zachowanie jego wysokiej jakości. Wśród najpopularniejszych czy najczęściej spotykanych rozwiązań są: Jenkins, który jest serwerem wykorzystywanym do automatyzacji części lub całości procesu CI/CD czy też GitLab, który dostarcza pełen zestaw funkcjonalności od systemu kontroli wersji po konfigurację pełnej ścieżki, integracji, dostarczania i wdrażania oprogramowania. Odpowiednikami usług oferowanych przez AWS będą tutaj CodePipeline, CodeBuild i CodeDeploy i na nie zwróciłbym szczególną uwagę, jeżeli naszym dostawcą chmurowym jest AWS.

Kolejnym obszarem, który jest cały czas na topie i na który trzeba zwrócić uwagę są mikroserwisy, ich konteneryzacja i zarządzanie nimi. Oczywiście podstawą jest tutaj Docker, chociaż nie jest to jedyna platforma kontenerów, to na pewno jest ona najbardziej popularna i każdy DevOps będzie miał z nią i z kontenerami do czynienia na pewnym etapie swojej kariery. Jeżeli chodzi o zarządzanie kontenerami, to niewątpliwym liderem jest tutaj Kubernetes. Aktualnie praktycznie każdy z większych dostawców usług chmurowych oferuje gotową usługę, która pozwala na szybkie uruchomienie klastra kubernetesowego. Na przykładzie AWS jest to EKS, czyli Elastic Container Service.

 

Powiedzieliśmy, że chmura jest jedną z podstawowych kompetencji, która musi wchodzić w skład toolsetu DevOpsa. Z chmurą kojarzą mi się między innymi certyfikaty czy też ścieżki certyfikacyjne prowadzone przez głównych dostawców usług chmury publicznej. Czy są jakieś certyfikaty związane z chmurą, może nawet szerzej, które według Was stanowią jakąś wartość w pracy DevOpsa? Zarówno jeśli chodzi o umiejętności, które dają, jak i pewną przewagę w procesach rekrutacji na przykład.

 

J.B.: Tak, dokładnie. Poza certyfikatami chmurowymi są inne certyfikaty, na które zwracamy uwagę. Warto pamiętać o certyfikatach związanych z kontenerami, Docker czy Kubernetes. Na rynku i u nas cenione są też certyfikaty od firmy HashiCorp, między innymi od rozwiązania Terraform. Na pewno ciągle ważne są certyfikaty, które warto utrzymywać czy robić z zarządzania systemami, Linux czy Windows, ponieważ jednak w większości projektów to DevOps odpowiada za zarządzanie tymi systemami operacyjnymi. Wymieniłbym może też certyfikat z obszaru metodyk zwinnych, na przykład Agile, który obok tych technologicznych jest takim dobrym uzupełnieniem. Dobrze żeby DevOps też miał tę orientację, ponieważ jednak bardzo często ta technologia jest wykorzystywana w projektach.

 

Jasne, o tym ostatnim nie pomyślałem, ale w sumie ma to duży sens, skupiać się nie tylko na technologicznych certyfikatach, ale również na takich bardziej związanych z procesami. Może to być spora wartość. Czy dla Ciebie, Jacku, jako osoby, która rekrutuje inżynierów DevOps, te certyfikaty o czymś mówią? Czy osoba, która je posiada może mieć jakąś przewagę w procesie rekrutacji?

 

J.B.: Na pewno na początku tak, w pierwszej fazie naszej rekrutacji, ponieważ CV z certyfikatami pokazuje, że ktoś faktycznie ma przynajmniej wiedzę teoretyczną, skoro zdał te certyfikaty. Ale oczywiście musimy pamiętać, czy osoby zdające certyfikaty muszą pamiętać o wiedzy praktycznej. Zauważyliśmy, że jest taki syndrom na rynku, że dużo osób też może nie ma możliwości uzyskania wiedzy praktycznej, więc zaczyna od tej wiedzy teoretycznej, zdobywając te certyfikaty, które na pewno dają większą możliwość wejścia do jakiegoś projektu czy do firmy jako DevOps. My jako dostawca chmury obliczeniowej patrzymy jednak też na praktykę, ponieważ praktyki nie da się nauczyć. Trzeba to wypracować, miesiące czy lata pracy nad różnymi projektami. Jednak w takiej ostatecznej dla nas decyzji o wybraniu kandydata, to praktyka ma większe znaczenie.

 

Właśnie, miałem zapytać o to, jak budować kompetencje merytoryczne. Po części na to odpowiedziałeś. Wiadomo, najlepiej w praktyce. Podejście do certyfikatu może być jakimś wstępem do uzyskania kompetencji merytorycznej. Tam też bardzo często podczas robienia certyfikatu czy też przechodzenia tej ścieżki musimy faktycznie jakąś pracę praktyczną wykonać, natomiast nie zawsze mamy możliwość zasymulowania takich środowisk, takiej kultury organizacyjnej, jak w realnych projektach. Chmura nam to być może jakoś upraszcza, da się nawet, korzystając z darmowych kredytów za zero dolarów, pewne rzeczy zrobić, ale mimo wszystko to zawsze są jakieś przybliżenia. Jak według Was najlepiej takie kompetencje merytoryczne budować?

 

T.S.: Może zaczniemy od wyjaśnienia różnicy pomiędzy samymi umiejętnościami i kompetencjami, jakie powinien posiadać DevOps. Chociaż umiejętności są ważną częścią uczenia się, nie wystarczą, aby poprowadzić ludzi do prawdziwego mistrzostwa i sukcesu. Umiejętności skupiają się na wiedzy potrzebnej danej osobie do wykonania określonego zadania. Kompetencje przenoszą jednak umiejętności na wyższy poziom, przekładając je na zachowania, które demonstrują to, co zostało opanowane. Kompetencje będą obejmowały dynamiczną kombinację umiejętności, postaw, zachowania, a także wiedzy. 

 

Chociaż umiejętności są ważną częścią uczenia się, nie wystarczą, aby poprowadzić ludzi do prawdziwego mistrzostwa i sukcesu. Umiejętności skupiają się na wiedzy potrzebnej danej osobie do wykonania określonego zadania. Kompetencje przenoszą jednak umiejętności na wyższy poziom, przekładając je na zachowania, które demonstrują to, co zostało opanowane. Kompetencje będą obejmowały dynamiczną kombinację umiejętności, postaw, zachowania, a także wiedzy. 

 

Budowanie kompetencji merytorycznych DevOpsa zacząłbym od zbudowania i ugruntowania wiedzy w podstawowych obszarach administracji systemami operacyjnymi oraz z tworzenia skryptów i oprogramowania. Następnie przeszedłbym do pracy z wybranymi usługami chmurowymi, zaczynając od tych bardziej podstawowych, aby dobrze zrozumieć założenia, a następnie przechodząc płynnie do zarządzania zasobami i infrastrukturą jako kodem. Ważne jest także zbudowanie doświadczenia z zakresu kontenerów, ich budowania oraz zarządzania nimi. Dalej istotne jest poznanie zagadnień związanych z ciągłym dostarczaniem rozwiązań i oprogramowania. 

Gdzie i jak konkretnie budować te kompetencje? Myślę, że dobrze jest rozpocząć to od zapisania planów i przemyśleń, które będą pomocnym narzędziem podczas tworzenia planu budowania swoich kompetencji. Ważna jest na pewno praca w różnych projektach, które będą dawały DevOpsowi możliwość rozwijania już nabytych i zdobywania nowych umiejętności oraz kompetencji. Prawie każdy lider może wskazać mentora, który odegrał kluczową rolę w jego sukcesie. W LCloud także praktykujemy mentoring i każdemu nowemu DevOpsowi jest przydzielany mentor, którego zadaniem jest pomoc w usystematyzowaniu jego wiedzy oraz nabyciu odpowiednich kompetencji. Istotne jest także, w mojej opinii, uczenie się poza codzienną pracą, uczestniczenie w konferencjach i webinariach oraz czytanie i testowanie.

 

Myślę, że mentoring to jest bardzo fajna metoda, żeby tę wiedzę przekazywać czy po prostu poszerzać w zespole. A doskonale wiemy, że w naszej branży poszerzanie swoich kompetencji, rozszerzanie swojej wiedzy powinno występować praktycznie na porządku dziennym, ponieważ ta branża zmienia się tak szybko i dynamicznie. Na początku powiedzieliście trochę na temat interesujących materiałów, które lubicie obserwować, oglądać, słuchać, czytać. Chciałbym Was jeszcze dopytać o to, jak albo skąd najlepiej pozyskiwać wiedzę na temat nowinek, nowych technologii, rekomendacji, co do technologii. Czy są takie miejsca, które możecie polecić?

 

J.B.: Bardzo cennym źródłem informacji oczywiście jest Internet, tutaj niczym nie zaskoczę, gdzie ilość artykułów, blogów czy nagrań wideo związanych z tematyką DevOps jest w tym momencie ogromna, dokładnie ze względu na ten bardzo szybki i dynamiczny rozwój tej dziedziny. Dodatkowo uważam, że warto wspomnieć o płatnych czy bezpłatnych konferencjach, spotkaniach Meetup organizowanych w wielu miastach, które bardzo często są połączone z warsztatami, co jest dodatkową wartością dla osób, które chcą zostać DevOps albo są i chcą poszerzyć tę wiedzę, ponieważ oprócz posłuchania o dobrych praktykach mogą też wymieniać się doświadczeniami z innymi osobami.

 

Teraz chciałbym Was zapytać o ścieżkę kariery, która może być udziałem inżyniera DevOps. W przypadku programistów najczęściej zaczynamy na stanowiskach juniorskich, później, poprzez mid czy regular, dochodzimy do seniorskich. Potem zależnie od organizacji są to jeszcze architekci, principal deweloperzy i tak dalej. Natomiast ten trzon jest tak mniej więcej już w tej branży ustalony. Jak to może wyglądać w przypadku DevOpsa? Jak może wyglądać taka przykładowa ścieżka kariery inżyniera DevOps?

 

T.S.: To, jak danemu inżynierowi potoczy się ścieżka kariery zależne będzie od wielu czynników. Może się ona równie dobrze zacząć od programisty czy administratora systemów. Kandydat na DevOpsa powinien na początku przejść etap usystematyzowania swojej wiedzy i podnoszenia kwalifikacji, w ramach którego nabywa niezbędnej wiedzy teoretycznej z wybranych obszarów oraz posługiwania się wybranymi narzędziami. Nie powinno tu zabraknąć zaznajomienia się z wybranym dostawcą chmury obliczeniowej i dostępnymi metodami automatyzacji. Po tym etapie, myślę, że możemy określić go mianem junior DevOpsa. Ma już pewne umiejętności i znajomość wybranych narzędzi, jednak nie będą one poparte praktycznym doświadczeniem. 

Podczas pracy nad kolejnymi projektami, junior DevOps nabiera konkretnego doświadczenia z wykorzystania wcześniej zdobytej wiedzy. Pracuje pod okiem kogoś bardziej doświadczonego, kto wprowadza go w kolejne zagadnienia, aby osiągnąć pozycję mid DevOpsa. Bardzo ważne jest, by próbował cały czas nowych rzeczy, narzędzi i rozwiązań, aby szukał swojego ulubionego środowiska pracy i podnosił swoje kwalifikacje. Po pewnym czasie taki DevOps staje się seniorem, który niczego się już nie boi. I ten senior DevOps nie powinien mieć oporów przed zrobieniem czegoś, czego nigdy wcześniej nie robił. Wynika to tak naprawdę z jego doświadczenia, które pozwala mu na przełożenie znanych mu już konceptów na nowe narzędzia i nowe zagadnienia. Dla seniora ważne jest, że nie opiera się tylko na znajomości wielu różnych narzędzi, ale ma także rozwinięte umiejętności miękkie.

 

Rozumiem. A czy w takiej codziennej pracy są jakieś rzeczy, które Wam bardzo przeszkadzają, bardzo uwierają? Czy ta praca ma jakieś cienie?

 

T.S.: Oczywiście, pomimo wszelkich zalet i blasków pracy DevOpsa, znajdują się też tutaj pewne cienie. Nie chciałbym jednak za bardzo się nad nimi rozwodzić, aby nie zniechęcić potencjalnych przyszłych DevOpsów. Do głównych minusów zaliczyłbym przede wszystkim konieczność znajomości bardzo szerokiego spektrum rozwiązań technicznych i technologicznych oraz bycia stale na bieżąco z nowinkami. Zgromadzenie wiedzy z różnych obszarów, które łączy DevOps oraz nabranie niezbędnego obycia i praktyki zajmuje sporo czasu. Przechodząc z jednego projektu do kolejnego, niejednokrotnie wszystkie poprzednio używane narzędzia i wypracowane rozwiązania mogą być całkowicie zastąpione przez inne, co niejako wymusza stałą adaptację i poznawanie nowych rzeczy. To wymaga czasu i samozaparcia i, w mojej opinii, jeżeli ktoś nie jest pasjonatem, może to dla niego oznaczać barierę nie do przeskoczenia.

Jeżeli lubisz pracować w roli, która jest często nie do końca zdefiniowana, wysoce odpowiedzialna, łatwo ją obwinić, gdy coś idzie nie tak i walczysz nie tylko z działem rozwoju oprogramowania, ale także ze sprzętem, siecią i politykami bezpieczeństwa, to DevOps jest dla Ciebie. Wiem, że sprawiłem teraz, że brzmi to okropnie, ale to nie lada przygoda. I masz możliwość pracować w różnych działach. DevOps to z pewnością rola, w której musisz czerpać przyjemność z pracy z wieloma różnymi ludźmi i zespołami, zaspokajając ich miejscami konkurencyjne plany i posiadając wielu szefów. DevOps jest prawie bardziej powołaniem i podobnie jako powołanie wymaga dużo czasu i poświęceń. Będziesz za kulisami, a wielu nie będzie wiedziało dokładnie, jaką pracę wykonujesz.

 

Jeżeli lubisz pracować w roli, która jest często nie do końca zdefiniowana, wysoce odpowiedzialna, łatwo ją obwinić, gdy coś idzie nie tak i walczysz nie tylko z działem rozwoju oprogramowania, ale także ze sprzętem, siecią i politykami bezpieczeństwa, to DevOps jest dla Ciebie. Wiem, że sprawiłem teraz, że brzmi to okropnie, ale to nie lada przygoda. I masz możliwość pracować w różnych działach. 

 

Bardzo misyjne podejście, ale bardzo mi się podoba. Tomku, powiedziałeś, że to jest często taka nie do końca zdefiniowana rola, że ten zestaw odpowiedzialności może się zmieniać w zależności od projektu, może być płynny, może być sporo niedopowiedzeń. W sumie powinienem o to zapytać na początku, ale chciałbym, żeby to jednak wybrzmiało. Jak Wy definiujecie różnice w pracy DevOpsa, dewelopera i SysOpsa?

 

J.B.: Może ja odpowiem. Na wstępie powiedzieliśmy, że DevOpsem może zostać deweloper lub administrator SysOps, wykorzystując swoje wcześniejsze doświadczenie. Można wyróżnić dwa typy DevOpsów i nawet do pewnego czasu, aby zostać certyfikowanym DevOps w chmurze u jednego z dostawców, należało wcześniej uzyskać certyfikat SysOps lub deweloper. Ten podział idealnie pokazywał już ścieżkę DevOps. Natomiast później zastosowanie rozwiązań czy wymagań w projekcie definiuje, jaki DevOps do projektu dołączy i jaką kompetencję będzie musiał rozwijać.

W naszych projektach w LCloudzie mamy wyraźny podział, ponieważ DevOpsi, którzy wcześniej byli typowymi deweloperami, ale stwierdzili, że oprócz tworzenia aplikacji chcą jednak poznać zagadnienia DevOps, muszą więcej skupić się na poznaniu zagadnień związanych z siecią, związanych z bezpieczeństwem infrastruktury, aby w najnowszym trendzie Serverless nie musieć skupiać się na zarządzaniu systemem operacyjnym na serwerach, a wyłącznie skupić się na maksymalnym wykorzystaniu gotowych serwisów cloud. Czyli muszą posiadać wiedzę, jak efektywnie zaimplementować serwisy cloudowe do swojej aplikacji poprzez API dostawcy chmurowego czy różnych innych protokołów sieciowych. Podsumowując, w tych projektach DevOps buduje aplikacje w funkcjach cloud wykorzystując gotowe usługi od dostawcy chmury.

Natomiast w przypadku SysOpsa, czyli administratora systemów Linux czy Windows, oprócz poznania usług chmurowych czy technologii chmurowej, która może być też na przykład wykorzystana na lokalnej infrastrukturze, musi uzyskać wiedzę z zakresu konteneryzacji oraz nabyć wiedzę, jak tworzyć skrypt do automatyzacji zadań, procesów, potrzebny do deploymentu aplikacji, czyli procesu budowania, testowania aplikacji, a następnie wdrażania jej na infrastrukturę.

 

Rozumiem. Myślę, że to jest bardzo klarowne, jasne rozróżnienie. Osobiście obserwowałem osoby, które, tak jak mówiliśmy, ewoluowały w swojej ścieżce rozwoju od dewelopera albo wręcz od takiego klasycznego administratora systemów on-premise w kierunku DevOpsa. Motywacje były różne, różne były mocne strony później tych osób, co też miałem okazję obserwować. Czy według Was któraś z tych ścieżek jest lepsza, gorsza? Może którąś Wy osobiście preferujecie w osobach, z którymi współpracujecie?

 

J.B.: Gorsza czy lepsza? Tak naprawdę jest całkowicie inna od strony dewelopera czy administratora. Co najważniejsze, nie trzeba się przekwalifikować, z jednej i drugiej strony wykorzystuje się to, co się umiało wcześniej przed byciem DevOpsem. Możemy założyć, że to kogoś interesowało, ponieważ wiadomo, że jeśli ktoś nie jest programistą, jeśli nie czuje, że to jest dla niego, więc też i tutaj może wykorzystać dokładnie to, co dla niego raczej jest przyjemne z nowym trendem DevOps.

 

Mam jeszcze pytanie związane z tym, jak podchodzi się do rekrutowania DevOpsów. Może to wyglądać nieco inaczej w takiej firmie, jak wasza, LCloud, która jest skupiona na usługach chmurowych, DevOpsowych i to jest jej obszar działania. Inaczej to może wyglądać w firmach, gdzie ta rola nie jest trzonem, ale pewnym dodatkiem. Z ofert pracy bardzo często wynika, że taka firma poszukuje kogoś takiego, kogo ja nazywam administratorem 2.0 albo SysOpsem w chmurze, czyli właściwie kogoś, kto bardziej ogarnia tę chmurę, niż jest DevOpsem. Ale że jest pewna moda, pewien hype na rynku na nazywanie takiej roli DevOps, to tak się to tytułuje. Nie wiem, jak to wygląda z Waszej perspektywy, czy podzielacie taką opinię?

 

J.B.: Tak, zgadzam się. Uważam, że ciągle rola DevOps jest dla wielu managerów w IT czy CTO nowością. Nie mają dokładnie wiedzy o roli DevOps, bo będą zatrudniać dopiero osoby, które będą pierwszymi DevOps w firmie. Ciężko im zobaczyć różnicę podczas zatrudniania odpowiedniego DevOps do swojej firmy. Niestety w takiej sytuacji najbardziej cierpi firma, która może zrazić się do rozwiązań chmurowych, które często zostają wdrożone nieefektywnie przez DevOpsa. Można go nazwać jeszcze administratorem i dopiero zaczyna on nabierać na tym projekcie czy na tej firmie swojego doświadczenia, a wiadomo, że najlepsze są praktyki DevOps. Z mojej obserwacji wynika, że początkujący DevOpsi próbują przenieść identyczną konfigurację z lokalnego środowiska on-premise do środowiska chmurowego.

Inna moja obserwacja, to że klient końcowy czy biznes w firmach dokładnie widzi aplikację, to co już wspominałem wcześniej, czyli zła infrastruktura czy złe zarządzanie oprogramowaniem nie jest na początku widoczne, nie widać tych błędów w rozwiązaniach. Ale w momencie, jak już aplikacja czy produkt, który jest budowany przy rozwiązaniach chmurowych staje się bardziej zaawansowany i w końcu pokazuje te niedociągnięcia, to wtedy zmiana konfiguracji może być kosztowna, ponieważ nie było na to przewidzianego budżetu. Może się nawet okazać, że zmiana konfiguracji jest niemożliwa, ponieważ wprowadza poważne zmiany od strony architektury aplikacji.

 

Mówiliśmy, że praca inżyniera DevOps, to jest trochę miks pracy operacyjnej, związanej chociażby z utrzymaniem infrastruktury w chmurze czy też rozwój, trochę takiej pracy koncepcyjnej, procesowej, komunikacyjnej. Czy wobec tego jesteście w stanie powiedzieć, co jest miarą sukcesu inżyniera DevOps? Kiedy może on o sobie powiedzieć, że zrealizował swoją misję w projekcie czy w firmie? Czy są jakieś KPI-ie, mierniki, coś co Wam przychodzi do głowy?

 

T.S.: Tak, myślę, że moglibyśmy wyróżnić tu wiele różnych metryk i wskaźników, które mogłyby być uznane za miarę sukcesów DevOpsa. Będą one jednak często uzależnione od projektu, w ujęciu którego je rozważamy. Spróbuję zatem ograniczyć się do tych, które uważam za najbardziej ogólne. Za jedną z kluczowych miar sukcesu DevOpsa, niewątpliwie przyjąłbym sukces całego projektu, nad którym pracuje bądź pracował. Jeżeli projekt odnosi sukces, to jest to na pewno po części zasługa jego i jego pracy, którą wykonał nad zapewnieniem płynnego funkcjonowania poszczególnych elementów i wszystkich wprowadzonych automatyzacji rozwiązań. 

Innym ważnym wskaźnikiem jego sukcesu jest, w mojej opinii, dostępność i czas pracy aplikacji oraz całej infrastruktury. DevOps pracuje niestrudzenie nad tym, aby szybko wyłapać problemy, najlepiej jeszcze zanim się ujawnią dla klienta, śledząc i monitorując szereg kluczowych metryk. Potrafi zidentyfikować i zareagować na potencjalne problemy, zanim ktokolwiek mu to zgłosi.

Kolejnym wskaźnikiem sukcesu DevOpsa będzie także ilość wdrożeń, przygotowanie ścieżek ciągłej integracji, dostarczania i wdrażania nowych wersji oprogramowania czy zmian w infrastrukturze systemu w taki sposób, że nie zakłóca to dostępności systemu dla jego użytkownika. Jest to niewątpliwie coś, czego każdy DevOps pożąda.

Jeszcze jedną miarą sukcesu, o której myślę, że warto wspomnieć, jest dotrzymywanie technologicznego kroku biznesowym celom, które są stawiane przed DevOpsem i przed programistami oraz działem wsparcia. Jak już ustaliliśmy wcześniej, DevOps stale testuje nowe rozwiązania, szukając tego, co będzie mógł wykorzystać w swoim środowisku pracy. Musi mieć jednocześnie na względzie wymagania stawiane mu przez biznes, które niejednokrotnie zmieniają się bardzo szybko. Sukcesem DevOpsa, w mojej opinii, będzie to, jak szybko potrafi się dostosować do takich zmian.

 

DevOps stale testuje nowe rozwiązania, szukając tego, co będzie mógł wykorzystać w swoim środowisku pracy. Musi mieć jednocześnie na względzie wymagania stawiane mu przez biznes, które niejednokrotnie zmieniają się bardzo szybko. Sukcesem DevOpsa, w mojej opinii, będzie to, jak szybko potrafi się dostosować do takich zmian. 

 

Jedną z najbardziej poszukiwanych obecnie ról w IT jest właśnie inżynier DevOps, ten rynek jest bardzo chłonny. Chciałbym Was zapytać, jak wygląda obecnie rynek pracy dla inżyniera DevOps. Czy to jest perspektywiczna ścieżka kariery, gdyby ktoś ze słuchaczy zastanawiał się, czy być może w tym kierunku nie pokierować swoją karierą?

 

J.B.: Jak najbardziej, ponieważ jest obecnie ogromna podaż projektów chmurowych i wdrożeń w oparciu o filozofię DevOps. Podczas moich obserwacji rynku zauważam, że sporo osób dysponuje jedynie teoretyczną wiedzą, a małym doświadczeniem projektowym. Doświadczenia nie można uzyskać poprzez tylko nauczenie się do certyfikatu, o czym wspomnieliśmy. Niestety to wymaga pracy, najlepiej w zespole z doświadczonym DevOpsem, a to wymaga znowu czasu, przez co ciągle jest niedomiar wykwalifikowanych, doświadczonych inżynierów. A z drugiej strony mamy podaż na rynku na DevOpsów. Wiele firm, które w ostatnich latach decydują się na migrację do rozwiązań chmurowych, stąd popyt na doświadczonych DevOps będzie rósł.

 

Jacku, Tomku, bardzo Wam dziękuję za ciekawą rozmowę. Cieszę się, że pokazaliście, jak ta rola wygląda od środka, jak się rozwijać jako inżynier DevOps w tym szybko zmieniającym się świecie, myślę, że to jest bardzo potrzebne. Wobec tego zapytam Was jeszcze na koniec, gdzie Was można znaleźć w Internecie, w jaki sposób się z Wami skontaktować?

 

J.B.: Jeśli chodzi o kontakt bezpośredni do nas, to jak najbardziej LinkedIn jest taką dobrą platformą do skontaktowania się z nami. Jeśli chcecie się dowiedzieć czegoś więcej o naszej firmie, to najlepiej wejść na naszą stronę LCloud, przeczytać i zobaczyć dokładnie, czym się zajmujemy. Są obszary, które mogą Was zaciekawić i możecie próbować z nami zdobyć to doświadczenie DevOpsowe, ponieważ, tak jak Tomek wspomniał, jest to jak najbardziej możliwe.

 

Świetnie, oczywiście wszystkie linki będą dodane w notatce do odcinka, zarówno Wasze profile na LinkedInie, jak i strona LCloud. Warto odwiedzić, żeby zobaczyć, jakie usługi oferujecie, jak również, jakie rekrutacje są otwarte i tam szukać też swojego wejścia i rozwoju, jako inżynier DevOps. 

Bardzo Wam dziękuję, wobec tego.

Do usłyszenia, cześć!

 

J.B.: Dziękuję, Krzysztofie!

 

T.B.: Dzięki, cześć!

 

J.B.: Cześć!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Podejście DevOps staje się coraz popularniejsze. Mamy też do czynienia z coraz szerszym wachlarzem technologii i rozwiązań w tej dziedzinie. Umiejętności pożądane u inżyniera DevOps to nie tylko twarde kompetencje, ale i zestaw umiejętności miękkich i warto na to zwrócić uwagę.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się proszę  recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak zostać i rozwijać się jako inżynier DevOps.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!