To jest 50. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o DevOps. Odcinek okrągły, powód do radości dla mnie. Okazja, żeby podziękować Tobie, słuchaczu, że jesteś, wspierasz i słuchasz.

Przypominam, że w poprzednim odcinku poruszyłem temat studiowania informatyki. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/50. 

Chcę poszerzać horyzonty ludzi z branży IT i wierzę, że poprzez wywiady publikowane jako podcasty, takie jak ten, będę to robił z sukcesem. Aby nie przegapić, kolejnych odcinków subskrybuj koniecznie ten podcast. 

Nazywam się Krzysztof Kempiński i życzę Ci miłego słuchania. Odpalamy!

Cześć, mój dzisiejszy gość jest w branży IT, już od ponad 19 lat, pracował jako project manager i service menager. Zajmował się analizą biznesową, brał udział w kilku różnych transformacjach IT oraz zarządza zespołami IT. Obecnie pracuje jako senior project manager w Netguru. Moim i waszym gościem jest Michał Bohuszewicz. 

Cześć Michał, bardzo mi miło gościć Cię ponownie w podcaście. 

Cześć Krzysztof, dziękuję za zaproszenie.

Michał był już niedawno moim gościem, występował w odcinku o Scrumie, do tego odcinka jak najbardziej zachęcamy. Dzisiaj natomiast porozmawiamy sobie o takim drugiej specjalizacji Michała, mianowicie o DevOps. Na początku nie może, nie paść to sakramentalne pytanie, na które już odpowiedziałeś w tamtym wspomnianym odcinku, mianowicie, czy słuchasz podcastów? Jeśli tak, to gdybyś mógł pokrótce przypomnieć, jakie to są podcasty. 

Staram się sięgać, do podcastów, które poruszają tematy, aktualnie mnie interesujące. Niejednokrotnie słucham Maćka Aniserowicza i jego gości w podcaście DevTalk, często sięgam też do podcastu Porozmawiajmy o IT, chętnie słucham też podcastu Management 3.0, który można znaleźć np. Spotify jako Happy Melly albo Happiness at Work. Zachęcam do zapoznania się z tymi materiałami, bo bardzo dużo ciekawych podcastów, zostało tam nagranych. Może jeszcze tak nowa rzecz, którą ostatnio słucham, żeby podszkolić swój angielski –  Plain English, dość ciekawy podcast, bardzo interesujące historie są opowiedziane zrozumiałym, prostym angielskim, ale też z dawką dodatkowych słówek, czy gramatyki, którą można sobie przyswoić. 

Formalności mamy już za sobą, możemy przejść do tematyki dzisiejszego podcastu. Michał, skąd się u Ciebie wzięło zainteresowanie tematyką DevOps? 

Przez te swoje 19 lat spędzone w IT, większą część spędziłem po stronie związanej z utrzymaniem, wsparciem użytkowników, ogólnie po angielsku, natomiast od 6 lat, jestem po tej drugiej stronie barykady, w tym obszarze odpowiedzialnym za rozwój systemów informatycznych. Tego słowa barykada używam celowo, bo przez lata pracy odnoszę takie wrażenie, że ten rozwój i utrzymanie, czyli ten development and operation, to takie dwa wrogie obozy, które zwykle nie za bardzo się lubią albo nawet walczą ze sobą w taki otwarty sposób. Często w organizacjach są oddzielne departamenty odpowiedzialne za rozwój i utrzymanie, mające oddzielnych managerów, dyrektorów. Tworzą się takie silosy, które w najlepszym przypadku nie najbardziej się lubią, a często prowadzą otwartą wojnę między sobą. Gdy zacząłem poznawać podejście, które jest reprezentowane przez DevOps, to zobaczyłem, że można inaczej, że można współpracować, można wspólnie starać się dostarczać wartość do tzw. biznesu. To bardzo mi się spodobało i zrozumiałem, że zamiast walczyć ze sobą, możemy walczyć z problemami, które nam się przytrafiają w naszej pracy i razem dostarczać wartość klientom organizacji. 

Często spotykam się, z tym że jest sporo nieporozumień wokoło DevOps. Jest takie podejście, że to jest taki administrator 2.0, taka nowsza wersja administratora IT i serwerów. Tymczasem DevOps, to nie jest rola w takim rozumieniu, ale metodyka, nowe podejście czy też nowa kultura dostarczania oprogramowania. Czy mógłbyś na początku, zdefiniować czym jest DevOps? 

DevOps to ruch społeczny o charakterze kulturowym i profesjonalnym, podkreślający komunikację, współpracę i integrację ludzi, procesów i technologii 

Fajnie, że zacząłeś od tych nieporozumień odnośnie DevOps, bo często można odnieść takie wrażenie, że jest np. stanowisko DevOps’a w jakiejś organizacji albo mówimy o komórkach DevOpsów, tymczasem rzeczywiście jest to coś więcej. Jest to kultura organizacyjna. Może na początku zacznijmy od tego, skąd wziął się ten termin DevOps. Otóż w roku 2009 na konferencji VeloCity, dwóch panów, John Allspaw i Paul Hammond, którzy wtedy pracowali w Flickr, mieli prezentację “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”. Wtedy po raz pierwszy, pojawił się ten zlepek, obok siebie. Na tej konferencji był również obecny Patrick Debois, został na tyle zainspirowany na tyle tą prezentacją, że następnego roku zorganizował konferencję, która nazywała się DevOpsDays. Mówi się, że od tej konferencji i nazwy DevOps, powstał cały ruch, cała metodyka, która rozwija się do dzisiejszego dnia. Niektórzy twierdzą, że DevOps, nie ma jakiejś konkretnej definicji, natomiast DevOps Institute, definiuje DevOps, jako ruch społeczny o charakterze kulturowym i profesjonalnym, podkreślający komunikację, współpracę, oraz integrację ludzi, procesów i technologii, w całym strumieniu wartości. Automatyzujący proces dostarczania oprogramowania i zmian w infrastrukturze. Ma na celu ustanowienie kultury i środowiska, w którym można budować, testować i wdrażać oprogramowanie szybciej i częściej, bez poświęcania szybkości i niezawodności usług procesowych wspieranych przez IT. Tak brzmi ta definicja, która jest podana przez DevOps Institute. Warto podkreślić, że w tej definicji jest mowa o automatyzacji i pewnym przyspieszeniu, ale podkreślona jest kwestia zbudowania pewnej kultury i odpowiedniego środowiska pracy. To w mojej opinii jest chyba najważniejszy element DevOps, który niestety dość często jest pomijany, tzn. czasami zbudowanie takiego działu powoduje, że mamy kolejny silos w organizacji, który przepycha się i walczy z innymi komórkami organizacyjnymi w IT. DevOps definiuje takie 3 drogi, które zostały po raz pierwszy opisane w książce Projekt Feniks, a potem bardzo ładnie rozwinięte w książce The DevOps Handbook. Pierwsza droga to flow, czyli przepływ pracy, strumieniów wartości i tutaj rozumiemy taki przepływ pracy od pomysłu, który pojawi się w obszarze biznesowym, poprzez jego realizację przez deweloperów, następnie poprzez wdrożenie przez operations, a następnie dostarczenie danej wartości do klienta. Chodzi o to, aby ten przepływ był jak najszybszy, jak najsprawniejszy, generujący jak najmniej kosztów i problemów. Druga droga to pętle zwrotne, czyli tzw. feedback, chodzi o to, żeby jak najczęściej i jak najszybciej uzyskiwać informację zwrotną o tym, co dzieje się w naszej strukturze IT, jaki jest odbiór rzeczy, które dostarczamy na produkcję naszych klientów, jak biznes postrzega to, co jest dostarczane itd. Chodzi o to, żeby ten feedback nie odbywał się raz na kwartał czy raz na miesiąc, tylko jeśli to możliwe to nawet każdego dnia. Jeżeli chodzi o infrastrukturę informatyczną, to żebyśmy mieli przez cały czas, na bieżąco mieli informację, w jakim stanie jest ta infrastruktura i czy działa prawidłowo. Trzecia droga polega na stworzeniu generatywnej struktury wysokiego zaufania, która pozwala na dynamiczne podejście do eksperymentowania i podejmowania ryzyka. Te trzy drogi zawierają szereg technik, metod, które można wykorzystywać, są odpowiednie narzędzia, które te drogi wspierają, ale też pewne założenia teoretyczne, które leżą u podstaw. Można powiedzieć też, że DevOps, dzieli zdolności organizacji w takie 5 obszarów tj. ciągłe dostarczanie architektura, produkty i procesy, zarządzanie szczupłe, monitorowanie oraz  kultura. Wydaje się, że właśnie w książce “Accelerate” wydanej w roku 2018, zwrócono uwagę na poprawę w tych 5 obszarach. 

To co powiedziałeś, bardzo mi się kojarzy z takim podejściem agile’owym do wdrażania programowania. Pamiętam czasy zanim agil stał się modny, wówczas dosyć mocne było rozgraniczenie pomiędzy zespołem developerskim i komórką ludzi, którzy zajmowali się utrzymaniem, administratorów. Zastanawiam się, czy według Ciebie wprowadzenie tylko takiego podejścia agile’owego do developmentu, z pominięciem tego Ops, ma sens? Czy też może powinno się do tego podchodzić w ten sposób, że jeżeli jesteśmy już zwinni to traktujemy te dwie części równolegle i w sposób zwinny staramy się dostarczać oprogramowanie w sposób ciągły, monitorować je, przedkładać ludzi ponad procesy i wszystko to, co agile wniósł nam ze sobą?

 To jest dobre pytanie, bo wydaje się, że ta cała rewolucja DevOps, o której sobie teraz rozmawiamy, która miała miejsce w okolicach roku 2009, wzięła się właśnie z tego problemu, że często organizacje w obszarze developmentu, zaczynały działać już zwinnie, coraz lepiej IT współpracowało z biznesem i to dogadywanie było na zdecydowanie lepszym poziomie, biznes był coraz bardziej zaangażowany w ten proces i wszystko było dobrze, do momentu, kiedy trzeba było pójść z tym wszystkim na produkcję. Kiedy trzeba było to wdrożyć i utrzymywać, to w organizacjach panowały dość sztywne reguły, procesy i przebicie się przez to, nie było łatwe. W swojej książce DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji, jest taki ciekawy cytat – “w dekadzie 2000-2010 ze względu na wdrożenie zasad i praktyk Agile czas potrzebny na opracowanie nowych funkcji, skrócił się do tygodni lub miesięcy”, dzisiaj powiedzielibyśmy, że nawet do dni, ale wdrożenie rozwiązań do produkcji wymagało tygodni lub miesięcy, co często miało katastrofalne skutki. To niestety, można zauważyć, bo o ile development jest w stanie dość szybko dostarczyć pewnych zmian, o tyle potem często napotyka się na taki mur w organizacji pod tytułem “kalendarz zmian” i jest informacja, że świetnie, że macie przygotowaną i przetestowaną tę zmianę, ale jej wdrożenie nastąpi dopiero w następnym kwartale, bo tak przewiduje to kalendarz wdrożeń i wtedy mamy okienko, kiedy będziemy wdrażać zmiany w systemach. Tak naprawde w dzisiejszym świecie, niestety nie można czekać tak długo na wdrażanie zmian, bo biznes wymaga tego, żeby te zmiany były wdrażane jak najszybciej i jak najsprawniej. Mawiało się kiedyś, że duże ryby łowią małe, a dzisiaj często to szybkie ryby zjadają te wolne. Pokazuje to rzeczywiście przykład wielu firm, że ta szybkość wdrażania zmian w systemach informatycznych, decyduje o przewadze konkurencyjnej, dlatego niezbędne było zmienienie nie tylko, tego obszaru dostarczania nowych funkcji, ale również obszaru utrzymania, zarządzania, monitoringu, a także bezpieczeństwa, które w wielu firmach stanowi dużą wartość i DevOps, również o tym wspomina. 

Zastanawiam się, czy w związku z tym, zwinne metodyki wdrażania są czymś wymaganym przy metodyce DevOps, czy to jest coś takiego, co musi najpierw być wdrożone albo czego świadomość musi być w firmie nastąpić, zanim wdrożenie DevOps, będzie możliwe? Czy też z Twojego doświadczenia, czy przykładów z biznesu jesteś w stanie powiedzieć, czy DevOps, również do takich projektów typu waterfall się nadaje?

