W jakim kierunku zmierza DevOps?

Transkrypcja

Dziś moim gościem jest Wojciech Lepczyński. Wojtek opowie nam o kierunku, w jakim zmierza DevOps. Wojtku, dziękuję, że przyjąłeś moje zaproszenie na rozmowę.

Witam serdecznie wszystkich słuchaczy i Ciebie, Mateuszu. To ja dziękuję za kolejne zaproszenie.

To już chyba, jak dobrze liczę, trzeci raz, więc miałeś okazję się przedstawiać. Ale może zróbmy jak zwykle, powiedz nam kilka słów o sobie i co łączy Cię z branżą IT, żeby ci, którzy nie słyszeli, dowiedzieli się czegoś o Tobie, a ci, co już nas słuchali wcześniej sobie przypomną.

Oczywiście, jeszcze raz bardzo serdecznie witam wszystkich słuchaczy. Ja nazywam się Wojciech Lepczyński. Lubię mówić, że jestem DevOpsem. Aktualnie pracuję jako Chief Software Engineer w GFT, gdzie wspólnie z zespołem tworzymy nowoczesny cyfrowy bank w chmurze dla klienta z Azji. To bank bez fizycznych biur i budynków, w 100% funkcjonujący w przestrzeni cyfrowej. Projekt ten rozwijamy już od jakiegoś czasu, a teraz skupiamy się na jego udoskonalaniu: dodawaniu nowych funkcji, optymalizacji kosztów, migracji do nowego regionu i tak dalej. Mogę powiedzieć, że jest dużo ciekawych zadań.

W IT pracuję już ponad 12 lat. Byłem adminem, trochę architektem, konsultantem chmurowym. Teraz głównie jestem DevOpsem. I jak na razie mi się to podoba. Najbardziej lubię pracować z chmurą, z którą mam bliższą znajomość od jakichś 7 lat. Ogólnie uwielbiam dzielić się swoją wiedzą i doświadczeniem, dlatego od kilku lat prowadzę własny blog oraz kanał na YouTubie, gdzie publikuję treści związane z chmurą i z DevOpsem. Jeżeli interesują Cię te tematy, serdecznie zapraszam do odwiedzenia mojego kanału. Mam nadzieję, że znajdziesz tam mnóstwo ciekawych materiałów. Fajnie być tutaj z Wami i mieć okazję podzielić się swoją pasją oraz doświadczeniami. Cieszę się na tę rozmowę i mam nadzieję, że będzie inspirująca dla wszystkich słuchaczy.

Na pewno będzie inspirująca i ciekawa. Muszę przyznać, że dzisiaj będzie dużo trudnych słów i skrótów, ale postaramy się wszystko rozwinąć i wyjaśnić. Chcemy pokazać, w którą stronę zmierza DevOps, jakie są nowe ścieżki, co się z czego wywodzi i w którą stronę warto iść. Zróbmy wprowadzenie i powiedzmy, czym jest DevOps i z jakimi wyzwaniami spotyka się na co dzień.

Zacznę od oklepanej regułki, że DevOps to zbiór praktyk, narzędzi i filozofia, która ma na celu automatyzację i integrację procesów między zespołami developerskimi a operacyjnymi, co prowadzi oczywiście do szybszego dostarczania oprogramowania oraz jego wyższej jakości. Jeśli ktoś jest zainteresowany tym tematem, to w jednym z wcześniejszych podcastów mówiliśmy o nim więcej. Mateusz na pewno może podlinkować.

Ja natomiast mogę krótko przypomnieć, że zazwyczaj, mówiąc DevOps, mamy na myśli osobę pracującą na tym stanowisku. Muszę przyznać, że taka osoba często spotyka się z takimi wyzwaniami jak automatyzacja procesów, ciągła integracja, ciągłe dostarczanie, czyli tak zwane w skrócie CI/CD. Trzeba pamiętać oczywiście o monitorowaniu systemów oraz analizie logów. Ja mam background jako administrator, więc mam dużo zadań związanych z architekturą w chmurze i ogólnie tworzeniem infrastruktury jako kodu.

DevOps generalnie musi współpracować z różnymi zespołami i ustalać różne kwestie między działami, co jest kluczowe, ponieważ działa na styku development i operations. Ta współpraca, komunikacja między zespołami, jest niezbędna w codziennej pracy. Byłem na projektach, gdzie miałem spory kontakt z klientami i innymi zespołami, oraz na takich, gdzie ten kontakt był raczej znikomy, także wygląda to różnie.

Wywołałeś temat chmury, to może zaczniemy od tego, kim jest Cloud Engineer i czy to twór wywodzący się z DevOps, czy może wchodzący w jego skład?

Cloud Engineer, jak sama nazwa wskazuje, ma coś wspólnego z chmurą. Zazwyczaj jest to specjalista odpowiedzialny za projektowanie, wdrażanie i zarządzanie infrastrukturą chmurową. W uproszczeniu można powiedzieć, że Cloud Engineer to taki specjalista, który zamiast zwykłej fizycznej serwerowni wybrał wirtualną serwerownię, czyli chmurę. Rola ta może być powiązana z projektami DevOps, ale nie jest to twór wywodzący się bezpośrednio z DevOps. Cloud Engineer koncentruje się na zarządzaniu zasobami w chmurze, podczas gdy DevOps obejmuje, moim zdaniem, szerszy zakres automatyzacji i integracji procesów. Popraw mnie, jeśli się mylę.

Myślę, że moja wizja tej profesji jest jak najbardziej zgodna z tym, co tutaj powiedziałeś. 

Cloud Engineer może być częścią zespołu DevOps. Taka współpraca jest jak najbardziej możliwa, zwłaszcza że teraz mamy bardzo dużo projektów, które są praktycznie w 100% w chmurze.

Mamy już informację czym jest Cloud Engineer, to może powiedzmy, czym jest cyberbezpieczeństwo. Myślę, że z roku na rok jest to coraz ważniejszy element w branży IT. Czy DevOps odpowiada za ten sektor, czy może jest to kompetencja innej osoby, którą możemy znać pod nazwą DevSecOps?

Tutaj dużo zależy od organizacji. Według mnie wszystkie osoby zaangażowane w procesy DevOps powinny być świadome zagrożeń i konsekwencji swoich działań. W niektórych firmach zadania DevOps i DevSecOps mogą się pokrywać. DevSecOps, jak sama nazwa wskazuje, integruje dodatkowo obszar bezpieczeństwa, co oznacza, że oprócz standardowych praktyk DevOps skupia się także na aspektach bezpieczeństwa. W praktyce trudno sobie wyobrazić DevOpsa, który nie ma pojęcia o cyberbezpieczeństwie. Dlatego według mnie DevOpsi muszą również posiadać wiedzę i umiejętności związane z bezpieczeństwem systemów, żeby tworzyć je w bezpieczny sposób.

Według mnie DevSecOps skupia się właśnie bardziej na bezpieczeństwie, na tworzeniu ról, przydzielaniu uprawnień, na stawianiu barier i ograniczeń. Często zajmuje się na przykład przeglądaniem logów bezpieczeństwa, tworzeniem ról IAM. Co to IAM? Identity and Access Management, zarządzanie tożsamością i dostępem. Umożliwia identyfikację i kontrolę dostępu, co przekłada się w znacznym stopniu na bezpieczeństwo. Co Ty myślisz na ten temat?

Myślę, że ten DevOps jest tak ogromną kobyłą, że naprawdę ciężko tym zarządzać jako jednoosobowy zespół. Albo nawet w kilka osób może to być bardzo ciężkie. Myślisz, że to będzie jeszcze bardziej się rozchodzić i zwiększą się te specjalizacje, żeby każdy mógł odpowiadać za jedną część tortu?

Po części tak jest. Ja zauważyłem, że coraz częściej developer musi też posiadać pewną znajomość chmury i narzędzi do automatyzacji, czyli to na pewno rośnie. Role często się pokrywają. Generalnie rozwój jest nieunikniony i naturalne jest to, że role ewoluują i się zmieniają. Ja mam wrażenie, że firmy są coraz bardziej świadome ryzyka. Na przykład jak tworzy się coś w chmurze, to zazwyczaj zaczyna się od przyznawania najmniejszych możliwych uprawnień. Owszem, jest to czasem bardzo frustrujące, gdy musisz prosić o każde dodatkowe uprawnienie, zwłaszcza gdy tworzysz nowe role, nie do końca wiesz, co będzie potrzebne. Jednak w pełni popieram takie podejście. Jakie jest Twoje zdanie?

Jako developer nie jestem z tego zbyt zadowolony, bo zawsze jestem tą osobą, której coś nie chce działać i muszę prosić o te dodatkowe uprawnienia. Już nie opowiadając o historii zaszłości na temat chmodów i tak dalej, ale wydaje mi się, że też to podejście, o którym wspomniałeś, to trochę jest powód tego, że Ty jako administrator zawsze w ten sposób pewnie postępowałeś, więc to jest taka dla Ciebie naturalna ścieżka.

Tak. Generalnie jak tworzy się oprogramowanie dla banku, to bezpieczeństwo jest kluczowe i każda drobna zmiana w uprawnieniach musi, ale to musi być uzasadniona. Potrzebujesz do czegoś dostęp albo tworzysz jakąś usługę, która potrzebuje dostęp, to musisz jasno określić, jakie uprawnienia są Ci potrzebne, a potem zespół od security to sprawdza i zatwierdza albo prosi Cię o wprowadzenie jakichś poprawek. Najgorzej jest, gdy o czymś zapomniałeś i musisz ponownie przechodzić przez całą procedurę bo chcesz rozszerzyć uprawnienia.

Czyli rozumiem, że minął tydzień, chcesz coś zrobić i potem znowu coś nie działa i czekasz kolejny tydzień?

To zależy. Jednak nie jest tak, że raz nadane uprawnienia zostają Tobie na zawsze, bo często przeprowadza się audyt bezpieczeństwa i wtedy może wyjść na jaw, że masz więcej uprawnień niż powinieneś mieć i są one zmniejszane. Często jest tak, że potrzebujesz określonych uprawnień tylko na przykład na pewien czas. Potrzebujesz wyższych uprawnień, aby przeprowadzić aktualizację albo audyt jakichś usług. I wtedy prosisz o przyznanie uprawnień na określony czas, na przykład na 24 godziny albo na 5 dni, a po tym czasie są Ci one zabierane. I to jest całkowicie OK, bo patrząc od strony bezpieczeństwa, jeśli normalnie masz tylko uprawnienia do odczytu i ktoś przejął Twoje konto, to tak naprawdę nic nie zrobi, nic nie zepsuje. A gdybyś miał uprawnienia admina, to mogłoby już nie być tak fajnie.

Albo wyobraź sobie, że ktoś ma wyczyścić stare dane ręcznie, bo nie da się tego zrobić automatycznie. Odpala skrypt i okazuje się, że uruchomił go na złym koncie. Teraz, jeśli nie miał uprawnień tam, gdzie nie powinien mieć, to nic się nie stało. Ale jeśli miał uprawnienia wszędzie, to mogą dziać się cuda. Wszyscy jesteśmy tylko ludźmi, bywamy zmęczeni, czasem nieuważni i różnie to może być. Dlatego tak bardzo lubię politykę minimalnych uprawnień.

Myślę, że Twoją odpowiedzią trochę płynnie przeszliśmy do tematu, czym jest DevEx. Wydaje mi się, że to jest bardzo istotne. Zapytam Cię od razu, czym jest DevEx i dlaczego może być istotny w branży IT?

Mówiąc DevEx, masz na myśli Developer Experience, tak?

Potwierdzam.

Jeśli dobrze rozumiem, Developer Experience odnosi się do ogólnego doświadczenia i satysfakcji developerów z pracy nad tworzeniem oprogramowania.

Obejmuje to wszystkie aspekty ich codziennej pracy, w tym narzędzia, procesy, środowisko pracy, technologię. Także interakcje z innymi zespołami, co wpływa na skuteczność tworzenia oprogramowania.

Dobrze idę? W dobrym kierunku?

W bardzo dobrym kierunku i myślę właśnie, że to jest to nawiązanie, żeby developerzy jak najmniej musieli prosić się o te rzeczy, o których wspominaliśmy, tylko żeby od razu mieli do tego dostęp. Rozumiem, że polityka bezpieczeństwa, ale też przechodząc przez te wszystkie procesy, pewnie się denerwujemy i zamiast robić swoją pracę, to musimy jednak czekać, aż będziemy mogli pójść dalej. 

DevEx jest ważny. Bezpośrednio wpływa na produktywność, na jakość kodu i na morale zespołu. Poprawa DevEx może prowadzić do szybszego dostarczenia wartościowych funkcji, mniejszej ilości błędów i większej innowacyjności. Kluczowe elementy DevEx to łatwość użycia narzędzi, efektywność procesów oraz wsparcie i kultura organizacyjna sprzyjająca ciągłemu doskonaleniu się i współpracy.

Często wystarczą proste pytania: Czy narzędzie, którego używam, utrudnia mi pracę, czy ją ułatwia? Czy proces pracy eliminuje sposoby, w jakie mogłem popełnić błędy? Albo: Czy środowisko, w którym pracuję, pomaga mi się skupić? Często mówimy o takim flow, że jak zaczynasz nad czymś pracę, to nagle czas szybko mija, a Ty z łatwością realizujesz trudne zadania. Często developerzy chcą po prostu pracować i nie przejmować się na przykład kontaktami z klientami.

Jeśli ludziom stworzy się dobre środowisko do pracy, to zazwyczaj praca jest przyjemniejsza, szybko posuwa się do przodu i, co jest także zauważalne, jest mniejsza rotacja pracowników. Chodzi o to, aby ich praca była nie tylko produktywna, ale także przyjemna i satysfakcjonująca.

Duży wpływ na DevEx mają narzędzia i technologie, z których korzystają developerzy. Mówiłem tu o oprogramowaniu, o tych rzeczach, z którymi ma się styczność każdego dnia. Kolejną rzeczą jest dokumentacja. Dobrze, gdy jest jasna, zwięzła, dostępna i oczywiście aktualna.

Ważna jest także współpraca z innymi ludźmi. Co z tego, że ktoś jest dobrym specjalistą, jeśli nie umie współpracować z innymi? Znam osobę, która jest dobrym specjalistą, ale przez jej zachowanie nikt nie chciał z nią współpracować. Tak więc umiejętność komunikacji jest bardzo ważna. Człowiek, który nie pasuje do zespołu, może go po prostu rozwalić. Dużych projektów nie buduje się przecież samodzielnie.

Można tu jeszcze wspomnieć ogólnie o kulturze organizacyjnej, o tym, jak organizacja dba o pracownika, docenia go itd. Tu nie zawsze chodzi o pieniądze, chociaż wiadomo, wdzięczność i uznanie miło przyjmuje się w gotówce. Dobrze, jak firma docenia ludzi, ale według mnie musi to robić mądrze, bo na przykład awansowanie nieodpowiednich osób przynosi odwrotny skutek.

Chyba trochę odbiegłem od tematu, ale obecnie wiele firm zdaje sobie sprawę, że DevEx prowadzi do szybszych cykli rozwoju, większej innowacyjności i w efekcie lepszego produktu. DevEx jest też teraz postrzegany jako integralna część osiągania celów biznesowych. W związku z tym firmy przeznaczają całkiem niezły budżet i czas na inwestycje w zaawansowane narzędzia, zoptymalizowany przepływ pracy oraz wspierającą kulturę organizacyjną, aby maksymalnie poprawić doświadczenie developerów.

Co ty myślisz aktualnie o DevEx? Jak to wygląda z twojego punktu widzenia?

Ja myślę, że to jest jeden z najważniejszych elementów. Co prawda rynek troszkę się zmienił, ale programiści bardzo doceniają i pamiętają dobre firmy, mocno też wymieniają się takimi informacjami. Wielokrotnie słyszałem coś na zasadzie: Słuchaj, nie warto tam iść, bo dużo mówią, ale mało robią, a w pracy wygląda to całkiem inaczej. 

Nie ma owocowych czwartków.

Tak jest. Jak najbardziej, to pozwala na pewno utrzymać ludzi, budować zespoły, skalować projekty, skalować firmę. Myślę, że to jest bardzo ważny element. Na pewno, tak jak sam zauważyłeś, ma to bardzo istotny wpływ na działania organizacji i pewnie będzie miało jeszcze większy.

Tak, zgadzam się. 

Skoro mamy ten DevEx omówiony, to może warto wspomnieć o Platform Engineering, bo wydaje mi się, że to może być jedna z dróg do DevEx w sensie tworzenia dobrej opinii o firmie i o pracy w niej.

Pracowałem w firmach, w których nie było czegoś takiego jak Platform Engineering oraz w takich, w których to działało całkiem dobrze. Stworzenie czegoś takiego wcale nie jest takie proste, ale według mnie jest bardzo opłacalne. Często w praktyce wygląda to tak, że jest taki dedykowany zespół od platformy, do którego zgłaszają się developerzy z informacją, że chcą zrobić kolejną aplikację i mają konkretne wymagania: że aplikacja będzie w określonym języku, że jest przewidziana na określoną liczbę użytkowników, ruch i tak dalej.

Taki zespół platformy tworzy im gotowe środowisko pracy w bardzo szybkim czasie. Najczęściej automatycznie, za pomocą skryptów i automatyzacji. Platform Engineering można powiedzieć, że to taka praktyka oparta na zasadach DevOps, która ma na celu poprawę bezpieczeństwa, zgodności i oczywiście zmniejszenie kosztów w dłuższym czasie oraz skrócenie czasu tworzenia oprogramowania.

Zarówno zmiana nastawienia oparta na produktach, jak i zestaw narzędzi i systemów, które ją wspierają. Ja na przykład wspomniałem o zespole platformy, ale na przykład bardzo przydatna byłaby taka wewnętrzna infrastruktura, taka platforma, takie IDP, czyli Internal Developer Platform, która mogłaby służyć przyspieszeniu pracy różnych zespołów i na której sam byś mógł sobie wyklikać to, czego potrzebujesz. Różne zespoły korzystałyby oczywiście z niej w trochę inny sposób, ale chodzi o pomoc w ich codziennej pracy.

Zajęcie się chociażby standaryzacją, automatyzacją i uproszczeniem procesów, co pozwala na efektywniejsze tworzenie, testowanie i wdrażanie oprogramowania. Tacy inżynierowie platformy, o których wspomniałem, projektują i utrzymują narzędzia, usługi i infrastrukturę, które zapewniają spójne i wydajne środowisko pracy dla zespołów developerskich, ale nie tylko. Głównym celem Platform Engineering jest zwiększenie produktywności, upraszczanie rzeczy oraz poprawa ogólnego doświadczenia pracy DevEx w organizacji, czyli tego, o czym rozmawialiśmy wcześniej.

Poprzez stworzenie solidnej platformy developerzy mogą skupić się na tworzeniu wartościowego kodu, zamiast tracić czas na rozwiązywanie problemów z infrastrukturą i konfigurowanie poszczególnych usług. Pytałeś, czy to jest jedna z dróg do poprawy DevEx? Otóż moim zdaniem tak, ale DevEx można też poprawić innymi metodami. Wdrożenie praktyk DevOps, takich jak ciągła integracja i ciągłe dostarczanie, również może przyczynić się do lepszego doświadczenia developerów.

Ważne jest również inwestowanie w rozwój umiejętności zespołu oraz promowanie kultury współpracy i ciągłego doskonalenia. Optymalizacja narzędzi developerskich, zapewnienie efektywnej komunikacji i dostęp do zasobów szkoleniowych to kolejne aspekty, które mogą wpłynąć na DevEx. Kluczowe jest zrozumienie potrzeb developerów i dostosowanie środowiska pracy w taki sposób, aby wspierać ich codzienne zadania. Jak wspomniałem już, trzeba zastanowić się, czy dana rzecz ułatwia mi pracę, czy utrudnia, no i eliminować to, co utrudnia pracę, a rozwijać to, co ją ułatwia. To jest teoria. W praktyce to już nie zawsze jest takie proste.

Skoro nie jest proste, to może powiedz nam, jakie kompetencje będą niezbędne właśnie w roli Platform Engineer, żeby mógł dobrze pracować?

Platform Engineer, według mnie, powinien posiadać umiejętności w zakresie zarządzania infrastrukturą, zarówno on-premises, jak i w chmurze. Oczywiście, automatyzacji procesów, programowania na przykład Python, Go, zarządzania konfiguracją na przykład Terraform, Ansible, a także umiejętności miękkie, takie jak komunikacja i współpraca w zespole. Ważne jest również zrozumienie potrzeb developerów i dostarczenie rozwiązań, które poprawią ich efektywność i doświadczenie. Dostarczenie im tego, co potrzebują, co naprawdę pomoże im w pracy.

To może wróćmy jeszcze na chwilę do IDP, o której wspomniałeś. Czy Twoim zdaniem to jedyny kierunek do wdrożenia DevEx w firmie?

Internal Developer Platform, to taka wewnętrzna platforma. Dostarcza ona zazwyczaj developerom zestaw narzędzi, usług, zasobów, aby mogli szybko i efektywnie tworzyć, testować i wdrażać oprogramowanie. Oczywiście tworzenie czegoś takiego nie jest ani proste, ani szybkie. Można by użyć analogii i powiedzieć, że wytyczenie trasy, przejście ścieżki po raz pierwszy i opisanie tego zazwyczaj trwa najdłużej, ale dzięki temu kolejne osoby, które podążają tą samą ścieżką, mają już prościej i pokonują ją szybciej. Wiedzą, gdzie muszą uważać i na co się przygotować.

IDP jest jednym ze sposobów na poprawę DevEx, ale nie jedynym. Jak wspomnieliśmy, istnieją inne metody, takie jak usprawnienie procesów CI/CD, lepsze zarządzanie wiedzą w zespole czy implementacja pętli zwrotnej, która działa. Gdy dostajesz informację zwrotną, co możesz poprawić albo co jest OK, to może naprawdę pomóc. Bo tak naprawdę, gdy nie masz tych informacji, to nie wiesz, czy idziesz w dobrym kierunku. Według mnie takie rzeczy mogą znacząco wpłynąć na DevEx.

Ty też masz takie doświadczenie jako developer. Może dodasz coś w tym temacie?

Jasne. To może jako developer niekoniecznie, ale tak zastanawiałem się, jak to wygląda przy współpracy z osobami, którym pomagam w nauce programowania czy poszerzania umiejętności. Prosty przykład: jeżeli ktoś zrobi projekt, to ja automatycznie dostaję informację na Slacku, że jest do zrobienia code review. Tej osobie automatycznie wysyłam kolejne materiały do kolejnego modułu. Powiedziałbym, że to jest taka platforma, która usprawnia mi cały proces. Raczej to nie jest związane stricte z programowaniem, ale bardzo ułatwia komunikację. Ja nie muszę pytać: jak tam Twój projekt, czy już zrobiłeś, czy masz jakieś problemy, tylko mam od razu informację z GitHuba, że jest pull request i trzeba zrobić code review, a ta osoba dostaje kolejne materiały, więc może się zająć. Działamy asynchronicznie i to wszystko fajnie współgra. Na samym początku miałem tak, że to wszystko trwało. Jeżeli ja nie miałem tego zautomatyzowanego, to ktoś podsyłał linka do pull requesta, ja wtedy wiedziałem, że mam coś zrobić. Dopiero jak odczytałem tę wiadomość, to wysyłałem materiały i to było takie niezbyt fajne. W szczególności, jeżeli, nie wiem, gdzieś jechałem na weekend, a ktoś akurat w piątek wieczorem sobie zrobił projekcik i chciał w weekend usiąść, no i w zasadzie nie miał materiałów. Więc z mojej perspektywy takie usprawnienie. Myślisz, że to można byłoby nazwać IDP, czy nie do końca?

Na pewno jest to taka fajna, szybka pętla zwrotna, że dostajesz od razu informację o tym, że coś jest do zrobienia i możesz pracować dalej. Nie musisz czekać do wieczora, aż może ktoś odpisze, tylko masz to już teraz. Działa to szybko.

Może czas na takie małe podsumowanie. Dokąd Twoim zdaniem zmierza DevOps? Które kompetencje zostaną przejęte przez inne role, a które na przykład zostaną przejęte przez sztuczną inteligencję?

Jak już wspomniałeś o AI, to według mnie to jest ten kierunek. Można zauważyć, że bardzo popularne są tematy, które mają w nazwie AI. Spotkałem się nawet z tym, że jeśli tylko jakaś usługa używa prostych algorytmów, to próbuje się ją sprzedać jako AI.

Ja jestem dość blisko związany z DevOps, więc kładę duży nacisk na automatyzację procesów. Uważam, że coraz większa część zadań będzie zautomatyzowana za pomocą różnych narzędzi. Automatyzacja będzie dotyczyć nie tylko CI/CD, ale także monitorowania, zarządzania infrastrukturą, bezpieczeństwa i naprawiania błędów.

To może bym Ci tylko wszedł w słowo, bo tak się zastanawiam, czy myślisz, że ta sztuczna inteligencja będzie po stronie na przykład osoby odpowiedzialnej za DevOps, czy raczej to będzie po stronie infrastruktury? W sensie, że taki AWS po prostu automatycznie, biorąc pod uwagę te wszystkie inne procesy, które gdzieś tam działają w tle, będzie w stanie wyciągnąć te najlepsze i będzie takie sugestie wrzucał jak Google Analytics czy Google Ads. Słuchaj, bo widzę, że tutaj u Ciebie można byłoby poprawić to i to. Zastanów się nad tym. Można to zrobić tak i tak."

Myślę, że obie odpowiedzi są prawidłowe. Bo w AWS na przykład już jest dostępne coś takiego, że: Słuchaj, Ty tu używasz takich dysków, a gdybyś użył innych, to zapłaciłbyś mniej i miałbyś szybsze dyski. Tak samo ludzie też, moim zdaniem, powinni się tym zainteresować. Już teraz często spotykamy systemy monitoringu bazujące na przykład na wykrywaniu anomalii, jak to, że użytkownik loguje się w innych godzinach niż zazwyczaj. Nie mówiąc już o tym, że na przykład z innego kraju czy jakiejś innej lokalizacji niż zazwyczaj. Tym podobne rzeczy.

Tak więc AI może być używana nie tylko do wykrywania, ale także do automatycznego rozwiązywania problemów w systemach, co zmniejszy potrzebę ręcznego interweniowania. Wspomnieliśmy dzisiaj także o Platform Engineering i IDP i to chyba też jest ten kierunek, w którym to się będzie rozwijać. No i oczywiście bezpieczeństwo. Możemy coraz więcej i coraz szybciej zrobić. Należy pamiętać, że większe możliwości wiążą się z większą odpowiedzialnością. Uważam, że DevSecOps będzie standardem, integrującym praktyki bezpieczeństwa na każdym etapie cyklu życia aplikacji. Zespoły będą korzystać z narzędzi AI do automatycznego wykrywania, testowania, a może nawet naprawy lub zabezpieczenia.

Niestety, często AI traktowane jest jak taka czarna skrzynka. Wiesz, dajesz coś na wejście i oczekujesz fajnych rezultatów na wyjściu. Niestety, jeśli ma być bezpiecznie, to musisz wiedzieć, jak to działa, z jakich źródeł korzysta, jak obrabia dane, jak się uczy i tak dalej, żeby się nie okazało, że Twoje wrażliwe dane są udostępniane mniej znanym trzecim stronom.

Wspomniałeś o tych kierunkach, to może też powiedzmy w co warto zainwestować swój czas, jakie kompetencje mogą się przydać w najbliższym czasie?

Według mnie warto zainwestować swój czas właśnie w AI, zwłaszcza jeśli ktoś to lubi i się tym interesuje. Kompetencje związane z infrastrukturą jako kodem są na pewno w cenie. Ciężko mi sobie wyobrazić pracę bez tego. Tak samo jak konteneryzację, czy wiedzę na przykład o Dockerze i Kubernetesie. Kiedyś już nagrywaliśmy o tym odcinek, więc jeśli ktoś jest ciekawy, to zapraszam do słuchania. Oczywiście nie wpychałbym kontenerów wszędzie na siłę. Jak wspomniałem, jeśli kogoś interesuje ten temat, warto zajrzeć do wcześniejszego odcinka, gdzie się na tym bardziej skupiliśmy.

A propos narzędzi, jakie ludzie używają i AI, mogę powiedzieć, że w majowej ankiecie Stack Overflow, dotyczącej między innymi kodowania, technologii i narzędzi, w której wzięło udział ponad 65 tysięcy developerów, ChatGPT dominuje. Używa go dwa razy więcej developerów niż GitHub Copilota. Wydaje mi się, że taka ankieta może być ciekawym miejscem, gdzie można zajrzeć, żeby sprawdzić aktualne trendy. Jak ktoś jeszcze nie widział, a chciałby, to może wstawimy jakiś link gdzieś pod tym nagraniem, co? Byłoby łatwiej znaleźć.

Jasne.

Wracając do DevOps, odnoszę wrażenie, że będzie nadal ewoluować w kierunku większej automatyzacji i integracji z AI, co zmieni charakter niektórych kompetencji i zadań właśnie. 

Czy widzisz w tym miejscu jakieś zagrożenia? Co jeżeli nadamy, tak jak wspominaliśmy, zbyt dużo uprawnień sztucznej inteligencji, to się nad tym przejedziemy? Myślisz, że to może być niebezpieczne?

Pewnie będą tego typu sytuacje, zwłaszcza na początku, gdy to będzie w fazie testów, uczenia się. Może to i będzie dobra decyzja, bo jak użytkownicy zżerają więcej zasobów niż powinni, to może o czymś zapomnieli albo coś da się inaczej skonfigurować, bardziej optymalnie. Należy też pamiętać, że jeszcze długo nie dojdziemy do poziomu, gdy to sztuczna inteligencja będzie podejmowała ostateczne decyzje. Zawsze gdzieś tam będzie człowiek, który może pomóc to skalibrować, ustawić tak, by działało jak powinno i cofnąć wprowadzone zmiany.

Zazwyczaj, jak się wprowadza nowe polityki blokujące ruch, chociażby ograniczające dostęp, to najpierw się je wprowadza tylko w formie informacyjnej, czyli dodajesz nowe ustawienie, sprawdzasz w logach, czy na pewno blokujesz odpowiedni ruch i swoimi regułami czegoś nie zepsujesz. Dopiero po jakimś czasie przestawiasz konfigurację z zwykłego informowania na blokowanie. A gdyby coś poszło nie tak, to zawsze możesz zrobić szybki rollback i wycofać swoje zmiany.

Dlatego właśnie bardzo lubię infrastrukturę jako kod. Jeśli nowe zmiany nie działają tak, jak powinny, to można je szybko wycofać. Nie boisz się klikania po dziesięciu kontach i wycofywania zmian, myśleniem, co tam ostatnio zmieniłem, tylko klikasz rollback i wycofujesz swoje zmiany. Oczywiście AI jest na razie na bardzo niskim poziomie, ale w przyszłości może się to zmienić. Kompetencje związane z automatyzacją, bezpieczeństwem, monitorowaniem i zarządzaniem infrastrukturą mogą zostać przejęte przez bardziej wyspecjalizowanych ludzi, bo te obszary mogą w przyszłości się rozrosnąć.

AI natomiast może odgrywać coraz większą rolę w automatyzacji procesów, monitorowaniu, diagnostyce, zarządzaniu wydajnością, co pozwoli na jeszcze szybsze i bardziej efektywne dostarczanie oprogramowania. Ale to takie przypuszczenie. Jak to mówią, co będzie, to czas pokaże.

Mam nadzieję, że dzisiaj zrobiliśmy odpowiednie podsumowanie, pokazaliśmy ścieżki rozwoju, że nie zanudziliśmy albo nie narzuciliśmy zbyt dużej ilości skrótów. Taka była prośba od jednego ze słuchaczy, żeby zrobić takie podsumowanie, więc robimy.

Na koniec chciałbym poprosić Cię o książkę, jaką polecisz osobie, która chciałaby lepiej poznać świat DevOps. Wiem, że w zasadzie polecamy też niekoniecznie książki związane z DevOps i to jest ciekawe, że raczej ludzie niekoniecznie polecają rzeczy, które są związane z ich technologiami, tylko polecają coś, co jest nie do końca związane. Myślisz, że po prostu trzeba mieć równowagę, czy to jest związane z czymś innym?

Aktualnie czytam Atomowe nawyki Jamesa Cleara, ale jeszcze czeka mnie książka CIONET Cookbook: Recipes for Digital Success którą dostałem w tym roku na konferencji AWS Community Day od Kuby Wołynko. Jeśli ktoś chce poznać lepiej świat DevOps, to może zacząć od czytania blogów ludzi pracujących w tej branży, od oglądania filmów z tym związanych, a najlepiej to zacząć działać w tym kierunku. Moim zdaniem nic nie zastąpi praktyki.

Z książkami jest ten problem, że wiedza bardzo szybko się aktualizuje, a bardzo ciężko jest zmienić w nich treści. W internecie na blogu zawsze możesz wydać jakiś update, a update książki troszkę trwa, więc te książki dość szybko mogą się zdezaktualizować. 

Zanim się napisze i wyda, to już się okazuje, że nie warto, bo te rzeczy, które tam są, to już są nieaktualne. 

Dlatego moim zdaniem nic nie zastąpi praktyki.

Jasne. Powiedz nam proszę, gdzie możemy Cię spotkać w sieci, jeżeli ktoś by chciał się czegoś dowiedzieć, podpytać, a może nawet zrealizować Twój kurs, który może prędzej czy później się pojawi.

Może. I jak zwykle na moim blogu lepczynski.it oraz na kanale YouTube, gdzie staram się dzielić swoją wiedzą dotyczącą chmury, automatyzacji i ogólnie moich przygód w świecie DevOps. Aktualnie moje spojrzenie na chmurę i świat się zmienia, więc tworzone przeze mnie treści również się zmieniają. Kiedyś tworzyłem głównie tutoriale opisujące co, jak zrobić, a teraz planuję podążać troszkę w innym kierunku.

Chcesz nam powiedzieć w którym, czy na razie to jest tajemnica?

Zobaczymy, jak to wyjdzie, ale planuję tworzyć więcej treści opisujących pracę DevOpsa, pracę w chmurze i też powiedzieć, co można zrobić, żeby podążać w tym kierunku, gdzie warto zajrzeć. Kiedyś planowałem opisać swoją własną ścieżkę od admina do DevOpsa. Zobaczymy, jak to wyjdzie. Aktualnie jestem bardzo zajęty i trochę brakuje mi na to czasu, ale mam nadzieję, że akurat na to znajdę jednak ten czas, bo często mnie ktoś pyta o coś takiego. I oczywiście można znaleźć mnie też na LinkedInie.

W takim razie tym bardziej dziękuję, że pojawiłeś się tutaj, nie mając czasu. Bardzo Ci dziękuję za tę rozmowę i podzielenie się z nami swoimi doświadczeniami.

Dzięki, no trochę już się przekładał ten odcinek. Fajnie, że się w końcu udało go nagrać.

Jasne, ja również dziękuję, z Tobą zawsze się fajnie gada, a czas szybko mija. Dziękuję Wam, drodzy słuchacze, że byliście z nami przez cały czas i zapraszam do wysłuchania także innych odcinków podcastu, w których Mateusz spotyka się z innymi ciekawymi ludźmi. Dzięki, Mateusz, mam nadzieję, że jeszcze się kiedyś spotkamy.

Do zobaczenia, cześć.

Na pewno, cześć.