Rola developera w rozwoju i utrzymaniu rozwiązań chmurowych na przykładzie AWS
W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Bartłomiejem Wasiukiem z Capgemini o roli developera w rozwoju i utrzymaniu rozwiązań chmurowych na przykładzie AWS.
Posłuchaj naszej rozmowy w wersji audio 🎧 👇
Cześć, Bartku, bardzo miło mi gościć Cię w podcaście.
Cześć, Krzyśku, witam wszystkich.
Z Bartkiem słyszymy się już po raz drugi. Ostatnio mieliśmy okazję w odcinku 173. mówić o tworzeniu przyjaznych środowisku i opartych o chmurę aplikacji w Java i dzisiaj niejako te dwa główne wątki będziemy kontynuować, bo też będziemy mówić o wytwarzaniu software’u, też będziemy mówić o opieraniu tych rozwiązań właśnie o chmurę, ale skupimy się, tak jak sobie z Bartkiem już zdążyliśmy ustalić, na rosnącej roli developera w rozwoju, w utrzymaniu tych rozwiązań chmurowych i będziemy się posługiwać przykładami z chmury AWS. Myślę, że brzmi bardzo ciekawie.
Klasycznie chciałbym Cię, Bartek, zapytać o to, czy słuchasz podcastów. Może masz jakieś ciekawe audycje, o których byłbyś w stanie tutaj powiedzieć?
W tej kwestii chyba nic Ci nie zmieniło od ostatniego razu. Nie wiem, czy to jest dobra reklama, ale nie słucham za często podcastów przede wszystkim. Do mnie osobiście bardziej przemawia słowo pisane. Jeśli mam czegoś słuchać, to muszę się na tym bardzo mocno skupić. Wolę czasami jednak coś przeczytać i tutaj może podcastu nie polecę, ale polecę taką stronę anglojęzyczną infoq.com. Jest to bardzo ciekawa strona, agregująca nowinki ze świata technologii. Osobiście pozakładałem tam sporo filtrów, alertów. Raz w tygodniu dostaję zbiorczy mail z interesującymi mnie najciekawszymi tematami, głównie związanymi z architekturą, z rozwiązaniami chmurowymi, z architekturą opartą o mikroserwisy, nowinki Javowe. Polecam gorąco.
Tak, to jest solidne i bardzo bogate źródło wiedzy, zdecydowanie warto polecić, ale właśnie warto w takim podejściu przefiltrowania tych tematów, tych wątków, na których nam zależy do tego podejść, bo można faktycznie zginąć w tym morzu artykułów i newsów.
Dokładnie, jedyny podcast, który znam, taki IT, który mogę polecić, to nie wiem, czy znacie, porozmawiamy o IT. Bardzo ciekawi goście, ciekawe tematy, to mogę z czystym sumieniem polecić.
Dzięki, myślę, że tak, co niektórzy mogą kojarzyć. Tak, z Bartkiem spotykamy się tutaj też na kanwie Tech Talka, który Bartek będzie niedługo miał okazję poprowadzić w ramach Capgemini Tech Talk. Chciałbym Cię, Bartek, prosić, żebyś właśnie zareklamował, żebyś zaprosił, bo myślę, że to będzie też bardzo fajne rozszerzenie i uzupełnienie tych tematów, które dzisiaj poruszamy.
Z pewnością. Więc chciałbym zaprosić Was wszystkich na Tech Talk 6 czerwca we Wrocławiu. W socialach Capgemini są linki do bezpłatnej rejestracji na to wydarzenie, tak że możecie sobie sprawdzić, o której godzinie, w jakim miejscu. Będzie dwóch prelegentów, ja i mój kolega. Będziemy opowiadali na temat pracy w chmurze. Ja skupię się na roli programisty w pracy z chmurą na przykładzie AWS-u. Dzisiaj, jak już wspomniałeś, porozmawiamy sobie troszkę na ten temat. Natomiast dzisiaj nie zdradzę wszystkich odpowiedzi i wszystkiego, co będę chciał powiedzieć. ale myślę, że będzie to taki dobry wstęp, dobra zajawka na ten temat.
Pewnie zostawimy pewien niedosyt. Myślę, że jak najbardziej to ma sens, a dla ułatwienia w notatce do odcinka też znajdzie się strona, gdzie możecie się na to wydarzenie darmowe, powtarzamy tutaj, zapisać i właśnie dowiedzieć się jeszcze więcej.
Super, to rozpocznijmy może od powiedzenia sobie, jak te różne role, które obecnie w IT z chmurą są związane, te związane oczywiście z wytwarzaniem i utrzymaniem rozwiązań, bo jeśli byśmy chcieli szerzej patrzeć, to pewnie jeszcze więcej by się ich znalazło, ale myślę tutaj głównie o DevOps Inżynierze, Cloud Inżynierze i developerze jako takim. Jaki jest podział odpowiedzialności, jaki jest podział obowiązków tych ról właśnie w kontekście tworzenia i utrzymania rozwiązań opartych o cloud?
Właśnie to nie jest takie proste pytanie. Może inaczej, pytanie jest proste, odpowiedź nie jest taka prosta i taka oczywista. Zacznijmy od próby jakiejś definicji i określenia obszarów odpowiedzialności wymienionych przez Ciebie ról. Przede wszystkim DevOps. DevOps, ta nazwa w ogóle powstała z połączenia angielskich słów development i operations. Termin ten bardziej opisuje taką metodykę organizacyjną, mającą na celu w pewien sposób utrzymanie współpracy pomiędzy działami wytwarzania i oprogramowania, czyli development oraz zarządzania systemami, operations.
Można powiedzieć więc, że DevOps Inżynier to osoba, która w swojej pracy i podejściu do tej pracy łączy elementy rozwoju oprogramowania i utrzymania infrastruktury. Stanowisko DevOps jest taką ewolucją założenia o bliskiej współpracy działów developerskich z operacyjnymi. Jeśli chodzi o zakres odpowiedzialności osoby pracującej w roli DevOpsa, można wymienić takie rzeczy jak tworzenie infrastruktury, przygotowywanie środowisk pracy dla developerów, testerów, tworzenie pipeline’ów CI/CD, zarządzanie pracą z repozytorium kodu, monitoring aplikacji, infrastruktury, automatyzacja reakcji na incydenty, może nawet definiowanie procesów związanych z incident managementem, implementacja metryk dotyczących infrastruktury i aplikacji.
To jest taki bardzo podstawowy zbiór zadań, którymi na co dzień zajmują się inżynierowie DevOps. Jak widać, jest to bardzo pojemny zbiór i jest to spora część tzw. inżynierii programowania. Samo programowanie to jest de facto wycinek tego, co można nazwać software engineeringiem. DevOpsi zajmują się wsparciem, takim tworzeniem tego środowiska. I w sumie nie jest to rola taka stara, bo jeśli dobrze pamiętam, samo pojęcie DevOps zostało po raz pierwszy zaproponowane ok. 2009 roku. Więc koncept jest w miarę świeży, ale uważam, że bardzo potrzebny, ponieważ dzięki temu, że ktoś dba o środowisko, o infrastrukturę, o ten cały ekosystem, programiści mogli skupić się (czemu używam czasu przeszłego, do tego dojdę) bardziej na logice biznesowej i w miarę szybkim dostarczaniu nowych funkcjonalności, nowych feature’ów na tym, żeby ten time to market, go to market był jak najkrótszy.
Kolejna rola, o której wspomniałeś, rola, która przyszła nam i jest silnie powiązana z konkretną technologią, z konkretnym konceptem, czyli Cloud Engineer. Można o Cloud Engineerze powiedzieć, że jest to taki DevOps w środowisku chmurowym. Czym zajmuje się Cloud Engineer? Oczywiście ja uogólniam, uśredniam, że tak powiem, rolę, zakres odpowiedzialności, więc proszę mnie nie linczować za to, że u mnie w firmie inaczej troszkę jest, u mnie jest troszkę inaczej. Uśredniam, chcę to bardzo mocno podkreślić.
Więc Cloud Engineer można powiedzieć, że jest to taki inżynier, który zajmuje się obsługą infrastruktury chmurowej w bardzo dużym skrócie. Na pewno wymaga to bardzo dobrej znajomości rozwiązań chmurowych, takich jak AWS, Azure, Google Cloud lub innych. Wiemy, że tych chmur jest cała masa, dostawców jest bardzo dużo, bo to także Apple, IBM, w zasadzie każda większa licząca się firma technologiczna ma swoją chmurę, z której korzysta, chociażby np. do swoich zastosowań wewnętrznych. I ktoś to musi utrzymywać, ktoś musi w tym pracować, prawda?
Spośród umiejętności technicznych Cloud Engineera możemy wymieniać kompetencje z zakresu sieci komputerowych, np. bezpieczeństwa IT, baz danych, oprogramowania, nawet oprogramowania serwerowego, i narzędzi deploymentu, jakby nie patrzeć. Wielu pracodawców wymaga również znajomości Dockera, znajomości orkiestratora kontenerowego jak Kubernetes, Docker Swarm, ale głównie Kubernetes. Np. AWS bardzo mocno korzysta z Kubernetesa, jeśli chcemy wdrożyć, zarządzać orkiestrację kontenerów w naszym projekcie.
Myślę, że jednak bardzo ważne w roli Cloud Engineera jest to, jak zapewnić skalowalność i niezawodność systemów działających w chmurze, a także jak optymalizować koszty wykorzystania serwisów natywnych danego rozwiązania chmurowego. Poza tym automatyzacja pracy w chmurze, pipeline’y CI/CD. Brzmi tak samo jak DevOps, tylko w chmurze, prawda?
Natomiast trzecia trzecia rola, czyli rola developera. Nam rola developera przeważnie kojarzy się z osobą, która siedzi i klepie kod. Tworzy kod. Klepie to może bardzo pejoratywne określenie, ujmijmy to: osoba, która tworzy kod. I rzadko przyjmuje się tym, co się dookoła dzieje. Natomiast w moim odczuciu, na podstawie moich obserwacji, moich doświadczeń, powoli się to zaczyna troszkę zmieniać.
Myślę, że jednak bardzo ważne w roli Cloud Engineera jest to, jak zapewnić skalowalność i niezawodność systemów działających w chmurze, a także jak optymalizować koszty wykorzystania serwisów natywnych danego rozwiązania chmurowego. Poza tym automatyzacja pracy w chmurze, pipeline’y CI/CD.
Właśnie, to w tym kontekście chciałbym jeszcze Cię trochę pociągnąć za język też na bazie Twoich doświadczeń. Ponieważ o ile dla Cloud Engineera, dla DevOps Engineera obcowanie z chmurą to jest praktycznie chleb codzienny, o tyle de facto ciężko by sobie było wyobrazić realizację tych właśnie założeń czy tych zadań technicznych, o których tutaj powiedziałeś, gdyby tych nowoczesnych rozwiązań chmurowych nie było, ale według mnie chmura najbardziej wpływa, czy modyfikuje właśnie to, czym zajmuje się developer, albo w jaki sposób realizuje te zadania.
We wcześniejszym ujęciu jeszcze przed tą filozofią DevOps mieliśmy, tak jak tutaj zaznaczyłeś, te dwa dosyć nieraz mocno odseparowane, nieraz wręcz antagonizujące za sobą działy wytwarzania i później wdrożenia czy utrzymania. Dzięki DevOps nieco zbliżamy do siebie te dwa działy. Ale teraz właśnie okazuje się, tak jak tutaj zaznaczyłeś, że ta rola developera też musi być coraz bardziej świadoma tego, jak chmura działa, jakie możliwości daje. W związku z tym chciałbym Cię zapytać, czy taki nowoczesny programista, powiedzmy, to już musi być za pan prac z chmurą? Musi wiedzieć, jakie są możliwości chmury, żeby szybciej, lepiej, łatwiej realizować swoje zadania? Czy to ciągle jest takie zadanie dla chętnych jeszcze?
W mojej opinii nie uciekniemy od chmury. Stary model oparty na stawianiu własnych serwerów stawianiu własnych data center, utrzymywaniu infrastruktury tej fizycznej, hardware’owej, powoli odchodzi w przeszłość. Tak jak już wspomniałem, każda najbardziej licząca się firma IT, nie tylko IT, która ma bardzo rozbudowany dział IT, posiada już własną chmurę, własne rozwiązanie chmurowe albo korzysta z jednego z najpopularniejszych publicznych dostawców rozwiązań chmurowych. Nie uciekniemy od chmur.
Chmury pozwalają nam zamienić koszty utrzymania całej infrastruktury hardware’owej na koszty związane po prostu z użyciem tego, czego potrzebujemy. To znaczy, że jeśli mamy mały ruch, mało płacimy, powiedzmy na naszej stronie. Jeśli mamy jakiś backendowy system do przetwarzania danych, jeśli mamy mało tych danych do przetwarzania, mało płacimy. Jeśli mamy tego więcej do przetworzenia, to siłą rzeczy więcej zapłacimy. Więc koszty są uzależnione od naszych potrzeb tak naprawdę.
Skalowalność, kolejna rzecz, bardzo ważna. Myślę, że to jest rzecz, której nie można przecenić. Jak wygląda skalowalność przed chmurą? Trzeba było wysłać zapotrzebowanie do procurementu czy do innego działu na kolejny serwer, trzeba było pojechać, kupić albo zamówić, zamontować, zainstalować, zrobić testy. Jak tego sprzętu się nam za dużo robiło, trzeba było kolejnego admina zatrudnić. To wszystko było czas i koszty. Teraz, jeśli mi się zwiększa ruch, zwiększa mi się ilość danych, którą muszę przetworzyć, to co robię? Ustawiam prostą regułę i voila! Wszystko samo automatycznie się dzieje.
Więc od chmury nie uciekniemy. Żaden developer. My w IT od chmury nie uciekniemy, będziemy, póki co nie ma lepszego rozwiązania, więc myślę, że z chmurą każdy, kto pracuje w IT, każdy inżynier powinien być jak najbardziej zaznajomiony. Teraz pytanie, w jakim stopniu? W jakim stopniu inżynierowie, developerowie powinni zapoznać się z tą chmurą?
W moim mniemaniu im więcej, tym lepiej. Większa świadomość usług, jakie chmura nam dostarcza, większa świadomość tego, co my możemy zrobić, spowoduje, że my będziemy po prostu tworzyli lepszy, szybszy, lepiej skalowalny kod. Będziemy dostarczali po prostu lepszą wartość klientowi. Klient, który jest zadowolony, to jest klient, który wróci, klient, który zamówi więcej, klient, który poleci nas komuś innemu. Więc, na tym chyba wszystko polega, prawda?
👉 Czytaj dalej: https://porozmawiajmyoit.pl/poit-247-rola-developera-w-rozwoju-i-utrzymaniu-rozwiazan-chmurowych-na-przykladzie-aws/