Wydaje się, że pewne korzyści z wdrożenia modelu DevOps w takich tradycyjnych organizacjach też się sprawdzają, aczkolwiek trzeba zauważyć, że jeżeli mamy takie tendencyjne podejście  i na samym początku mamy duży obszar do narzucenia pewnych wymagań, następnie tworzymy architekturę do tego, potem dopiero kodujemy, potem testujemy i na koniec mamy gotowy produkt na wdrożenie, który wdrażamy i utrzymujemy, no to w tym modelu niestety tracimy coś bardzo ważnego, czyli ten  plan to market, czyli jak najszybsze dostarczenie wartości dla użytkownika końcowego. Z drugiej strony wiele praktyk, które opisuje DevOps, można zastosować również w takim tradycyjnym modelu. Stabilność i bezpieczeństwo środowiska można osiągnąć. Dlatego też, w książce, na którą już się powoływałem, stwierdzono, że metodyka DevOps, może być stosowana zarówno przy zwinnym wytwarzaniu oprogramowania, jak i w takim podejściu tradycyjnym, waterfallowym.

Dzięki wprowadzeniu kultury i technik, które dostarcza nam DevOps jesteśmy w stanie uzyskać efekt, kiedy szybciej dostarczamy zmian w oprogramowaniu

Gdybyś mógł tak podsumować, jakie korzyści z wprowadzenia kultury DevOps, mogą nastąpić w firmie. W różnych częściach firmy, czyli części developerskiej, części utrzymaniowej, części biznesowej. Co każda z tych grup, może uzyskać, jeśli wprowadzimy kulturę DevOps?

Można by stwierdzić, że dzięki wprowadzeniu i kultury i pewnych metod, technik, które dostarcza nam DevOps, jesteśmy w stanie uzyskać efekt, kiedy szybciej dostarczamy zmiany w oprogramowaniu, ale co ważne przy jednoczesnym zachowaniu, wysokiej dostępności, niezawodności oraz bezpieczeństwa. Osiąga się to dzięki, takim różnym, mniejszym krokom, czy elementom składowych tej metodyki tj. zmniejszanie porcji, które są deployowane na środowisko produkcyjne, sprawianie, że dzielimy nasze zmiany na małe części, które są później umieszczane w środowisku produkcyjnym, ale bardzo często. Dzięki temu przyspieszamy ten time to market, te zmiany są szybciej widoczne. Dzięki temu jesteśmy też w stanie poprawić jakość kodu, deploymentu software, zmniejszamy koszty produkcji pojedynczej instalacji, ale przez to też zmniejszamy ryzyko, które wiąże się zawsze ze zmianą w systemie. Dodatkowo DevOps, jest odpowiedzialny za takie zaszczepienie w całej organizacji kultury komunikacji i współpracy, to jest niezwykle ważne. Wspominaliśmy o tym, podczas naszej rozmowy i scrumie i to jest rzecz, którą DevOps bardzo mocno podkreśla. Możemy dzięki temu szybciej i w bardziej planowy sposób dostarczać pewne zmiany, których wymaga biznes.

Powiedziałeś, że DevOps, to nie tylko takie aspekty techniczne, do których jeszcze wrócimy, ale to też nacisk na współpracę, komunikację między programistami, specjalistami od eksploatacji i wszystkimi tymi, którzy pracują dla sukcesu danego projektu. Po co, według Ciebie uwypukla się tak mocno to pojęcie komunikacji i współpracy? Jakie to ma przełożenie na projekt? Czy nie może to funkcjonować w takim tradycyjnym rozumieniu, gdzie są te silosy, o których powiedzieliśmy i działy, które komunikują się wąskim kanałem, ale pracują wewnątrz? Czy ten model jakoś się nie sprawdza?

Komunikacja jest niezwykle ważna w każdym etapie dostarczania rozwiązań informatycznych. Na to też kładł nacisk manifest agilowy, który został napisany w roku 200. To też wynikało z tego, że developerzy, którzy wtedy pracowali zauważyli ogromny problem w komunikacji z biznesem i też konsekwencje, które z tego wynikają. Książka The DevOps Handbook, zawiera takie ciekawy cytat na samym początku – “wyobraź sobie świat, w którym właściciele produktu, developerzy, inżynierowie walidacji, operacji IT, bezpieczeństwa informacji, współpracują ze sobą nie tylko po to, żeby sobie nawzajem pomóc, ale też po to, by zapewnić sukces całej organizacji”. Brzmi trochę jak sen, jak takie pobożne życzenie, ale wydaje mi się, że rzeczywiście jest to możliwe do osiągnięcia i wiele organizacji pokazuje, że można w tym kierunku iść. Taka współpraca i komunikacja pomiędzy poszczególnymi zespołami i w obrębie zespołów to podstawa filozofii DevOps i druga droga, czyli ten feedback, opiera się na takiej dobrej komunikacji. Zarówno pomiędzy biznesem jaki i IT, ale także pomiędzy poszczególnymi komórkami czy zespołami, które są w obrębie IT. Nie wiem czy zauważyłeś to w organizacjach, w których pracowałeś, ale ja to widziałem, że taki podział na utrzymanie i rozwój doprowadziło do powstania silosów, z których każdy miał swoje oddzielne cele, KPI-aje. Popatrz na przykład jeżeli chodzi o dział rozwoju, to z pewnością, to na czym zależy rozwojowi to to, żeby zmiany były wprowadzane jak najszybciej, z drugiej strony dział utrzymania wie o tym dobrze, że te zmiany, powodują potem najczęściej problemy, skargi użytkowników, niedostępność systemów informatycznych itd. Prawdopodobnie zależałoby im na tym, żeby te zmiany, były wprowadzane do systemów informatycznych jak najrzadziej, aby uzyskać wysoką dostępność i niezawodność środowiska. W końcu, jak zapytamy się biznesu, dla którego to wszystko robimy, czego on chce, czy woli mieć zmiany, które są wprowadzane często i szybko na jego żądanie, czy chce mieć system niezawodny, dostępny i bezpieczny. Oczywiście, powie, że chce jednego i drugiego. Dlatego też, DevOps, łączy te dwa światy i stara się w jak najlepszy sposób, zaspokoić potrzeby biznesu. 

Współpraca i komunikacja pomiędzy poszczególnymi zespołami i w obrębie zespołów to podstawa filozofii DevOps

Gdy przeglądam oferty pracy na stanowiska specjalistów, inżynierów DevOps, to pierwsze co tam się rzuca w oczy, kiedy patrzymy na takie umiejętności twarde, to jest znajomość Chmury. Żyjemy obecnie w czasach, kiedy to jest już dosyć powszechne i coraz mniej firm posiada takie urządzenia fizyczne, gdzieś w piwnicy. Coraz więcej tych usług jest przenoszonych do Chmury. Czy według Ciebie jej znajomość, to jest taki obowiązek, jeśli chodzi o umiejętności inżyniera DevOps, taki powiedziałbym wymóg, który jest minimalny dla tej roli?

Zdecydowanie. Jak słusznie zauważyłeś dzisiaj rzeczywiście, coraz więcej organizacji przenosi swoją infrastrukturę z takich tradycyjnych serwerowni do rozwiązań chmury publicznej. Nie mówiąc już o nowych firmach, o startupach, które zwykle bazują na tego typu rozwiązaniach i jest to bardzo rozsądne podejście, bo mimo wszystko zakupienie pewnej mocy obliczeniowej w takiej chmurze publicznej, jest o wiele tańsze niż wybudowanie własnej serwerowni, zapewnienie tam wszystkich potrzebnych dostępów, zasilania, internetu itd. W związku z tym wydaje mi się, że znajomość przynajmniej dwóch z trzech, takich podstawowych rozwiązań chmurowych, czyli AWUs, Google Cloud, czy Azura, to jest must have, w tej chwili dla osób, które chcą się zajmować tym obszarem DevOps, nazwijmy ich DevOps inżynierami, myślę, że to jest dobre określenie, bo wiemy, że DevOps, to nie stanowisko, ale DevOps inżynier, to już może być określenie stanowiska. Dzięki korzystaniu z  Chmury, wiele takich rozwiązań typu Docker, Kubernetes, Continuous Integration, Continuous Delivery jest dostępnych i możemy z tych narzędzi korzystać, dlatego na pewno warto zainteresować się przynajmniej jednym lub dwoma rozwiązaniami. Myślę, że AWS w tej chwili jest takim najpopularniejszym, ale z pewnością Azure, powoli go goni, jeżeli chodzi o udostępniane funkcje i też coraz więcej klientów korzysta z tego rozwiązania, podobnie jak z Google Clouda. 

Skoro już jesteśmy przy takich twardych kompetencjach, to DevOps również kojarzy mi się z częstym wdrażaniem aplikacji, również jej rozległe monitorowanie, po to, żeby zapewnić tę wysoką dostępność. Czy mógłbyś powiedzieć, czym są takie pojęcia, o których przed chwilą wspomniałeś, czyli Continuous Integration, Continuous Delivery, Continuous Monitoring i Continuous Deployment?

To oczywiście bardzo szeroki temat i również nie jestem specjalistą, żeby się, w tym obszarze wypowiadać jakoś bardzo szeroko. Najkrócej rzecz ujmując Continuous Integration, to jest istotna praktyka developerska, która polega na tym, że kod, który jest tworzony przynajmniej raz dziennie, jest mergowany do wspólnego repozytorium kodu, podczas takiego mergowania odbywają się oczywiście automatyczne testy, zbudowanie takiej aplikacji. Dzięki temu osiągamy to, że możemy na koniec dnia, mieć wszystkie zmiany, które zostały wdrożone przez różnych developerów. Mamy to wszystko po prostu w jednym miejscu. Continuous Delivery, czyli ciągłe dostarczanie, czyli praktyka, która pozwala na uzyskanie deploymowanego stanu aplikacji. W każdym momencie tę aplikację możemy umieścić na produkcji. Trzecia rzecz, czyli Continuous Deployment,  jest to monitoryzacja tego ostatniego kroku. O ile w Continuous Delivery aplikacja może być umieszczona na produkcji, przy czym samo umieszczenie jest czynnością ręczną, o tyle w Continuous Deployment, jest także zautomatyzowana. Taka aplikacja, automatycznie trafia na środowisko produkcyjne, ma to oczywiście swoje zalety, bo dzięki temu unikamy ręcznych akceptacji i kroków, które są do wykonania, może mieć też swoje wady, ponieważ wtedy tracimy kontrolę nad tym, kiedy taka zmiana zostaje na produkcji umiejscowiona. Dlatego niektóre organizacje decydują się na takie podejście Continuous Deployment, inne poprzestają tylko na Continuous Delivery, a sam moment umieszczenia aplikacji jest już wyzwalane ręcznie przez jakąś osobę w organizacji IT, która ma do tego uprawnienia. Pytałeś jeszcze o Continuous Monitoring  i to jest też rzecz, która jest związana z drugą drogą, czyli tym feedbackiem, chodzi o to, żeby nasze systemy informatyczne, były w sposób ciągły monitorowane i żeby na bieżąco zbierać informację o tym, w jaki sposób te systemy działają. DevOps tak naprawdę zaleca, żeby monitorować i mierzyć dosłownie wszystko, co się da. Dzięki temu jesteśmy w stanie stworzyć bogatą bazę dotyczącą tego, w jaki sposób aplikacja zachowywała się na przestrzeni ostatnich tygodni, miesięcy, czy nawet lat i wychwytywać  wszelkiego rodzaju anomalie, które pokazują, że coś w tej aplikacji, nie działa w sposób właściwy. Jeżeli mamy wiedzę o tym, że ilość klientów w naszej aplikacji jest duża i każdego dnia między godziną 8 a 10, a potem między 16 a 18 i któregoś dnia widzimy, że to zachowanie użytkowników jest inne niż zwykle, to być może coś nie tak jest z aplikacją. Być może jakiś jej moduł jest niedostępny albo proces zakupu nie może być dokończony. Jest to sygnał do tego, żeby sprawdzić, czy wszystko z tym systemem jest w porządku.

To, co łączy te wszystkie pojęcia, to jest ten pierwszy człon nazwy, czyli Continuous, czyli ciągłość. Żeby taką ciągłość zapewnić, musimy myśleć oczywiście o jakości i osiąga się to w różny sposób, np. przez jakieś automatyczne testy regresji, albo tak jak to robi Netflix, symulowanie awarii na produkcji. Tutaj wchodzimy w obszar QA. Mam wobec tego pytanie, czy podejście DevOps,  to jest takie multidyscyplinarne działanie związane z dostarczeniem oprogramowania? Poruszyliśmy kilka różnych ról, które mogą być wpisane w taką filozofię DevOps, QA, utrzymanie stabilności strony. To, co mi przychodzi na myśl, to to, że poruszamy wiele różnych aspektów, wiele różnych dyscyplin i zastanawiam się, czy ten DevOps to nie jest coś szerszego, czy to nie jest taka multidyscyplinarna działalność dotycząca tego, jak dostarczyć oprogramowanie. Co Ty o tym myślisz?

Zdecydowanie tak. Nawet ten cytat, który pozwoliłem sobie tutaj przytoczyć, o współpracy różnych osób czy działów, zwraca uwagę na takie role jak właściciel produktu, developer, ale też inżynierowie walidacji, czyli ten obszar QA, potem operacje IT i bezpieczeństwo. Jak najbardziej DevOps, w szeroki sposób podchodzi do kwestii, wytwarzania oprogramowania, jego późniejszego utrzymania i wszystkich elementów, które są z tym związane. Bardzo istotną rolę odgrywają też testerzy. Tutaj jedna ważna uwaga, jeśli mówimy o automatyzacji, o Continuous Integration, Continuous Delivery, to mamy świadomość, że coraz większy nacisk, będzie kładziony na automatyzację. Oczywiście są pewne obszary aplikacji, które prawdopodobnie zawsze, będą musiały być przetestowane w sposób manualny, ręczny. Takich testów nie unikniemy, aczkolwiek trend jest taki, żeby tych testów automatycznych było jak najwięcej, żeby one pokrywały jak największą część aplikacji. 

Wiele razy powiedziałeś o automatyzacji, to bardzo ważny aspekt DevOps. Co chcemy automatyzować i dlaczego tak nam zależy na tym?

Automatyzować chcemy wszystko. Im więcej rzeczy zautomatyzujemy, tym mniejsze jest prawdopodobieństwo popełnienia błędu. Prawda jest taka, że większość problemów, które były w środowiskach informatycznych wyniknęły z tego, że ktoś popełnił jakiś ludzi błąd, np. jest jakaś ilość skryptów, które trzeba uruchomić w odpowiedniej kolejności i ktoś albo pomylił tę kolejność, albo zapomniał, któregoś skryptu. Jeżeli ten obszar zautomatyzujemy, to znaczy napiszemy taki program, który wykona nam te skrypty w poprawnej kolejności, to wtedy unikamy tych błędów ludzkich, które mogą wystąpić. Oczywiście automatyzację, trzeba wprowadzać z głową, w każdej organizacji jest takie powiedzenie, że jeżeli mamy w jakiejś części bałagan i zaczniemy tam wprowadzać automatyzację, to efekcie otrzymamy tylko automatyczny bałagan i nic więcej. Na początku, na pewno trzeba pewne obszary uporządkować, przejrzeć, postarać się wyszczuplić pewne procesy, a dopiero potem wprowadzać automatyzację, a nie na odwrót. Natomiast rzeczywiście, dzięki takiej dobrej automatyzacji możemy uzyskać na pewno przyspieszenie pewnych działań, a po drugie większą niezawodność tych wszystkich działań. Jeżeli mamy naprawdę dobrze napisany skrypt, który podnosi nam całość środowiska i jeśli nastąpi jakaś awaria, to odtworzenie tych środowisk zajmuje nam bardziej minuty i godziny, niż dni i tygodnie, jak to było w poprzednich czasach, kiedy trzeba było ręcznie te systemy odtwarzać, przenosić itd. 

Jeśli ktoś chciałby zostać tym DevOps inżynierem, to jakie umiejętności musi posiąść, bardziej myślę o takich umiejętnościach twardych, żeby móc szukać pracy jako DevOps inżynier.

Wspominaliśmy już o tym, że znajomość Chmury, to jest takie must have, takiej osoby, naprawdę to są bardzo poszukiwane umiejętności, jak działania w AWS, Azure albo Google Cloud. Oczywiście, mamy na uwadze to, że to są bardzo rozbudowane systemy, myślę, że mało kto jest zdolny być specjalistą, we wszystkich funkcjach, które udostępnia np. AWS, bo są ich setki. Zauważa się, że następuje w tej chwili pewna specjalizacja w wąskich dziedzinach, jeśli chodzi o rzeczy, które są np. na AWSie, do zrobienia. Natomiast z pewnością, taka osoba, która chciałaby się tym zajmować, powinna posiadać jakąś ogólną wiedzę o środowiskach chmury publicznej i głębszą w tych obszarach, które dotyczą zarządzania samą infrastrukturą IT. Bardzo przydatna jest też znajomość wszelkich narzędzi typu Continuous Integration, Continuous Delivery, Continuous Deployment oraz narzędzi do monitorowania. Jest tego całkiem sporo i też wydaje się, że na dzień dzisiejszy trudno być specjalistą, we wszystkich tych narzędziach, ale trzeba po prostu zobaczyć, które z nich są aktualnie najczęściej pożądane przez pracodawców, najczęściej wykorzystywane przez kolegów po fachu. Być może dobrym kierunkiem jest np. nauczenie się przynajmniej dwóch jakichś narzędzi, z pewnością znajomość wszelkich repozytoriów opartych o Gita. Wszelkie rzeczy związane z kontenerami, narzędzia, które umożliwiają nam testowanie i sprawdzanie, czy te środowiska są dostępne, czy został spełniony losowy sposób zabijania podów i patrzymy, czy są one w stanie automatycznie podnieść się i wrócić do życia. Upewniamy się, czy cała struktura, na której stoi nasza organizacja, rzeczywiście jest dostępna dla użytkowników końcowych, bo to jest najważniejsze. 

Na początku, kiedy Cię przedstawiałem, wspomniałem, że uczestniczyłeś w kilku dużych transformacjach IT. Jak się wdraża taką kulturę DevOps, w firmie? Czy to jest też, coś, w czym brałeś udział? Zastanawiam się, czy to się robi w etapach, czy to po prostu jest proces, który musi nastąpić z przysłowiowego wtorku na środę? Czy kiedykolwiek można uznać, że jesteśmy już za tym procesem i mamy go z głowy? 

