Rynek IT ciągle się zmienia. Czasem mam wrażenie, że za szybko. Zawsze żyję w obawie, że gdybym wyjechał na roczny urlop -- po powrocie zastałbym całkiem inny świat, do którego musiałbym równać, aby znaczyć cokolwiek na tym rynku. Cóż, chyba takie realia zawodu programisty. Ciągle gonimy za nowościami by nie przespać chwili, która będzie decydująca dla naszej kariery.
Konteneryzacja w moim mniemaniu była tą chwilą, którą przespałem. Pamiętam, jak kilka lat temu ze wszystkich stron słyszałem jaką obiecującą technologią był Docker. Uznałem wtedy jak zwykle, że to kolejna fanaberia świata IT, którą mogę pominąć -- moda, która umrze tak szybko jak się pojawiła. Gdybym wiedział, w jakim błędzie wtedy byłem…
Minęło kilka lat, ja ciągle klepałem kod w Javie, myśląc, że umiem już wszystko, a przynajmniej na tyle dużo, aby uznać siebie za senior developera -- wszak mijało mi wtedy 6 lat zawodowego programowania w Javie. Pamiętam to bardzo dobrze -- kolega oznajmił mi, że postawił na Dockerze swoje środowisko developerskie by móc łatwiej tworzyć swoje oprogramowanie. Wtedy uznałem to jako ciekawostkę, którą warto przynajmniej sprawdzić czy faktycznie jest coś warta. Zgrało się to jednocześnie z momentem, gdy nowy projekt, w którym miałem okazję pracować, wymagał konteneryzacji (jeden z wymogów wdrożeniowych). To była jedna z przełomowych chwil w moim życiu IT. Coś, co otworzyło mi oczy i pokazało, że granice w świecie IT sięgają dalej niż mi się wydaje.
Zacznijmy jednak od początku. Jakiś czas temu mądrzy ludzie zaczęli robić swoje programy w architekturze mikroserwisów. Szybko okazało się, że ten trend na dobre zadomowił się w standardach wytwarzania oprogramowania. Dekompozycja funkcjonalna na wiele mniejszych serwisów przynosi w zasadzie same korzyści. Mikroserwisy są spójne koncepcyjnie. To małe projekty, które łatwiej utrzymać. Każdy serwis komunikuje się z innym, by jako całość stworzyć dla użytkownika końcowego całkiem sprawnie działający system. Takie cegiełki łatwo wymieniać na inne, jeśli okaże się, że klient nagle zmieni zdanie (skąd my to znamy!). Awaria jednego elementu nie musi oznaczać awarii całego systemu -- a jedynie jednej z wielu jego funkcjonalności. Dodatkowo mikroserwisy bardzo dobrze się skalują. Jeśli masz problemy z wydajnością -- wystarczy czasem powielić instancję kluczowych elementów, aby równolegle pracując udźwignąć nadmierny ruch. Brzmi świetnie -- i faktycznie tak jest.
Wspomniany przeze mnie Docker jest technologią, która daje bardzo wiele możliwości. Również w zakresie o którym wspomniałem. Czym on właściwie jest? Jest technologią wirtualizacji tj. uruchamiania jakiegoś serwisu w kontenerze, ale bez konieczności emulowania całej warstwy sprzętowej i systemu operacyjnego. Jeśli znamy starego i poczciwego VirtualBox’a to efekt w zasadzie jest podobny -- mamy uruchomione procesy w oddzielnym autonomicznym, odseparowanym obrazie -- ale z tą różnicą, że w przypadku dockera obraz ten nie zawiera w sobie własnego systemu operacyjnego a “pożycza” z naszego komputera. Kontener waży więc bardzo mało i zużywa bardzo mało zasobów. Dodatkowo robi to na tyle mądrze, że uruchomiony kontener jest odizolowany od naszego systemu i nie jest w stanie wyrządzić mu krzywdy. Mamy oczywiście w każdej chwili możliwość modyfikacji, startu, zatrzymania, usunięcia dockera -- kiedy nam się to podoba. Efekt jest taki, że nie ma żadnego problemu, aby uruchomić 20 kontenerów na jednym średniej klasy komputerze (baza danych, kilka serwisów backendowych, frontend, monitoring, itp…). Fajne? Pewnie! A czy dalibyście radę uruchomić 5 VirtualBoxów na własnej maszynie? Szybko by się skończył RAM, nie mówiąc ile te 5 obrazów zajmowałoby miejsca na dysku. W dockerze kontener waży niewiele więcej niż sama aplikacja. Podobnie jeśli chodzi o zużycie RAM. Przecież to jest tak piękne i stwarza tyle możliwości, że musiało zrewolucjonizować świat. I tak się stało!
Nastała era konteneryzacji. Docker stał się standardem. Wiele firm zamawia oprogramowanie, które się konteneryzuje -- a więc w łatwy sposób można tą cegiełkę wrzucić na swoje środowisko i zmusić do pracy. Ciężko obecnie spotkać jakąś poważną firmę, która nie korzysta z podobnych rozwiązań. A jeśli taka się jeszcze uchowała -- to zatrzymała się w średniowieczu IT.
Chcesz zgłębić wiedzę na ten temat? Wyszukaj szczegółowe informacje na temat docker, docker-compose i docker swarm.
Czas płynął dalej, a systemy składające się wyłącznie z dockerów stały się dość ciężkie w utrzymaniu. Pracujących kontenerów duże systemy potrafią mieć setki, tysiące. Pojawił się problem -- jak tym wszystkim zarządzać, obsługiwać, automatyzować, wznawiać, skalować itp. Wtedy pojawiła się firma Google, która wjechała na białym koniu ze swoim Kubernetesem. Z perspektywy czasu stwierdzam, że zrobili kawał dobrej roboty. Brawa należą się tutaj również polskim pracownikom Googla, którzy do dziś maczają swoje palce w tym projekcie.
Kubernetes jest czymś, co nie miał docker bądź docker-compose -- łatwość praktycznie dowolnego skalowania kontenerów, obsługa failoverów, automatycznej konfiguracji na dowolnej liczbie komputerów (klastrze). Kubernetes -- nazwa tak długa, że cały świat nazywa go k8s (k, potem 8 jakichś liter, na końcu s). Najprościej mówiąc -- k8s ustandaryzował sposób zarządzania kontenerami docker’a (w zasadzie k8s nie tylko obsługuje same dockery, ale nie o tym ten artykuł). Klaster k8s składający się z wielu maszyn sam zajmuje się decydowaniem -- gdzie postawić dany kontener (w nomenklaturze k8s nazywany jest jako pod), jak bardzo powinien być zreplikowany w systemie, co zrobić, gdy któryś pod przestanie działać, jak zapewnić komunikację jednego poda z drugim, które adresy/porty naszej aplikacji powinny być wystawione na świat i wiele wiele innych. Wszystko to konfigurowane jest za pomocą plików yml w zwartej i przystępnej formie. Na tyle przystępnej, że większość systemów takich jak Jenkins, Gitlab mają wbudowaną jego obsługę! Wielokrotnie widziałem wielkie firmy (telekomy, banki), które całe środowiska stawiają właśnie na kubernetesie. Jest to wygodne, ustandaryzowane, odporne na awarie rozwiązanie. Jest to też ukłon w kierunku programistów, którzy nie muszą mieć wiedzy administratorskiej, aby deployować swoje oprogramowanie. Developer pisze opis deploymentu na k8s w postaci pliku yml i gotowe -- aplikacja uruchamia się na klastrze. k8s sam uruchamia poda, nadaje mu adres IP, wystawia odpowiednie porty na świat, zapewnia łączność z innymi podami. Nasz program jest gotowy do działania w środowisku kubernetesa.
Jak monitorować działanie naszych aplikacji? k8s dostarcza swoje CLI, dzięki któremu mamy dostęp do wszystkich możliwości klastra. Dla ludzi lubiących klikać -- można wystawić interfejs webowy, który dostarcza podstawowe funkcjonalności poprzez zwykłą przeglądarkę komputerową.
Chcesz zgłębić wiedzę na ten temat? Wyszukaj szczegółowe informacje na temat Kubernetes, Ingress.
Czas płynął dalej, świat oszalał na punkcie technologii chmurowych. Jeśli przespaliście ten moment -- jest to ostatni dzwonek, aby załapać się na odjeżdżający pociąg! Szacuje się, że za kilka lat ponad 50% stanowisk w IT związane będzie z chmurami. Wszystkie usługi za chwilę będziemy mogli sobie wyklikać zamiast ręcznie stawiać je na fizycznych maszynach w firmowych serwerowniach. Szykuje się nam wielka rewolucja -- jakiej nie widział nikt! Chmury dostosowują się do potrzeb klienta. Zarówno Amazon Web Services, Microsoft Azure, Google Cloud Platform, Oracle Cloud, Alibaba Cloud (i wiele innych) zaproponowali swoje rozwiązania w kwestii konteneryzacji.
To na barki infrastruktury providerów chmurowych powierzamy dostosowanie zasobów, aby udało się uruchomić nasz rozproszony system. Nas nie interesują już obsługi, zakupy, awarie potrzebnego sprzętu serwerowego, prąd, licencje. Płacimy jedną stałą stawkę za użyte zasoby i niczym innym się nie przejmujemy. To chmura ma poradzić sobie ze wszystkimi problemami tak, abyśmy tego nie odczuli. Widziałem wdrożenia, kiedy to jedna z firm potrzebowała przeliczyć duże dane w krótkim czasie. Rozwiązaniem okazało się postawienie kilku tysięcy kontenerów i uruchomienie w ten sposób równoległych obliczeń na produkcji. Zostało to zwyczajnie wyklikane u jednego z providerów chmurowych. Maszyny oczywiście zrobiły swoje, pieniądze zarobione, a po wszystkim usunięto wszystkie pody, by nie płacić więcej za użyte zasoby. Piękne! Elastyczne! Tanie! Właśnie dlatego warto uczyć się chmur! Wiele z nich umożliwia darmowe okresy próbne. Spróbuj i Ty!
Chcesz zgłębić wiedzę na ten temat? Wyszukaj szczegółowe informacje na temat:
- Google GKE -- Google Kubernetes Engine
- AWS EKS -- Amazon Elastic Container Service for Kubernetes
- Azure AKS -- Azure Kubernetes Service
Programista -- brzmi dumnie. Zarabiamy tak dużo pieniędzy, że czasem zapominamy skąd one się biorą. A przecież potrafimy stworzyć swoiste cuda, które przetwarzają olbrzymie ilości informacji wielokrotnie szybciej niż mógłby to ręcznie zrobić człowiek. Potrafimy automatyzować wiele procesów, by polepszyć jakość pracy i życia przeciętnego człowieka. Należy jednak pamiętać, że nasza praca wymaga ciągłej nauki nowych technologii, ciągłej pogoni za nowymi trendami i rozwiązaniami. Sama znajomość języka programowania jest oczywiście ważna, ale nasze oprogramowanie przecież na czymś musi być uruchamiane. Nie zapomnijcie o tym!
Chcesz dowiedzieć się więcej na szkoleniach? Sprawdź poniższe odnośniki:
