22 maj 2024 POIT #247: Rola developera w rozwoju i utrzymaniu rozwiązań chmurowych na przykładzie AWS
Witam w dwieście czterdziestym siódmym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest rola developera w rozwoju i utrzymaniu rozwiązań chmurowych na przykładzie AWS.
Dziś moim gościem jest Bartłomiej Wasiuk – pełni rolę architekta oprogramowania, lidera technicznego oraz people managera we wrocławskim oddziale Capgemini Polska. Od kilkunastu lat, w zależności od projektu, pracuje przy implementacji, projektowaniu i wdrażaniu rozwiązań z obszarów telekomunikacji i finansów. Preferuje stos technologiczny oparty o język programowania Java, ale zawsze dobiera odpowiednie narzędzie pod konkretne rozwiązanie. Doświadczony w pracy z metodykami zwinnymi Scrum oraz SAFe.
Sponsor odcinka
Sponsorem odcinka jest Capgemini Polska.
W tym odcinku o roli developera w rozwiązaniach chmurowych rozmawiamy w następujących kontekstach:
- jaka jest odpowiedzialność ról DevOps engineer, cloud engineer i developer?
- czy nowoczesny programista musi rozumieć jak działa chmura i jak ją wykorzystywać?
- jakie znaczenie w tym temacie ma upowszechnianie się podejścia IaC?
- jakie narzędzia, które udostępnia AWS mogą się przydać developerom do definiowania i zarządzania infrastrukturą?
- jakie umiejętności chmurowe powinien obecnie mieć programista?
- jakie są najczęstsze błędy, które popełniają developerzy przy pracy z AWS i jak można ich unikać?
- jak będzie się zmieniało znaczenie roli developera w rozwiązaniach chmurowych?
Subskrypcja podcastu:
- zasubskrybuj w Apple Podcasts, Google Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
- ściągnij odcinek w mp3
- poproszę Cię też o polubienie fanpage na Facebooku
Linki:
- Profil Bartka na LinkedIn – https://www.linkedin.com/in/bartlomiej-wasiuk-01814961/
- Capgemini TECH TALK – https://www.capgemini.com/pl-pl/aktualnosci/wydarzenia/tech-talk-meet-up-5-cloud/
Wsparcie na Patronite:
Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.
Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.
👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit
Pozostańmy w kontakcie:
- 📧 Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
- 📩 Zapisz się na newsletter, aby nie przegapić kolejnych ciekawych odcinków
- 🎙 Subskrybuj podcast w lub
Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)
Transkrypcja podcastu
To jest 247. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o roli developera w rozwoju i utrzymaniu rozwiązań chmurowych na przykładzie AWS.
Sponsorem tego odcinka jest Capgemini Polska. Wszystko, co potrzebujesz, notatka, linki, transkrypcja, czekają na Ciebie na porozmawiajmyoit.pl/247.
Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka.
Odpalamy!
Cześć, mój dzisiejszy gość pełni rolę architekta oprogramowania, lidera technicznego oraz people managera we wrocławskim oddziale Capgemini Polska. Od kilkunastu lat w zależności od projektu pracuje przy implementacji, projektowaniu i wdrażaniu rozwiązań z obszarów telekomunikacji i finansów. Preferuje stos technologiczny oparty o język programowania Java, ale zawsze dobiera odpowiednie narzędzie pod konkretne rozwiązanie. Doświadczony pracy z metodykami zwinnymi Scrum oraz SAFe. Moim i Waszym gościem jest Bartłomiej Wasiuk.
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?
Myślę, że na tym rynku, na którym teraz jesteśmy, gdzie liczy się czas, w którym będziemy w stanie dostarczyć usługę, to również wykorzystanie tych rzadko gotowych elementów, oczywiście w odpowiednim dostosowaniu do swojego rozwiązania, też przyspiesza znacząco ten czas dostarczenia na rynek rozwiązania. Niekiedy jest to być, a nie być dla danego biznesu.
Oczywiście możemy pewnie mnożyć jeszcze różne inne powody, dla których warto byłoby ze strony developera zainteresować się chmurą, ale świadomość to jest jedno, a drugie to jest danie takich rozwiązań albo uproszczenie tego procesu, żeby developer chciał po prostu wykorzystywać te możliwości, żeby to zwyczajnie było przyjemne i łatwe. Jestem ciekawy, jak Ty oceniasz, czy pojawienie się infrastruktury jako kodu, jest tutaj krokiem w tym kierunku, czy to daje takie właśnie narzędzia developerem, żeby chętnie i łatwo byli w stanie sobie tę infrastrukturę za pomocą tego toola, który znają, czyli języka programowania, kształtować. Super by było, jeśli jakieś przykłady właśnie na bazie AWS byłbyś w stanie zaprezentować.
Więc zacznijmy od tego, że programista, który pracuje z chmurą, może ograniczyć się tylko do tworzenia kodu. Może tworzyć sobie mikroserwisy, które CloudOps, czy Cloud Engineer, czy DevOps będą w stanie wdrożyć, powiedzmy, czy stworzyć pipeline wdrożeniowy, pipeline CI/CD, i programista tylko będzie klikał jeden przycisk i ten kod jego będzie leciał, będzie tam testowany itd. Wszystko fajnie, tylko potrzeba tutaj czasu. Potrzeba przynajmniej dwóch osób do tego.
Teraz tak, można zakodować w mikroserwisach bardzo dużo rzeczy, ale są natywne usługi AWS-owe, które bardzo pomagają, bardzo upraszczają i przyspieszają już nawet nie tylko proces tworzenia tego oprogramowania, proces tworzenia całej infrastruktury, ale także są już przetestowane, są wykorzystywane przez tysiące, jak nie miliony ludzi na świecie i są sprawdzone, bezpieczne, szybkie, optymalne itd. Więc fajnie jest, żeby programista wiedział o takich rozwiązaniach.
Ja na przykład jestem programistą i potrzebuję, żeby mój mikroserwis miał swoją bazę danych. To co, będę dzwonił po DBAdmina, żeby mi założył taką bazę danych, wszedł w konsolę AWS-ową, wyklikał ją? Jest to mało efektywne. Ja potrzebuję mieć takiego gateway’a, który będzie do odpowiedniego mikroserwisu przekierowywał zapytania, requesty. Zwykłe, restowe. I będę dzwonił po jakiegoś API architekta, żeby mi to zaprojektował? Nie, mamy np. usługę API Gateway, prawda? Mamy Route 53, więc mogę te przekierowania wszystko sobie fajnie porobić. Tak że developer, który ma świadomość istnienia takich funkcji, istnienia takich serwisów, jest w stanie sam sobie bardzo szybko przygotować to środowisko pracy, wdrożyć je i użyć.
I teraz dochodzimy właśnie do sedna: jak to zrobić, żeby to było powtarzalne. Generalnie od lat programiści mają środowiska testowe. Środowisko developerskie, testowe, produkcyjne. To jest takie minimum, prawda? Ja pracowałem jeszcze z osobnymi środowiskami, benchmarkowym, to było środowisko, gdzie po prostu bardzo dużo zasobów mieliśmy, mieliśmy bardzo dużo danych i tam były testy obciążeniowe, stresowe itd., było też środowisko tzw. eksternalne, to było środowisko takie brzegowe, gdzie nasza sieć była połączona z sieciami klientów i tam robiliśmy wspólne testy end-to-end, ale takie naprawdę end-to-end rozwiązań naszych i tej naszej części i części naszych partnerów.
Tak że mamy kilka środowisk i ja chcę, żeby moje usługi wszędzie tak samo wyglądały. To jeśli ja wchodzę na konsolę AWS-ową i sam ręcznie wyklikuję, tworzę, ustalam role IMO-we, ustalam dostępy, tworzę certyfikaty, ACM itd., to bardzo łatwo jest o ludzki błąd. Więc jak to zrobić, żeby po pierwsze to było powtarzalne, a po drugie żeby programiści byli w stanie to dość łatwo przygotować? To robimy: definicja zasobów za pomocą jakiegoś kodu.
I tutaj z pomocą przychodzi AWS. Jest taki framework CloudFormation, gdzie za pomocą JSON-ów, YAML-i definiujemy taki template, szablon. Za pomocą tego szablonu tworzymy tzw. CloudFormation Stack w czasie deploymentu na chmurę, na AWS-a. I ten stack to jest nic innego jak po prostu stos usług AWS-owych. Więc możemy sobie za pomocą takich template’ów zdefiniować coś, co jest powtarzalne, będzie wyglądało i działało tak samo na każdym naszym środowisku.
Kolejną rzeczą, kolejnym krokiem naprzód, że tak powiem, jest AWS CDK, czyli Cloud Development Kit. Jest to taka nakładka na CloudFormation, jeszcze wyższa forma abstrakcji, można tak powiedzieć, gdzie ja nie używam YAML-ów, nie używam JSON-ów do definiowania takiego template’u, tylko ja tworzę normalną aplikację. Mam klasy, mam metody. Mój stos to jest normalna klasa wewnątrz klasy pod nazwą aplikacja. Ja definiuję sobie funkcję Lambda, definiuję sobie API Gateway, definiuję sobie IAM role. Robię to wszystko w kodzie. Jest normalna biblioteka do tego. AWS dostarcza biblioteki do tego. Jest pełne API. Ja piszę kod. De facto piszę kod, który potem jest zamieniany na infrastrukturę, na usługi. To jest rzecz według mnie wspaniała, która bardzo pomaga developerom i bardzo upraszcza pracę ze środowiskiem.
Też użyłeś stwierdzenia infrastructure as a code. Słowo infrastruktura w ogóle troszkę zmieniło swoje znaczenie w kontekście środowiska chmurowego. Czym jest infrastruktura? Infrastruktura to drogi, mosty, tory, w takim ogólnym znaczeniu, przekładając na język IT: Dyski twarde, szafy krosownicze, serwery, cały ten hardware. Kiedy pracujemy w chmurze, to dla nas infrastrukturą są wszystkie usługi, które my mamy, z których korzystamy. Usługi natywne AWS-a. Ale też my jesteśmy w stanie sami definiować sobie serwer swój. Np. NGINX-a jesteśmy w stanie sobie sami zdefiniować. Zdefiniować sobie Redirecty, zdefiniować sobie proxy. Całą masę innych rzeczy, które też jako administrator takiego Apache HTTP serwera jestem w stanie zmienić, w pliku serwer XML, jeśli dobrze pamiętam.
Lata temu się z tego korzystało, ale jesteśmy w stanie podobne rzeczy teraz też w chmurze zdefiniować za pomocą kodu. Czy to template, czy to właśnie AWS CDK. To bardzo ułatwia pracę developerom, ale też bardzo pomaga zrozumieć developerom zależności i jak działają, jak skonfigurować poszczególne serwisy w chmurze AWS-owej.
Ja na przykład jestem programistą i potrzebuję, żeby mój mikroserwis miał swoją bazę danych. To co, będę dzwonił po DBAdmina, żeby mi założył taką bazę danych, wszedł w konsolę AWS-ową, wyklikał ją? Jest to mało efektywne. Ja potrzebuję mieć takiego gateway’a, który będzie do odpowiedniego mikroserwisu przekierowywał zapytania, requesty. Zwykłe, restowe. I będę dzwonił po jakiegoś API architekta, żeby mi to zaprojektował? Nie, mamy np. usługę API Gateway, prawda? Mamy Route 53, więc mogę te przekierowania wszystko sobie fajnie porobić. Tak że developer, który ma świadomość istnienia takich funkcji, istnienia takich serwisów, jest w stanie sam sobie bardzo szybko przygotować to środowisko pracy, wdrożyć je i użyć.
Na pewno wartość takiego podejścia można traktować na różnych poziomach. Od tego lepszego zrozumienia, o którym właśnie powiedziałeś, co pozwala lepiej zaprojektować, lepiej zaimplementować to rozwiązanie, bo wiemy, jak to pod spodem będzie działało, a nie tak jak kiedyś, gdzie była to po prostu czarna skrzynka i de facto ciężko było zrozumieć i przewidzieć, co tam się może wydarzyć, po pewnie przyspieszony właśnie deployment, release, w ogóle szybsze dostarczanie całego rozwiązania.
Ale myślę sobie, że z taką mocą idzie też duża odpowiedzialność, prawda? I też nie chcielibyśmy robić z developerów Cloud Engineerów, żeby tutaj przesunąć tę odpowiedzialność w pełni, więc zastanawiam się, czy masz jakieś przykłady, czy być może kojarzysz też takie rozwiązania procesowe ze strony firmy, może jakieś narzędzia, które jest w stanie firma jako taka zaproponować developerom, żeby oczywiście mieli tę możliwość definiowania infrastruktury, ale mimo wszystko, żeby robili to, co należy do tych podstawowych zadań, czyli logika biznesowa, tak to nazwijmy, żeby nie musieli tych powtarzalnych czynności cały czas tutaj repetytywnie wdrażać.
Zadajesz bardzo ciekawe pytania i znowu moja odpowiedź będzie wielowarstwowa. Nie da się inaczej odpowiedzieć. Po pierwsze zgadzam się ze stwierdzeniem, że jeśli ja chcę programować w chmurze, ja nie muszę być Cloud Engineerem. Nie muszę być. Dobrze jest, bardzo dobrze jest, jest to bardzo mile widziane, jeśli ja znam i rozumiem, jak działa chmura, znam usługi chmurowe, ale ja nie muszę być takim w pełni wyspecjalizowanym takim masterem. Mogę być, ale nie muszę.
To wszystko zależy od tego, jak projekt wygląda, od tego, jaka jest moja firma, w czym się specjalizuję, czym się zajmuję, jaki jest zakres działań, zakres odpowiedzialności. Bardzo dobrze jest, ja będę to podkreślał, jeśli developer zna, rozumie chmurę, zna usługi, wie, jak z nich korzystać, wie, jak robić. Natomiast developer jednak jest od tworzenia rozwiązań, od tworzenia softu. Nawet teraz, kiedy ja pracuję z chmurą, pracuję u moich klientów, zawsze jest jakiś wyspecjalizowany zespół Cloud Engineerów, CloudOpsów. Zespół, który ma bardzo gruntową i bardzo wyspecjalizowaną wiedzę na temat chmury.
I kiedy my – ja, mój zespół – trafimy na jakiś problem, nie jesteśmy w stanie go rozwiązać. Zawsze jest ekipa, która jest w stanie nam pomóc, taka last resort, można by powiedzieć. Więc też nie jest tak, że jeśli developer ma znać chmurę, to ma wszystko wiedzieć o chmurze. Nie, nie bójmy się powiedzieć, że nie wiemy wszystkiego i czasami są takie problemy, że trzeba poprosić po prostu o pomoc, zamiast się zakupywać na miesiąc z danym problemem.
Idąc dalej, w przypadku dużych organizacji są też zespoły, które wewnętrznie działają na rzecz tej organizacji. Może nie do końca tworzą rozwiązania dla klientów tej organizacji, nie do końca tworzą bezpośrednio rozwiązania na rzecz klientów, nie w bezpośredni sposób tworzą takie środowisko dla końcowych użytkowników, oni pracują, tworzą rzeczy na wewnętrzny użytek firmy. W przypadku dużych korporacji, dużych firm IT, czy firm, które posiadają bardzo duże działy IT, to też chciałbym podkreślić, musimy mieć jakieś, jakby to nazwać, ujednolicenie naszego ekosystemu.
Standaryzacja usług.
Standaryzacja usług, standaryzacja rozwiązań. Dokładnie, właśnie o to mi chodzi. I teraz jak to osiągnąć? Poprzez definiowanie procesów, definiowanie takich rzeczy jak np. look and feel, czyli definiowanie kolorów do UI, na przykład, prawda? Ale też tworzenie wewnętrznych jakichś bibliotek, tzw. customizacja. I teraz do czemu to jest ważne i czemu to jest przydatne? Jak już powiedziałem, jedna rzecz to jest standaryzacja rozwiązań itd., a z drugiej strony AWS, dajmy na to AWS, to jest ogromna technologia, to jest ogromna przestrzeń, ponad 200 serwisów, cała masa zależności, cała masa dependencji, ogrom wiedzy, który trzeba sobie przyswoić, żeby to wszystko ogarnąć, to jest ogrom wiedzy.
Niektóre rzeczy konfiguracyjne konfiguruje się łatwiej, niektóre rzeczy konfiguruje się trudniej. Są rzeczy, które chcielibyśmy, żebyśmy w ramach naszej organizacji konfigurowali w podobny sposób. Jak to zapewnić? Poprzez właśnie tą customizację, czyli jeśli my definiujemy sobie nasze usługi używając AWS CDK, to wtedy jako organizacja mogę dostarczyć taki zespół, który będzie tworzył nasze wewnętrzne biblioteki.
I w tym momencie ja, jako developer w zespole X zamiast zajmować się definiowaniem na przykład ról od podstaw, ja zaciągam biblioteczkę, która ma już pewne role zdefiniowane. Ja zamiast zdefiniować wszystkich szczegółów Lambdy, czyli np. moja lambda jest napisana w TypeSkrypcie, no to muszę zdefiniować, jaki jest runtime environment, czyli np. node 16, node 18 itd. W Pythonie to wiadomo, Python, w przypadku Javy, jakie to jest JDK. Ja takie rzeczy mogę ukryć i mogę stworzyć sobie funkcję wewnętrzną, metodę, klasę działającą na rzecz koło mnie w mojej organizacji, która po prostu mi stworzy taką Javę. Ja w tym momencie się nie przyjmuję jak jest runtime.
Pomaga to w tym, że jeśli jako organizacja przeskoczymy z JDK 11 na 17, ja nie będę musiał zmieniać nic w mojej Lambdzie. To będzie, zmieni się biblioteczka, sobie zaktualizuje biblioteczkę, najnowsza wersja zostanie ściągnięta Mavenem, Gradlem i wszystko będzie działać z automatu. To jest customizacja. W taki sposób nasza organizacja może pomóc developerom, może uprosić ich pracę. Dzięki temu ja nie skupiam się za każdym razem na szczegółach, tych najdrobniejszych takich szczegółach, tylko mogę więcej czasu poświęcić logice biznesowej.
Ma to swój co prawda minus, jeden minus, mianowicie taki, że muszę zapoznać się z tym dodatkowym API naszym wewnętrznym, ale ja uważam, że warto poświęcić na to czas, bo dzięki temu wiele rzeczy zostaje zautomatyzowanych.
Podobnie mamy z build i deployment pipeline’ami, prawda? Ja mogę zdefiniować sobie cały deployment i build pipeline. Build pipeline to jest, powiedzmy, taka lista instrukcji potrzebnych do tego, aby zbudować, skompilować, zbudować moją aplikację. Czyli od kodu źródłowego i wszystkich zasobów do jakiegoś artefaktu. W przypadku Javy będzie to jakiś JAR, np. w przypadku aplikacji Angularowej to tam paczka, którą można zdeployować łatwo. I teraz do tego są potrzebne zależności jakieś, stworzenie tych zależności, zaciągnięcie ich, jakaś budowa, jakieś testy przede wszystkim, sprawdzanie, jakieś golden gate, czyli sprawdzanie, czy nasza aplikacja spełnia pewne kryteria jakościowe, typu statyczna analiza kodu, tak jak mówiłem, testy jednostkowe, może testy integracyjne, czy baza danych działa itd.
Deployment pipeline to jest podobna rzecz jak build pipeline, tylko że deployment pipeline powoduje zdeployowanie, wdrożenie naszej aplikacji na konkretne środowisko. I tutaj ja mogę też od zera wszystko definiować. Ale po co? Moja firma może mi dostarczyć bibliotekę, która daje krok golden gate. Ja w tym momencie już nie muszę definiować, jakie muszą być to role spełnione, jakościowe, żeby moja aplikacja została zbudowana, ponieważ mamy korporacyjne, organizacyjne i jakościowe zasady, prawda? I ja nie mogę zrobić odstępstwa w tym momencie.
To jest standard. Definiowanie, customizacja, definiowanie własnych bibliotek, które upraszcza moją pracę, pomaga mi bardziej skupić się na logice biznesowej w tym momencie, na dostarczeniu wartości dla klienta, to jest standard obecnie i ja się bardzo z tego cieszę, bo to pomaga mi skupić się na innych celach.
I tutaj właśnie jest to rozróżnienie między developerem, a Cloud Engineerem, a DevOpsem. I tu będzie to rozróżnienie, bo jedni będą pomagali po prostu drugim. Wszyscy gramy do tej samej bramki. Dla wszystkich najważniejsze jest, żeby dostarczyć ostatecznie jak najlepszą jakość i jak największą wartość dla naszych klientów, czy dla naszych użytkowników. Tylko że każdy ma przydzielone zadania i skupia się na swoich zadaniach.
Tak, ma to sens. Myślę sobie, że dodałbym jeszcze do tego, że pewnie w przypadku wdrożenia nowych kolegów, nowych koleżanek do zespołu takie standaryzacje też są pomocne, no bo jakoś tam zawężamy czy kierunkujemy te rzeczy, które taki developer musi poznać, żeby móc coś zrobić, a nie mówimy tutaj: zapoznaj się z wieloma usługami AWS, które tak jak powiedziałeś, są olbrzymie, mają mnóstwo opcji, nie wszystkie wykorzystujemy, więc to też pewnie ma taką jeszcze wartość.
Okej, jesteśmy tutaj przy zatrudnianiu, czy też wdrażaniu nowych członków zespołu, to chciałbym pociągnąć ten temat, który wielokrotnie tutaj zaznaczyłeś, że według Ciebie im więcej developer wie o chmurze, tym skuteczniej działa. Chciałbym Cię zapytać, jakie według Ciebie umiejętności chmurowe taki programista powinien znać, żeby też właśnie dały mu jakąś chociażby przewagę na rynku pracy?
Przede wszystkim developer powinien rozumieć, czym jest chmura, i znać te podstawowe koncepty budowy chmury. Czym jest region, czym jest availability zona, w jaki sposób tworzymy rolę, w jaki sposób udostępniamy usługi, w jaki sposób przyznajemy dostępy do usług. To są takie najbardziej podstawowe rzeczy, które budują chmurę, z którymi na co dzień się cały czas współpracuje. Podstawowe koncepty to jest jedna rzecz.
Druga rzecz: fajnie by było, w mojej opinii, jakby developer w ogóle wiedział, dlaczego korzystamy z chmury. Jakie są wady, bo chmura też ma swoje wady, nie ukrywajmy, nie mamy tej kontroli do hardware’u, mimo wszystko, ale też, jakie są zalety, a tych jest według mnie więcej. Jakie są zalety wykorzystania chmury? Dlaczego chmura daje nam przewagę? Czemu developer powinien to wiedzieć, żeby umieć to wykorzystać? Żeby wiedzieć, znać te zalety i wykorzystać je w swojej codziennej pracy.
Ponadto, znajomość podstawowych serwisów. Tu też zależy od tego, z jakim projektem pracujemy. Jeśli ja chmurę potrzebuję do stworzenia takiego backendowego systemu, bez jakiegoś wielkiego UI, do backendowego systemu, do przetwarzania danych, to troszkę inaczej będzie moja architektura wyglądała, niż kiedy ja tworzę jakąś stronę, jakiś serwis, który opiera się na ciągłej interakcji z użytkownikiem. Będzie to troszkę inaczej wyglądać.
Więc uważam, że taki ciągły rozwój, ciągła nauka, ciągłe poznawanie i dostosowywanie tej wiedzy do swoich potrzeb, to jest ta rzecz, do której bym zachęcał wszystkich developerów. Umiejętność pracy z chmurą. A wiesz, co jest też ważne, jest takie powiedzenie, że nie ma oprogramowania wolnego od błędów, jest oprogramowanie niedostatecznie przetestowane. Co za tym idzie? Musimy mieć świadomość, że zawsze może nam wyskoczyć jakiś błąd, zawsze może mieć jakiś problem, coś się może stać i teraz inwestygacja tego problemu, inwestygacja tego błędu, znajdowanie tego root cause, potem stworzenie poprawki. Dobrze jest, jak developer orientuje się mniej więcej w tym środowisku, żeby wiedzieć, gdzie mam logi, gdzie mogę znaleźć jakieś metryki, gdzie mogę znaleźć performansowe jakieś wykresy i sprawdzić, co nie działa.
Więc to nie jest tylko kwestia optymalnego korzystania z zasobów, ale też kwestia naprawienia błędów, rozwiązania poszczególnych problemów, incydentów. Im krótszy czas reakcji, tym lepiej. Zawsze tak było i zawsze tak będzie.
No tak, im większa wiedza jak to działa pod spodem, tym szybciej jesteśmy w stanie znaleźć właśnie tę przyczynę błędu. Tak jak powiedziałeś, nie ma oprogramowania bez błędu. Robimy je albo świadomie, albo nieświadomie. Jak gdyby na koniec dnia nie ma to pewnie znaczenia. Jakie najczęstsze błędy Ty obserwujesz u developerów, którzy właśnie pracują z AWS-em? Czy masz jakieś porady jak tego typu błędów unikać?
To jest temat rzeka tak naprawdę. Przede wszystkim to jest temat rzeka, ale to są takie bardziej developerskie błędy lub błędy projektowe. Takie pierwsza rzecz, która mi przychodzi na myśl, to jest nieoptymalne wykorzystanie zasobów albo używanie serwisów, których nie potrzebujemy tak naprawdę. Ja na to mówię strzelanie z armaty do komara.
Mężczyzna najlepiej wygląda w garniturze uszytym na miarę, prawda? W koszuli uszytej na miarę. Mówię o tym, bo ja jestem facetem, więc na tym się najbardziej znam. Kobieta najlepiej wygląda w sukience dostosowanej, dopasowanej, też uszytej na miarę. Tak samo oprogramowanie działa, wiem, że to banalne porównanie, ale tak samo oprogramowanie działa, kiedy jest skrojone na miarę naszych potrzeb. Ono działa wtedy najlepiej. Czyli to pierwsza rzecz, nieoptymalne wykorzystanie zasobów.
Ja czasami widzę, jak ludzie wykorzystują serwis EC2, czy tworzą sobie wirtualne maszynki, tak po naszemu, może troszkę inaczej powiem, walą na to mikroserwisy i to stoi przez 3/4 dnia nieużywane. A korzystamy, mamy tam przydzieloną przestrzeń pamięciową, za którą płacimy, czy serwis jest uruchomiony, maszyna jest uruchomiona, za to płacimy itd. A nie lepiej w tym momencie zrobić Lambdę? Funkcję Lambda, za którą będziemy płacili tylko wtedy, jak ona będzie działała, będzie wykonywała swoje zadanie. Kiedy ono zostanie wywołane, tylko wtedy zapłacimy za nią.
Innym przykładem jest też dobieranie nieodpowiednich narzędzi do tego, co chcemy zrobić. Ja trochę spędziłem czasu nad pisaniem funkcji Lambda. Pisałem funkcję Lambda w Javie, pisałem w Pythonie, pisałem w TypeScript. Z funkcjami Lambda jest ten problem, że one nie są cały czas w gotowości, nie są cały czas rozgrzane. Mówimy na to rozgrzane, warmed up. Kiedy ja chcę wywołać funkcję Lambda, to dopiero wtedy ona jest deployowana na jakiś taki ad hoc serwerek, wtedy jest rozgrzana, ten serwerek działa i mówimy, że ona jest rozgrzana.
I mamy coś takiego jak cold start. Cold start to jest ten czas potrzebny od mojego wywołania tej funkcji Lambda, aż do jej zdeployowania, uruchomienia, tam wszystko wewnętrznie się dzieje, ja nie mam na to wpływu, to mamy cold start, czyli ten czas potrzebny na to wszystko. W przypadku Javy, a jeszcze jak napiszemy taką Lambdę z wykorzystaniem Spring Boota, to ten czas to jest 10, 20 sekund, prawda? Jeszcze jak do tego mam podpiętą jakąś mini bazę danych, to trzeba to wszystko spiąć.
Natomiast w przypadku TypeScripta, w przypadku Pythona te czasy na cold starcie to jest kwestia dwóch sekund, trzech sekund, może pięciuset milisekund, no zależy, co zrobiliśmy. Czy to znaczy, że Java nie nadaje się do pisania Lambd? Nieprawda. Java nadaje się świetnie według różnych testów. Java nadaje się świetnie do pisania Lambd, kiedy mamy ogromny throughput, bo Lambda jest rozgrzana i tam będzie rozgrzana po wykorzystaniu, będzie, powiedzmy, jeszcze dwie minuty rozgrzana.
Możemy też trochę skonfigurować, żeby była np. do 15 minut rozgrzana, czyli gotowa do ponownego użycia. I teraz, kiedy mamy ogromny throughput, wielowątkowe rzeczy, po prostu ogromne dane do przetwarzania, Java najlepiej sobie wyjątkowo radzi z takim przetwarzaniem, w porównaniu do TypeScripta i Pythona. Akurat w przypadku środowisk chmurowych, mówię tylko o tym, na podstawie badań, na podstawie różnych tam wykresów performance’owych itd. Więc Java świetnie działa.
Kolejny przykład. Mam zadanie kronowe. Co dzień o północy generuję sobie jakieś raporty, wysyłam maile. I teraz mój zespół pisał mikroserwisy, pisał Java, nie zna TypeScripta, nie zna Pythona, nie zna JavaScriptu. I co? I teraz ja mam kazać im się uczyć nowego języka, kompletnie nowego języka, po to, żeby napisali mi funkcję? No nie, bo czy o 12, o północy, kronowe zadanie, które wysyła raporty, czy tam jest naprawdę różnica, czy ten wystartuje po dwóch sekundach, czy po dziesięciu sekundach? No nie ma. Więc mierzmy nasze siły na zamiary i starajmy się tak racjonalnie do tego podejść. Nie wynajdować koła na nowo.
To też kolejna rzecz. Widziałem takie mikroserwisy, widziałem funkcje Lambda, które próbują udawać inne serwisy, już takie natywne usługi AWS-owe. Starajmy się tego unikać i tu właśnie znajomość chmury, znajomość rozwiązań pomoże nam np. unikać tego błędu.
Ja czasami widzę, jak ludzie wykorzystują serwis EC2, czy tworzą sobie wirtualne maszynki, tak po naszemu, może troszkę inaczej powiem, walą na to mikroserwisy i to stoi przez 3/4 dnia nieużywane. A korzystamy, mamy tam przydzieloną przestrzeń pamięciową, za którą płacimy, czy serwis jest uruchomiony, maszyna jest uruchomiona, za to płacimy itd. A nie lepiej w tym momencie zrobić Lambdę? Funkcję Lambda, za którą będziemy płacili tylko wtedy, jak ona będzie działała, będzie wykonywała swoje zadanie. Kiedy ono zostanie wywołane, tylko wtedy zapłacimy za nią.
Jestem ciekaw, jak Ty widzisz tę rolę developera w przyszłości, właśnie w kontekście rozwiązań chmurowych. Czy tam będzie nam dochodziło jeszcze tych odpowiedzialności, tej wiedzy koniecznej, żeby się poruszać w tym środowisku? Może nie, może wręcz korzystając z coraz wyższych abstrakcji, tak naprawdę będzie to jeszcze przyjemniejsze, jeszcze łatwiejsze, jak na tę przyszłość patrzysz?
Po pierwsze, ktoś tę abstrakcję będzie musiał tworzyć. Czyli ktoś musi znać te chmury od podszewki, żeby tworzyć te abstrakcje, żeby dostarczyć te skustomizowane pod nasze rozwiązania biblioteki, po to, żeby upraszczać życie developerowi. Ktoś to musi po prostu wiedzieć, znać, umieć, użyć itd. Więc tacy specjaliści od chmur będą zawsze potrzebni. Tym bardziej że od chmury nie uciekniemy, jak już wcześniej mówiłem. Będą zawsze potrzebni.
Co do samej roli developera. Ja myślę, to się chyba zawsze sprawdza, że im większa wiedza, im więcej umiejętności ma developer, im bardziej elastyczny jest inżynier, tym będzie, łatwiej będzie znaleźć pracę, że tak powiem. Łatwiej będzie znaleźć tę pracę, utrzymać pracę. Myślę, że im więcej developer jest w stanie sam sobie ogarnąć, tym jego wartość na rynku pracy będzie większa. I jedyne, na co zwróciłbym uwagę, to to, że być może developer, który nie zna chmur, już powoli odejdzie do lamusa. Powoli będziemy coraz mniej znajdowali zajęcia dla takiego developera, ponieważ przy takim podejściu zawsze będzie musiał być ktoś drugi, ktoś trzeci, kto będzie wspomagał tego developera.
Owszem, chcę cały czas podkreślić, że zespoły wspomagające, supportujące, Cloud Engineerowie, DevOpsi itd., oni będą potrzebni, tylko to będzie bardzo wyspecjalizowana, bardzo głęboka wiedza. Natomiast chodzi o to, żeby developer nie musiał za każdym razem wołać tego Cloud Engineera, tego DevOpsa, tylko będzie mógł sam sobie poogarniać wszystko dookoła siebie, a w trudnych przypadkach będzie mógł zasięgnąć pomocy, porady.
Natomiast developer, który nic kompletnie nie umie z chmurą, jak trafia do środowiska chmurowego, to po prostu jakby trafił na inną planetę. Tak, jest to już duży ekosystem, zróżnicowany, przebogaty. Myślę, że po prostu developerzy nie unikną poznania chmury. Tyle.
To co byś doradził tym osobom, które dzisiaj zainspirowałeś do tego, żeby albo rozpocząć tę przygodę poznawania chmury, albo wejść głębiej? Od czego mogłyby te osoby zacząć? Może skupmy się na chmurze AWS-a, bo tutaj jak gdyby na kanwie tej chmury sobie rozmawiamy. Od jakich obszarów warto zacząć jej zgłębianie?
Przede wszystkim poznać wady, zalety, tak jak wcześniej powiedziałem, wady, zalety chmury – zrozumieć zalety, żeby umieć jak najlepiej z niej korzystać. Po drugie, zrozumieć podstawowe koncepty chmury, w ogóle przetwarzania, rozproszonego przetwarzania w chmurze, a następnie powolutku, krok po kroku zapoznawać się z tym, co chmura nam oferuje.
Nie trzeba, oczywiście można, ale nie zawsze trzeba płacić za jakieś wyspecjalizowane szkolenia, Jest pełno materiałów dostępnych w sieci. Chociażby dokumentacja AWS-owa jest przebogata. Jakby to wydrukować, to byśmy mieli otwartą drogę stąd na księżyc chyba. Bardzo dużo materiałów, bardzo dużo przykładów jest na stronach AWS-a. Są tutoriale darmowe, są blogi, są podcasty, są vlogi na YouTubie i na innych mediach. Jest cała masa materiału, po prostu trzeba tylko chcieć, znaleźć odrobinę jakiegoś samozaparcia i się uczyć.
Właśnie, trzeba chcieć. Myślę, że możemy do tej listy też dodać TechToki, m.in. Capgemini TechTok. Już w czerwcu będzie okazja, żeby się z Bartkiem spotkać, porozmawiać o tych i innych tematach, zainspirować bardziej. Być może Bartek będzie w stanie pokierować jeszcze te osoby, które czują się nieco zagubione w tym temacie, więc przypominam dla tych wszystkich osób, że w notacji do odcinka można znaleźć link do zapisu właśnie na tego TechToka.
Bartku, ja Tobie bardzo dziękuję za dzisiejsze spotkanie.
Również dziękuję. Dziękuję wszystkim za słuchanie naszych przemyśleń.
Myślę, że to była wartościowa rozmowa. Powiedz jeszcze na koniec, gdzie Cię można znaleźć w internecie, gdzie możemy słuchaczy odesłać.
Na mojej stronie, na moim profilu na LinkedInie, resztę mediów społecznościowych staram się trzymać do bardziej prywatnych relacji, ale na LinkedInie może dla mnie każdy może mnie złapać spokojnie.
Super. Oczywiście link standardowo znajdziecie w notatce do odcinka. Jeszcze raz Ci, Bartku, bardzo dziękuję.
Do usłyszenia i cześć!
Do usłyszenia.
I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media.
Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o roli developera w rozwoju i utrzymaniu rozwiązań chmurowych na przykładzie AWS.
Do usłyszenia w następnym odcinku. Cześć!