Z przykrością muszę stwierdzić, że te transformacje, w których brałem udział, akurat nie przybliżały organizacji do tego modelu DevOps. Natomiast w mojej ocenie, adaptowanie w organizacji kultury DevOps, ma proces ciągły. To na pewno nie jest coś, co ma nastąpić z wtorku na środę. To jest proces, który będzie zajmował miesiące i lata, a nie dni i tygodnie. Trudno też mówić, kiedy nastąpi taki konkretny moment zakończenia tej transformacji. Na pewno można w pewnym momencie uznać, że udaje nam się zaimplementować wiele pozytywnych zmian, które stwierdzają, że możemy powiedzieć, że jesteśmy organizacją działającą zgodnie z praktykami DevOps, tym niemniej, będzie na pewno dużo różnych obszarów, w których można coś usprawnić, polepszyć. Sama technologia IT, cały czas idzie do przodu, więc na pewno pojawią się nowe narzędzia, nowe rozwiązania, które trzeba będzie w naszej organizacji wykorzystać i zaimplementować. Ta droga nigdy się nie skończy, zawsze będzie mogła być kontynuowana. Powiedzieliśmy też, że DevOps, to tak naprawdę pewna kultura organizacyjna i tutaj też jest na pewno wiele do zrobienia. Zarówno w transformowaniu myślenia pracowników, jak i w szkoleniu tych pracowników, którzy przychodzą, którzy są nowi, oni też muszą tę kulturę poznać, muszą się z nią identyfikować i zgodnie z nią działać. Podsumowując, jest to na pewno proces, który trwa długie tygodnie, miesiące, może nawet lata, gdzie stopniowo poszczególne obszary należy implementować, patrzyć co możemy zrobić, żeby je usprawnić. 

Można mieć takie wrażenie, że skoro to jest proces ciągły, który tak naprawdę nigdy się nie skończy i zajmuje całkiem sporo czasu, jak również to, że sporo osób musi być w niego zaangażowanych, to DevOps, jako kultura, jest przeznaczony do dużych firm. Czy jest według Ciebie, jakiś rodzaj branży, w której DevOps się sprawdzi, a w których ta kultura nie ma za bardzo racji buty?

W mojej ocenie DevOps dostarcza pewien zbiór zachowań, które mogą być wykorzystywane w każdej firmie, która posiada systemy informatyczne, niezależnie od branży i wielkości. W książce The DevOps Handbook powiedziano, że tak naprawdę w dzisiejszym świecie, każda firma jest firmą informatyczną. Nawet bank, to firma informatyczna, tylko posiadająca odpowiednią licencję bankową. To jest prawda, bo dzisiaj trudno wyobrazić sobie, sprawnie działającą firmę, bez dobrych systemów informatycznych. Każda firma, która takie systemy posiada i rozwija, może odnieść korzyści z metodyki DevOps i z zasad, które ta metodyka proponuje. Oczywiście, jeśli mamy firmy informatyczne, gdzie systemy zmieniają się stosunkowo rzadko lub jest ich niewiele, są to tzw. systemy półkowe, to pewnie nie za bardzo jest miejsce na stosowanie praktyk DevOps w obszarze rozwijania tych systemów, ale być może kwestia bezpieczeństwa, czy utrzymania tych systemów, będzie bardzo pomocna. Z drugiej strony, jeśli mówimy o startupach technologicznych, to wydaje się, że takie podejście DevOps, to jest oczywiście must have, ze względu na to, że trzeba bardzo szybko wprowadzać wiele zmian, w bardzo krótkim czasie. Tak jak wspomnieliśmy, często przewagą konkurencyjną tych firm, jest to, że są w stanie szybko wprowadzać zmiany, szybko reagować na potrzeby klientów, bo mamy świadomość, że jeśli my tego nie zrobimy, to zrobi to nasza konkurencja, która jest w stanie nam bardzo szybko podkupić klientów. Na pewno też w dużych firmach, które mają swoje procesy, to wdrożenie takiej metodyki DevOps, takiej metodyki myślenia będzie zadaniem bardziej skomplikowanym i długotrwałym, niż w mniejszych organizacjach, które są bardziej zwinne i są w stanie szybciej zaimplementować takie zmiany w codziennej pracy. 

Nawet bank to firma informatyczna, tylko posiadająca odpowiednią licencję bankową

Skupiliśmy się trochę na metodyce i też poruszyliśmy jakieś twarde umiejętności, które można wykorzystać w takim podejściu DevOpsowym, ale to jeszcze nie wszystko, bo skuteczne wdrożenie DevOps często wymaga zmiany świadomości w firmie, sposobu zarządzania zespołami a może i całą firmą. Jakie masz obserwacje w tym temacie, czy to może sięgać tak szeroko?

Jak najbardziej, tak jak już wcześniej powiedzieliśmy DevOps, to w dużej mierze pewna filozofia, kultura pracy. Oczywiście procesy i narzędzia są ważne, ale DevOps kładzie nacisk, również na wartości. Można powiedzieć, że wymienia takich 5 głównych wartości, czyli kultura, automatyzacja, lin – czyli wyszczuplanie procesów, opomiarowanie i dzielenie się wiedzą, jak i doświadczeniami, jak i informacją zwrotną, o tym, jak działają nasze procesy. Ten obszar jest rzeczywiście, bardzo mocno podkreślany i wydaje się, że bez wprowadzenia odpowiedniej kultury w organizację, zaszczepianie pewnych procesów, czy technik na niewiele się zda. Możemy oczywiście osiągnąć poprawy w jakichś obszarach, ale na pewno efekt, nie będzie tak znakomity, jak wtedy gdybyśmy połączyli wszystkie narzędzia, techniki z odpowiednią kulturą organizacyjną. Tutaj chyba bardzo istotną rzeczą, na którą kładzie nacisk DevOps, jest taka kultura No–Blame, czyli nawet jeżeli coś się zepsuje, zrobimy coś niewłaściwego albo jeśli mamy jakiś poważny problem, to skupiamy się nie na szukaniu winnych, ale na tym, żeby jak najszybciej naprawić problem, a później wspólnie wyciągnąć z tego wnioski i zrobić jakieś ulepszenia, które spowodują, że takich błędów nie popełnimy w przyszłości. Znowu ciekawy cytat z książki, na którą już się powoływałem, tam jeden z managerów pewnej organizacji powiedział, o tym, że jeden z jego inżynierów w dziale IT, doprowadził do dość poważnej awarii systemów informatycznych i przydarzyło mu się to drugi raz. Potem powiedział tak: “oczywiście, nie zwolniliśmy tego pracownika, nikt inny nie ma tak dużej wiedzy na temat tego problemu, jak ten człowiek”. To jest prawda, jak już ktoś popełnił błąd pierwszy, czy drugi raz, to jest szansa, że nauczył się czegoś o tym i więcej go nie popełni. To jest właśnie takie stworzenie kultury, nie wzajemnego obwiniania się, ale szukania rozwiązań i wyciągania wniosków, z tego, co zostało źle zrobione. Ta filozofia jest tutaj bardzo istotna. Jak zwykle, wydaje się, że jest to obszar, który często jest pomijany. Kiedy mówimy DevOps, to często myślimy jakie narzędzia kupić, jakie procesy wprowadzić, kogo, z czego przeszkolić itd., a trochę mniej myślimy o tym, jakie wartości należy propagować w organizacji.

Myślę, że na naszym rodzimym rynku sporo mamy takich małych, czy średnich firm z sektora IT. Co byś radził takim firmom, które nie posiadają dużych budżetów na szkolenia, kupno kosztownych narzędzi. Co byś im polecił, jeśli chcą wprowadzić kulturę DevOps, z jakich prostych kroków mogą skorzystać?

Na pewno odradziłbym zaczynanie transformacji od zatrudniania specjalistów i kupowania jakichś konkretnych narzędzi, bo jeśli od tego zaczniemy, może się okazać, że będą to pieniądze wyrzucone w błoto. Zachęciłbym do tego, żeby po pierwsze sięgnąć po książkę Projekt Feniks i ją sobie przeczytać. Kiedy ja czytałem tę książkę, to naprawdę miałem wrażenie, że autorzy tej książki pracowali w firmie, w której ja przepracowałem 14 lat i doskonale znają problemy, które w tego typu organizacjach występują. To jest naprawdę świetna lektura na sam początek, żeby w ogóle zrozumieć, czym jest kultura DevOps, czym jest ta metodyka. Drugą polecaną pozycją jest książka The DevOps Handbook, w tej chwili pojawia się na rynku jeszcze jedna książka, The Unicorn Project, którą prawdopodobnie warto będzie przeczytać. Na początku zastanowiłbym się, co z tych praktyk i 3 dróg, które są opisane w tych dwóch publikacjach, ja mógłbym zaimplikować w swojej organizacji. Czasami można pewne rzeczy, robić bezkosztowo. Na pewno istotne jest to, żeby wybrać odpowiedni strumień wartości, od którego możemy zacząć. Zwykle takich strumieni wartości w organizacji jest sporo, od biznesu do klienta, poprzez dział developmentu i utrzymania, ale nie ma sensu zabierać się za wszystkie, lepiej wybrać jeden, czy dwa, które są dla nas najistotniejsze. Po drugie ciekawa rzecz, która też została opisana prawem Conwaya, że organizacje, które projektują systemy informatyczne, tworzą wzorce, które są kopiami struktur komunikacyjnych w tej organizacji. Okazuje się, że im większa organizacja, tym ma mniejszą elastyczność, opisywane zjawisko jest wyraźniejsze. To pokazuje, że trzeba by czasami pomyśleć o naszej strukturze organizacyjnej, w jaki sposób ta praca przepływa pomiędzy poszczególnymi komórkami, zastanowić się, czy ten przepływ jest właściwy, optymalny, czy nie można by było dokonać pewnych zmian w strukturze organizacyjnej, które tę pracę usprawnią, a za tym, też pójdzie struktura samych systemów informatycznych, które są budowane. Sposób, w jaki organizujemy nasze zespoły, ma potężny wpływ na oprogramowanie, które jest wytwarzane, a także na tworzone struktury architektoniczne i osiągane rezultaty produkcji. Aby uzyskać szybkie przepływ pracy oddziału, zapewnić wysoką jakość, dobre wyniki dla klientów, to trzeba tak zagospodarować zespoły i pracę w tych zespołach, żeby to prawo Convey’a działało na korzyść organizacji. Przy złej organizacji niestety to prawo, uniemożliwia zespołom bezpieczną i niezależną pracę. Tutaj ciekawa rada, zamiast tego, żeby zespoły na siebie nawzajem czekały i czasami nawet niewielkie zmiany, mogły powodować globalne konsekwencje, to warto, aby one ze sobą ściśle pracowały i były dobrze powiązane. 

Czyli całkiem sporo, tak jak powiedziałeś, bezkosztowych rzeczy można zrobić, może nie na tu i teraz, bo to wszystko wymaga trochę czasu, ale nie trzeba inwestować grubych milionów i tracić czasu na szkolenia, czy materiały, które i tak mogą się nie przydać. Myślę, że to daje sporą nadzieję. 

Wspominaliśmy o tych rzeczach, typu Continuous Integration, Continuous Delivery i Continuous Deployment, to z pewnością warto zacząć od tego, pierwszego kroku, czyli od Continuous Integration, czyli zadbać o to, żeby kod tworzony, przez programistów każdego dnia, był mergowany do wspólnego repozytorium, pomyśleć o tym, aby aplikacje były pokryte jak największą ilością testów jednostkowych, a następnie iść krok dalej, czyli wdrożyć Continuous Deployment, a jeszcze wcześniej Continuous Delivery. 

Jak obecnie wygląda rynek pracy dla specjalistów od DevOps, bo mam wrażenie, że tych ofert jest coraz więcej. Jak je przeglądam, to mam wrażenie, że stawki dorównują wręcz stawkom dla programistów. Wydaje się, że zapotrzebowanie jest zwyżkowe i całkiem duże, czy to jest coś, co też obserwujesz?

Jak najbardziej i wydaje mi się, że to będzie trend, który nie będzie się zmieniał tzn. zapotrzebowanie na specjalistów z tego obszaru, będzie rosło. Wynika to z tego, że większość firm przenosi swoją infrastrukturę, z takich tradycyjnych serwerowni do rozwiązań chmurowych i przez cały czas, brakuje dobrych specjalistów w tym obszarze. Wchodzą nowe technologie, które też są jeszcze słabo rozpoznane i nie ma wielu osób, które by się na tym dobrze znały. Dzisiaj znaleźć takiego specjalistę od Kubernetesa, który w dodatku dobrze zna AWS’a czy Google Cloud’a, nie jest rzeczą prostą. Stąd też pensje proponowane takim osobom, są stosunkowo wysokie. Zapotrzebowanie na osoby, które znają się na rozwiązaniach chmury publicznej, to są te technologie, które na pewno będą cieszyły się dużym powodzeniem i z pewnością osoby, które mają te kompetencje, na brak pracy w najbliższym czasie narzekać nie będą. 

Wobec tego, czego możemy się spodziewać w przyszłości? W jakim kierunku, według Ciebie ten ruch DevOps będzie się rozwijał? Nie obawiasz się, że takie podejście infrastructure as a code gdzie wręcz developer, może napisać kod za pomocą którego ta infrastruktura, może zostać zbudowana, czy to nie spowoduje, że ta część kompetencji związanych z Chmurą będzie miała coraz mniejsze znaczenie i to deweloperzy w jakiś sposób przejmą tworzenie infrastruktury w Chmurze?

Trzeba zacząć od tego, czy to źle? Czy to właśnie, nie jest ten kierunek, który jest dobry, żeby deweloperzy też mieli kontrolę nie tylko nad kodem, który piszą, ale również nad infrastrukturą, na której ten kod działa. Jednak bardziej wydaje mi się, że jest to dostarczenie pewnych narzędzi. Nadal jednak będą istniały pewne specjalizacje, nadal będą osoby, które będą specjalizowały się w dostarczaniu infrastruktury, a dzięki temu dostarczamy deweloperom, narzędzia do tego, żeby postawić sobie środowisko produkcyjne, na potrzeby testów albo integracji i zrobić to za pomocą autentycznych skryptów, w ciągu kilkunastu minut, nie angażując w to dodatkowych osób. Moim zdaniem, jest to raczej coś, z czego deweloperzy powinni się cieszyć, że możemy nad tym wszystkim panować z poziomu konsoli, a nie musimy za każdym razem prosić administratorów i specjalistów, żeby coś nam skonfigurowali, czy postawili jakąś wirtualną maszynę. Na pewno ten kierunek, o którym wspomniałeś, to jest przyszłość DevOps, dalsza automatyzacja jak największej ilości procesów i nowe możliwości, które nam to daje. Przyspieszenie tego deploymentu i być może, też wprowadzanie w poszczególnych organizacjach kultury częstych release oprogramowania. Są dzisiaj organizacje, które mają takich deploymentów nawet kilkaset dziennie, a ciągle jest dużo takich organizacji, które mają jakieś okienka, na wprowadzanie zmian w programach informatycznych, które są proponowane raz na kwartał, raz na miesiąc, albo nawet raz na tydzień, co i tak jest ogromną przepaścią w stosunku do tych organizacji, które są zwinne i działają zgodnie z duchem DevOps. Wydaje mi się, że tutaj dużo ciekawych kierunków rozwoju i na pewno warto to śledzić i starać się implementować te zasady, kierunki w naszych organizacjach. 

Moją intencją do tego podcastu, było raczej pokazanie krajobrazu DevOps, pokazanie jak szeroki jest to krajobraz i ile różnych tematów występuje. Natomiast, jakie materiały doradziłbyś komuś, kto chciałby swoją wiedzę poszerzyć, doczytać, dowiedzieć się czegoś więcej na temat kultury DevOps. Gdzie może sięgnąć?

Kilka z tych książek już tutaj wspomniałem, więc podsumowując, na pewno w pierwszej kolejności zachęcałbym do tego, żeby sięgnąć po książkę Projekt Feniks, jest ona przetłumaczona na język polski. Drugą książką, którą warto poczytać, może jest ona bardziej techniczna, ale to DevOps. Światowej klasy zwinność, niezawodność i bezpieczeństwo w Twojej organizacji. To jest książka napisana prawie przez tych samych autorów, co Projekt Feniks. W tej chwili będzie opublikowana książka The Unicorn Project, wiem, że część tej książki można już pobrać w postaci audiobooka i sobie to odsłuchać. Pojawiła się też taka publikacja jak [59:33], która podsumowuje kilka lat badań nad wprowadzaniem kultury DevOps, w różnych organizacjach, bardzo ciekawe wnioski i metryki można sobie tam przejrzeć. Jeżeli lubimy też słuchać, oglądać materiały to z pewnością znajdziemy mnóstwo tego typu materiałów w internecie. W komentarzu do tego odcinka też zawarliśmy link do DevChat.tv i tam mamy takie odcinki jak Adventures in DevOps, które można sobie odsłuchać i też ciekawych rzeczy się z tego dowiedzieć. Natomiast tak jak powiedziałem książka Projekt Feniks, będzie na pewno świetnym wprowadzeniem, szczególnie że nie jest to książka techniczna, ale fabularyzowana, gdzie kierownik pewnego działu IT, w pewnej dużej firmie z dnia na dzień staje się zastępcą wiceprezesa do spraw informatyki i ma przed sobą niezwykle trudne zadanie, wyprowadzenia infrastruktury IT, na prostą i doprowadzenia projektu Feniks do szczęśliwego końca. Kolejna drogi, które przebywa, są tam fajnie opisane i też można się z tego wiele ciekawych rzeczy nauczyć. 

Brzmi ciekawie. Ja Ci Michał bardzo dziękuję, po pierwsze za to, że ponownie zagościłeś w podcaście, po drugie za to wprowadzenie do kultury DevOps. Przypomnij proszę, jeszcze raz, gdzie Cię można znaleźć w internecie. 

Można mnie znaleźć na LinkedInie albo też na blogu www.itea.org.pl, na którym staram się publikować krótkie artykuły, na temat zarządzania szeroko rozumianego IT. 

Oczywiście, wszystkie linki dodam do opisu tego odcinka. Michał, jeszcze raz bardzo dziękuję i do usłyszenia. 

Dzięki wielkie, cześć.

To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Podejście DevOps zdobywa obecnie coraz większe uznanie. Mam nadzieję, że teraz lepiej rozumiesz filozofię tworzenia i utrzymanie produktu informatycznego. Osobiście zachęcam do zainteresowania się tym tematem, bo to jest kierunek, w którym IT z pewnością będzie podążało. To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Pomimo że podcast, to bardzo jednokierunkowe medium, bo ja mówię, a Ty słuchasz, to jednak przez takie wsparcie dasz mi znać, że jesteś i że słuchasz. 

Dziękuję. 

Jeśli masz jakieś pytania, to pisz śmiało na krzysztof@porozmawiajmyoit.pl. 

Miło mi było gościć w Twoich uszach. Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o DevOps. Zapraszam do kolejnego odcinka już za 2 tygodnie. Cześć.