To jest 133. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o Kubernetes

Przypominam, że w poprzednim odcinku rozmawiałem o trendach na rynku pracy IT w 2022 roku.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/133. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Jednocześnie bardzo dziękuję moim obecnym patronom. 

A teraz życzę Ci już miłego słuchania. 

Odpalamy! 

 

Cześć! Dziś moimi gośćmi są Maciek Kuźniar, pomysłodawca, główny architekt i CEO polskiej chmury obliczeniowej Oktawave, od 2003 roku związany z K2 Internet S.A., gdzie odpowiadał za rozwój i utrzymanie infrastruktury IT i współtworzył biznesowy sukces działu zajmującego się hostingiem zaawansowanych systemów IT dla kluczowych klientów. Autor koncepcji technologicznie wspierających rozwój biznesu oraz rozwiązań architektonicznych, gwarantujących wysoką dostępność i spełniających rygorystyczne wymogi serwisowe.  

Drugim gościem jest dzisiaj Zbyszek Kamiński, Cloud Masters & Premium Support Director Oktawave. Z chmurą Oktawave związany od 9 lat, a w branży IT od 1999 roku – piękny wynik! Zarządza zespołami Premium Support i Cloud Masters, wyspecjalizowanymi w analizie, optymalizacji, migracji i utrzymaniu systemów IT w chmurze. Odpowiada za wsparcie dużych portali internetowych – tui.pl, pracuj.pl czy serwisów grupy Edipresse – w trakcie i po migracji do chmury. Doradza w zakresie optymalnego zarządzania chmurą prywatną, publiczną, hybrydową oraz środowiskami multi-cloud. Pomaga skorzystać z rozwiązań globalnych dostawców, takich jak AWS, Azure, JCP. 

Maciek, Zbyszek, bardzo miło mi Was gościć w podcaście!

 

Maciek Kuźniar: Dziękujemy, nam też jest bardzo miło!

 

Zbyszek Kamiński: Cześć, Krzyśku! Dzień dobry wszystkim! 

 

Z Maćkiem i Zbyszkiem będę chciał dzisiaj porozmawiać o bardzo gorącym, można powiedzieć temacie, o którym się dużo słyszy w świecie cloud ostatnio, czyli o Kubernetes. 

Chciałem natomiast rozpocząć od takiego standardowego punktu każdego mojego podcastu, czyli pytania do gości – czy słuchacie podcastów, jeśli tak, to może macie jakieś swoje ulubione audycje? 

 

M.K.: Wiesz co, słuchamy. Czasem rzadziej, czasem częściej. Ja osobiście czasami słucham takich technologicznych podcastów, Zbyszek pewnie podobnie, choćby Niebezpiecznika, ale słucham też takich podcastów lifestylowych, np. popularnego pewnie dzisiaj Filipkowskiego z Zaprojektuj swoje życie, to naprawdę fajny podcast. I rzeczywiście czasami siedząc w samochodzie, wracając do domu, przesłuchuję sobie te podcasty Filipkowskiego, niektóre są naprawdę bardzo fajne. 

 

Z.K.: Ja podobnie, tak jak Maciek powiedział. Rzeczywiście będąc blisko świata technologicznego, te podcasty technologiczne bardzo pomagają w zapoznaniu się z technologią, nowinkami technologicznymi itd., niekoniecznie specjalnie rezerwując sobie czas na tę naukę, możesz po prostu słuchać w dowolnym momencie. 

Natomiast jeśli chodzi o coś poza technologicznymi rzeczami… My jesteśmy taką rodziną parkolubną, tak to nazywamy. To znaczy generalnie jesteśmy zakręceni z żoną i córką na parki rozrywki typu Disneyland, Warner Bros w Madrycie itd. Korzystamy więc również z takich podcastów, dlatego że tam najwięcej można się dowiedzieć o jakichś nowinkach, o nowych atrakcjach, o nowej formie zakupu biletów itd. Jest to więc bardzo przydatne. 

 

M.K.: Z tego się nigdy nie wyrasta chyba!

 

Z.K.: Podobno nie! Warto zawsze być dzieckiem.

 

Dokładnie, nigdy nie zaszkodzi trochę takiej fantazji i jednocześnie takiego odpuszczenia tematów i niezastanawiania się co będzie jutro, pewnie! Ale to jest inny temat.

Dzisiaj mamy bardziej techniczną rzecz do przedyskutowania. Chciałbym zapytać o Wasze doświadczenia związane  z Kubernetes. Właśnie! Lepiej mówić kubernetes, kiubernetis – jak jest poprawnie według waszej wiedzy?

 

Z.K.: Ja kiedyś robiłem takie dochodzenie, dlatego, że sam używałem chyba wszystkich form, o których powiedziałeś, a jest ich jeszcze więcej, i to, co mi się udało znaleźć i staram się w sobie wyrobić taki nawyk, to mówienie kubernetis. 

 

Kubernetis, świetnie. Brzmi bardzo dobrze. 

To zacznijmy może od początku – czym ten Kubernetes jest, jak powstał, kto go stworzył, na jakie problemy właściwie odpowiada i dlaczego się o tym temacie teraz całkiem sporo mówi? 

 

M.K.: Wiesz co, to jest bardzo ciekawa historia. Zbyszek, byłem pierwszy.

 

Z.K.: Dobrze, proszę bardzo Maćku.

 

M.K.: Pierwowzorem dla Kubernetesa był system, który powstał w Google, system ten nazywa się Borg – nawiązanie do Star Treka. To jest taki system, którego celem było zarządzanie właściwie całą infrastrukturą i wszystkimi zasobami w Google, i próba odpowiedzenia na problem polegający na tym, że setki czy dziesiątki tysięcy inżynierów mają potrzebę skorzystania z zasobów, te zasoby są umieszczone w różnych fizycznych lokalizacjach, w różnych miejscach. Trzeba było więc zbudować jakąś taką warstwę abstrakcji, taką jedną wielką maszynerię, która się właściwie nigdy nie psuje i która ma nieograniczoną ilość zasobów do dyspozycji w każdym momencie. I to był Borg. Borg do dzisiaj istnieje, zarządza chyba wszystkimi centrami danych w Google, jest cały czas rozwijany. Taka ciekawostka – rozwijany jest przez warszawski oddział Google, inżynierowie w Polsce pracują nad Borgiem. 

U podstaw Kubernetesa leży taka sama intencja, taki sam cel, jak leżał u podstaw Borga, mianowicie zbudowanie systemu, który stanowi taką jedną wielką maszynę, tylko że tym razem zbudowaną w ekosystemie kontenerów. Maszynę pozwalającą zarządzać nie tyle infrastrukturą taką fizyczną w centrali danych, ile pozwalającą zarządzać kontenerami, i upraszczać procesy, które są z zarządzaniem tymi kontenerami powiązane. 

Dzisiaj jest chyba 7 lat od wydania Kubernetesa, to gdzieś w 2014 roku się wydarzyło. Można powiedzieć, że ta platforma jest naprawdę dojrzała, zyskuje niezwykłe tempo rozwoju, bardzo wiele firm z tego korzysta. Czym właściwie jest Kubernetes? Kubernetes to platforma do zarządzania, do skalowania, do automatyzacji wszystkich aplikacji kontenerowych, tak bym to nazwał. Czyli jeśli chcemy stworzyć aplikację i zapakować ją w kontener, to być może dobrym pomysłem będzie umieścić ją w Kubernetesie. 

 

U podstaw Kubernetesa leży taka sama intencja, taki sam cel, jak leżał u podstaw Borga, mianowicie zbudowanie systemu, który stanowi taką jedną wielką maszynę, tylko że tym razem zbudowaną w ekosystemie kontenerów. Maszynę pozwalającą zarządzać nie tyle infrastrukturą taką fizyczną w centrali danych, ile pozwalającą zarządzać kontenerami, i upraszczać procesy, które są z zarządzaniem tymi kontenerami powiązane.

Zapewne wielu słuchaczy ma do czynienia, chociażby developersko pracując na co dzień z Dockerem. 

I chciałbym teraz Was zapytać, czym właściwie się różni Kubernetes od Dockera? Dlaczego potrzebujemy dwa systemy związane z konteneryzacją, czy nie wystarczy nam tylko jedno rozwiązanie? 

 

Z.K.: To może teraz ja spróbuję wyjść pierwszy, Maćku. 

Generalnie rzeczywiście bardzo często te zwroty, ta terminologia się przecina. To znaczy bardzo często mówiąc o Kubernetesie, mówimy również o Dockerze. Sam Docker to jest ogólnie technologia i forma pliku kontenera. Docker służy do automatyzowania, wdrażania aplikacji, tworząc takie samowystarczalne kontenery. Dlatego chcąc mówić bardziej precyzyjnie, jeżeli robimy porównanie pomiędzy Kubernetesem a Dockerem, powinniśmy porównywać Kubernetesa i Docker Swarma. Bo tak naprawdę w tym przypadku oba narzędzia są właśnie orkiestratorami, którzy służą do zarządzania np. obrazami utworzonymi w tej danej technologii. 

I teraz jeżeli mielibyśmy to porównać w taki sposób najbardziej przystępny, tak mi się wydaje, to taką jedną z największych różnic jest to, że Kubernetes pozwala na klastrowanie kontenerów platformy Docker. Docker Swarm działa na trochę innej zasadzie, natomiast w momencie, w którym myślimy o zbudowaniu środowiska, które będzie właśnie i odporne na awarie, i skalowalne, i pomoże nam w ogarnięciu tego naszego świata aplikacyjnego, to właśnie tu z pomocą przychodzi przede wszystkim platforma Kubernetes. Jest ona w moim odczuciu platformą po prostu bardziej złożoną od rozwiązania Docker Swarm. Z mojej perspektywy Docker Swarm bardziej pomaga w ogarnięciu takich jednostkowych projektów związanych z całą konteneryzacją, a Kubernetes jest już do zastosowań o skali zdecydowanie większej. 

Myślę, że też to, co warto powiedzieć, już może poza samym porównaniem, to jest to, że Kubernetes nie musi być od razu wyciągany na początku naszej drogi do technologii kontenerowej. Tak naprawdę wiele projektów jesteśmy w stanie opracować, przygotować, uruchomić z wykorzystaniem po prostu obrazów właśnie dockerowych. Natomiast przy większych zastosowaniach, zdecydowanie polecałbym już skręcenie w stronę właśnie Kubernetesa. 

M.K.: Wiecie co, to jeszcze jedna uwaga z mojej strony. Tak naprawdę Docker i Kubernetes to są dwie różne rzeczy. Można to sobie wyobrazić w ten sposób, że mamy taki gigantyczny statek transatlantyk, który płynie, i na tym transatlantyku są tysiące kontenerów poupychane. Kontenery na tym transatlantyku to są obrazy dockerowe. A transatlantyk to jest Kubernetes. 

 

Kubernetes jest takim miejscem, w którym można uruchomić te wszystkie kontenery zbudowane za pomocą Dockera, czyli to są kontenery dockerowe. Mogą być też inne, ale zwykle używa się kontenerów dockerowych. W tych kontenerach, w tym obrazie dockerowym jest aplikacja, którą Kubernetes zarządza. Aplikacja może się składać z wielu takich obrazów, zwykle to nie jest jeden obraz, zwykle jest ich kilka/kilkanaście, za chwilę będziemy o tym pewnie więcej mówić. Na Kubernetes trzeba patrzeć jako na platformę, a Docker jest komponentem tej platformy.

 

Kubernetes jest takim miejscem, w którym można uruchomić te wszystkie kontenery zbudowane za pomocą Dockera, czyli to są kontenery dockerowe. Mogą być też inne, ale zwykle używa się kontenerów dockerowych. W tych kontenerach, w tym obrazie dockerowym jest aplikacja, którą Kubernetes zarządza. Aplikacja może się składać z wielu takich obrazów, zwykle to nie jest jeden obraz, zwykle jest ich kilka/kilkanaście, za chwilę będziemy o tym pewnie więcej mówić. Na Kubernetes trzeba patrzeć jako na platformę, a Docker jest komponentem tej platformy.

 

Rozumiem. Myślę, że to jest bardzo obrazowe pokazanie faktycznie różnic i cieszę się, że to Maciek sprostowałeś, żebyśmy nie porównywali jabłek z gruszkami, bo to faktycznie są dwie różne rzeczy. 

Mówiliście wcześniej, że automatyzacja jest jednym z benefitów, który może wynikać z zastosowania Kubernetesa. Skoro automatyzujemy, to przede wszystkim chciałbym Was zapytać o to, co automatyzujemy w przypadku Kubernetesa i jakie benefity zyskujemy dzięki wprowadzeniu takiej automatyzacji, jak tym zarządzamy?

 

M.K.: Ja nie wiem, czy to jest dobre pytanie, czy można zapytać co automatyzujemy w przypadku Kubernetesa. Zróbmy krok wstecz – co właściwie automatyzujemy dzisiaj w IT? Dzisiaj w IT automatyzujemy procesy. I teraz jakie to mogą być procesy w IT? Pewnie jest ich szereg, ale taki, który przychodzi nam od razu na myśl, to jest automatyzacja procesu związanego z wytwarzaniem aplikacji. Piszemy aplikację, potem jak ją już napiszemy, to ją testujemy, jak ją przetestujemy, to uruchamiamy w systemie produkcyjnym, a jak ją w tym środowisku produkcyjnym uruchomimy, to za chwilę mamy poprawki do tej aplikacji, nowe wersje – to jest proces. 

Kubernetes jest narzędziem do automatyzacji. Automatyzować możemy m.in. procesy i dobrym przykładem procesu, który możemy zautomatyzować, jest właśnie proces wytwarzania aplikacji. I tu mówimy np. o takich zjawiskach jak CI/CD, czyli Continuous Integration/Continuous Development, które to terminy – za chwilę będziemy o nich więcej mówić – są już terminami, które mają już istotne znaczenie w świecie Kubernetesa. Natomiast wracając jeszcze do pytania, to chyba raczej nie da się – Zbyszek, co ty na to? – automatyzować samej aplikacji. Automatyzować możemy proces.

 

Z.K.: Oczywiście, automatyzujemy zdecydowanie proces dostarczania czy integracji itd., natomiast ja bym jeszcze troszkę inaczej powiedział. Bo dzisiejsze czasy właściwie wymuszają – a ta technologia w tym po prostu pomaga – żebyśmy automatyzowali wszytko, co jest możliwe. To znaczy generalnie zarówno po tej stronie pracy developerskiej… Chociaż developerskiej może mniej, chciałbym powiedzieć o tej stronie bardziej opsowej generalnie, czyli taka zasada, że jeżeli robisz coś po raz kolejny, po raz drugi, trzeci, czwarty, to znaczy, że można to zautomatyzować. 

Środowiska związane z kontenerami, aplikacje uruchamiane w formie mikroserwisów – ta technologia pomaga nam w tym, żebyśmy większość procesów, o których wspomniał Maciek, procesów związanych z dostarczaniem, zarządzaniem, utrzymywaniem naszej aplikacji i środowiska, na którym ta aplikacja działa, po prostu automatyzowali. 

Tak właśnie rozmawiam również z klientami, i u nas w zespole tak do tego podchodzimy – w momencie, kiedy możesz, jeżeli powtarzasz swoją pracę, to znaczy, że możesz spróbować ją zautomatyzować. Jeżeli mamy więc pytanie o to, co automatyzować, to właściwie wszystko, co jest możliwe. I zarówno to, w jaki sposób tę aplikację dostarczysz, jak ją zbudujesz, jak ją uruchomisz, jak i jak ją utrzymasz – to jest ciągły proces. Właśnie tym się charakteryzuje cykl życia aplikacji w naszym środowisku – ona jest stale zmieniana, stale remiksowana, stale upgrade’owana, pewnie nazw jeszcze można tutaj milion wymyślić, natomiast chodzi o to, że to jest proces ciągły. Im więcej z tego procesu zautomatyzujesz, tym po prostu będziesz miał z tego większe benefity. 

 

M.K.: Tak, tylko mi chodziło o to, że to jest automatyzacja zadań związanych z rozwojem aplikacji. Nie da się za pomocą Kubernetesa, czy w ogóle systemu automatyzacji takiej opartej o kontenery, automatyzować, nie wiem, np. pracy fabryki.

 

Z.K.: Oczywiście, tak! Zgadzam się z tobą w 100%, że rzeczywiście taśmy produkcyjnej w ten sposób nie zautomatyzujemy. Ale np. rzeczy, które z tej taśmy wpadają nam do różnego rodzaju aplikacji, systemów, baz danych etc., to już można się pokusić o to, żeby tutaj rzeczywiście wdrożyć narzędzia automatyzacji, żeby te informacje w sposób łatwy, bardziej aktualny, mieć po prostu dostępne. 

 

Środowiska związane z kontenerami, aplikacje uruchamiane w formie mikroserwisów – ta technologia pomaga nam w tym, żebyśmy większość procesów, o których wspomniał Maciek, procesów związanych z dostarczaniem, zarządzaniem, utrzymywaniem naszej aplikacji i środowiska, na którym ta aplikacja działa, po prostu automatyzowali. 

Tak właśnie rozmawiam również z klientami, i u nas w zespole tak do tego podchodzimy – w momencie, kiedy możesz, jeżeli powtarzasz swoją pracę, to znaczy, że możesz spróbować ją zautomatyzować. Jeżeli mamy więc pytanie o to, co automatyzować, to właściwie wszystko, co jest możliwe. I zarówno to, w jaki sposób tę aplikację dostarczysz, jak ją zbudujesz, jak ją uruchomisz, jak i jak ją utrzymasz – to jest ciągły proces.

 

OK, to myślę, że mamy tutaj jasność. 

Mam wrażenie, że padł taki mocny akcent na wydawanie aplikacji, że np. na CI/CD, że to jest fajna rzecz, którą można za pomocą Kubernetesa automatyzować, czy połączyć powiedzmy. Natomiast zastanawiam się też na ile, z waszego doświadczenia wynika, że wszelkiego typu utrzymanie, wszelkiego typu skalowanie na przykład aplikacji, zwłaszcza takiej, powiedziałbym, trochę rozproszonej, np. w architekturze mikroserwisów, czy to też jest dobre zastosowanie Kubernetesa? 

 

Z.K.: Tak, oczywiście, że tak. Generalnie patrząc na to, w jaki sposób dziś tworzymy nowoczesne aplikacje właśnie, wydając je w formie mikroserwisów, czyli starając się budować aplikacje będące jak najdalej aplikacji monolitycznych, raczej wybieramy sobie poszczególne funkcjonalności, obudowujemy je właśnie kodem i dostarczamy do środowiska w postaci mikroserwisu, to to wszystko pomaga nam w tym, żeby tę aplikację potem łatwiej utrzymać, w tym, żeby ona była łatwiej skalowalna. 

Z historii z życia wziętych – np. pojawia się jakiś pomysł na nowy ficzer. Masz aplikację, aplikacja ta jest nawet monolitem, załóżmy, dlaczego nie. To jest aplikacja monolityczna, obsługuje Twój biznes, nakręca Ci klientów itd. Masz zespół developerów, product ownera itd. Powstaje z tego jakiś pomysł – „słuchajcie, może byśmy zrobili taki ficzer do aplikacji”. I teraz w momencie, kiedy dołożysz sobie taki ficzer do monolitu, a ten ficzer spotka się z bardzo pozytywnym odbiorem Twoich klientów, to tak naprawdę umieszczając ten ficzer w monolicie, musisz skalować całość, żeby można było zadbać o dostępność tego ficzeru. 

W momencie, w którym ten ficzer wydasz w formie mikroserwisu i zbudujesz to na takiej platformie jak właśnie platforma Kubernetes, to wtedy nawet w momencie, kiedy to zainteresowanie ze strony Twoich klientów będzie na tyle duże, że w sytuacji takiego monolitu masz problem, tutaj tego problemu mieć nie powinieneś. 

Słuchajcie, to jest naprawdę przykład z życia wzięty. Rozmawiałem kiedyś z jednym klientem, który właśnie coś takiego przeżył. To znaczy wypuścili ficzer i nie spodziewali się nawet tego, że aż z takim odbiorem się ten ficzer spotka. Na początku nawet wpadli w taką małą panikę: „ej, kurczę, nie zadbaliśmy o to, nie zadbaliśmy o tamto, co teraz będzie?”. Okazało się, że wszystko było dobrze. Właśnie dlatego, że środowisko wspomogło ich w tym zwiększonym ruchu, w zwiększonym zainteresowaniu. Odpowiadając więc na twoje pytanie – tak, jak najbardziej tak.

 

Właśnie, to jest, mam wrażenie, często jeden z takich najczęściej wymienianych saving pointów właśnie Kubernetesa – że dosyć dobrze współpracuje z taką architekturą mikroserwisów, że możemy dosyć łatwo skalować całe takie rozwiązania, o czym Zbyszek przed chwilą powiedziałeś. 

Chciałbym to na chwilę zderzyć z innym podejściem – z jakimiś usługami PaaS’owymi, gdzie nie musimy się zajmować całą tą administracją z ich usług, one po prostu dla nas są w jakiś sposób udostępniane. Dlaczego więc nie zrealizować naszej aplikacji właśnie z wykorzystaniem takich usług PaaS’owych w świecie chmury, w takim trochę kontrapunkcie do walki z Kubernetesem, z konfigurowaniem tego wszystkiego na własną rękę. Jakie tutaj plusy i minusy tych rozwiązań widzicie? 

 

M.K.: Myślę, że dużo zależy od takiego zdroworozsądkowego podejścia do tego, co chcemy zbudować. Dzisiaj klient może mieć taką sytuację, że posiada już jakąś aplikację, która jest monolitem, chciałby ją rozwijać, ale z drugiej strony przerabianie całej tej aplikacji na architekturę mikroserwisową, dzielenie jej na komponenty, uruchamianie tego w jakimś frameworku dockeryzacji czy konteneryzacji, takim jak Kubernetes – to jest kawał roboty! 

Ale przecież tę aplikację trzeba jakoś rozwijać, i są firmy, które dzisiaj dotarły już do takiego brzegu, gdzie nie są już w stanie postawić kolejnej kropki, bo ten monolit ma już w sobie zbyt duży ciężar gatunkowy, żeby go dalej rozwijać. Droga trudniejsza to jest engineering całej aplikacji, próba dockeryzacji czy konteneryzacji i wejścia w architekturę mikroserwisów, z drugiej strony można sobie pomyśleć: „kurczę, na pewno jest jakieś łatwiejsze rozwiązanie”. 

Nierzadko takim łatwiejszym rozwiązaniem jest zastosowanie jakichś usług chmurowych, np. usług z kategorii platform as a Service, czyli te, które dostarczają już gotowe mechanizmy, dostarczają gotowe rozwiązania, np. jakiegoś problemu technicznego albo biznesowego, i można je stosunkowo łatwo „doczepić” do naszej monolitycznej aplikacji, w ogóle nie wchodząc w architekturę mikroserwisów. 

W takim scenariuszu my dalej zostajemy z monolityczną aplikacją, ale jej dodatkowe funkcjonalności są realizowane przez takie platformowe usługi. To mogą być nowe rzeczy, nowe funkcjonalności, ale to może być też sposób na wyjście w jakiś sposób z monolitu, bo przecież możemy np. backend bazodanowy naszej monolitycznej aplikacji próbować zastąpić jakimś PaaS’owym backendem bazodanowym. Możemy obsługę serwerów wysyłki pocztowej SMTP wyłączyć z naszej aplikacji monolitycznej i zastąpić ją usługą PaaS’ową z jakiejś dużej chmury. I tak stopniowo możemy coraz więcej komponentów tej naszej monolitycznej aplikacji zastępować usługami PaaS’owymi, i za jakiś czas może się skończyć tak, że ta funkcjonalność monolitycznej aplikacji będzie na tyle nieduża, że przejście do architektury mikroserwisów będzie już proste. 

Usługi PaaS’owe to są usługi, które są dzisiaj bardzo mocno zdefiniowane i będą zdefiniowane. Dostawcy usług PaaS’owych określają, co dana usługa czyni i w takim zakresie można tę usługę wykorzystywać. Z kolei nasza aplikacja może mieć różnego rodzaju funkcjonalności właściwe tylko dla naszej aplikacji – i nie kupimy usługi PaaS’owej, która akurat takie funkcjonalności realizuje, więc gdzieś jednak ten kod będzie musiał zostać po naszej stronie. Wtedy być może będzie musiał zostać już jako aplikacja taka mała, mikroserwisowa. 

I możemy pozostać z taką architekturą hybrydową, gdzie część funkcjonalności będą realizowały albo monolityczne aplikacje, albo mikroserwisy po naszej stronie, jakieś właściwe funkcjonalności dla naszego rozwiązania, dla naszego pomysłu biznesowego, a część będzie realizowana przez usługi PaaS’owe z jakichś dużych chmur. I powstaje taka hybryda łącząca mikroserwisy po naszej stronie i usługi PaaS’owe od dostawców chmur. 

 

Z.K.: Ja bym chciał tutaj nawiązać do tego, co Maciek teraz mówi. Absolutnie w żaden sposób nie powinniśmy na to patrzeć w ten sposób, że wejście w Kubernetesa wyklucza nam stosowanie usług PaaS’owych – absolutnie nie! Wszystko w zależności od naszego zapotrzebowania. 

Co w sytuacji, kiedy np. mamy deployment ułożony w ten sposób, że ktoś u siebie ma zainstalowanego minikube’a, w tym minikube’ie ma wszystko, łącznie z bazą danych w Kubernetesie? Potem może to trafić do jakiegoś środowiska testowego w chmurze, gdzie jest Kubernetes, ta baza danych dalej może być uruchomiona jako płot np. w Kubernetesie. Co nie oznacza, że kiedy przechodzimy w kolejne stage’e naszej aplikacji, gdzieś nie pojawiają się jakieś usługi PaaS’owe. 

Dlatego, że oczywiście w zależności od naszego zapotrzebowania, to może być zmienne. Czyli w zastosowaniach np. developerskich spokojnie możemy wszystko wepchnąć sobie w kontenery, uruchamiać i nie ma problemu, jest wszystko fajnie. Możemy też, jeżeli mamy np. takie, a nie inne zapotrzebowanie na przetwarzanie i taką, a nie inną ilość przetwarzanych operacji, w zależności właśnie od tego, jaki to jest typ środowiska, możemy dalej w tych środowiskach testowych, developerskich utrzymywać wszystkie usługi uruchomione w Kubernetesie. Natomiast np. środowiska wyższe typu środowiska stage’owe czy środowiska produkcyjne mogą spokojnie korzystać z usług PaaS’owych, np. właśnie tej wspomnianej bazy danych.

Co w sytuacji jednak, w której nasze zapotrzebowanie na bazę danych jest tak duże, że nawet usługi, które są Managed Services u dostawców chmurowych są za małe, bo np. opieramy się o jakieś limity, bo np. rzeczywiście potrzebujemy 20 tys. zapytań na sekundę w bazie danych i zaczyna się to robić problemem? Nic nie stoi na przeszkodzie, żebyśmy zrobili sobie hybrydę i przygotowali konfigurację systemów operacyjnych, dużych serwerów, które również w dalszym ciągu się skalują, np. wielkich maszyn wirtualnych, na których uruchamiamy sobie wtedy takie środowisko bazodanowe. 

I ten Kubernetes, ta nasza aplikacja, niezależnie czy to monolityczna, czy podzielona na mikroserwisy, w zależności od tejże aplikacji i zapotrzebowania, może korzystać i być wspierana innymi usługami, więc PaaS przychodzi z pomocą. To nie jest tak, że musimy wszystko uruchamiać w Kubernetesie, nie! Możemy łączyć to wszystko i budować sobie swoistego rodzaju hybrydy. 

 

Jasne.

 

M.K.: Wiesz, z trzeciej strony mogą być takie usługi PaaS’owe, których nie jesteśmy w stanie w ogóle odwzorować w środowisku mikroserwisowym czy w ogóle jakimkolwiek innym. Czy to będą np. rozwiązania dedykowane AI, czy jakiś Deep Learning, czy jakieś dość złożone analityki – to jest trudne do zbudowania samodzielnie, łatwiej jest skorzystać z usługi PaaS’owej, uzupełniając ten Flow naszej aplikacji o odniesienie do takich narzędzi na zewnątrz. Tak że z rozsądkiem. Te dwie architektury w ogóle się wzajemnie nie wykluczają, właściwie mogą działać współbieżnie i to jest całkiem niezły pomysł. 

 

Wiecie, cieszę się bardzo, że rozmawiamy o takim zdroworozsądkowym podejściu do wybierania tych rozwiązań, a nie jakimś takim dogmatycznym, gdzie mówimy, że zawsze trzeba robić tylko tak, bo to się zawsze u każdego zawsze sprawdzi. Doskonale wiemy, że nie zawsze. 

Dobrze, wiemy mniej więcej, czym jest ten Kubernetes, jakie ma zastosowania, zatem może teraz jakby ktoś chciał sobie to zainstalować i uruchomić, to co może zrobić? Może to po prostu pobrać i uruchomić jako usługę? W jaki sposób uruchomić Kubernetes? 

 

M.K.: Metod jest wiele, ale to wcale nie jest takie proste. To jest tak – możemy z Kubernetesa skorzystać uruchamiając tę platformę w ramach oferty dostawców dużych chmur, czyli globalnych chmur, ale też naszych lokalnych. Dzisiaj w ofercie większości dostawców chmurowych jest coś takiego jak Managed Kubernetes, który pozwala za pomocą właściwie kilku kliknięć w ramach interfejsu użytkownika, uruchomić cały klaster Kubernetesa i nie zastanawiać się nad tym, jak to zrobić manualnie. Dostajemy całego działającego Kubernetesa, i w ramach tego Kubernetesa możemy już wrzucać tam swoje aplikacje, uruchamiać swoje procesy. Dzisiaj właściwie wszyscy znaczący dostawcy tego rodzaju usługę posiadają, my też. 

Ale Kubernetesa można także uruchomić samodzielnie, korzystając ze środowisk wirtualnych, czyli uruchomić po prostu na wirtualkach – gdzieś uruchamiamy kilka wirtualek i na nich uruchamiamy Kubernetesa. Można to zrobić też na fizycznym sprzęcie. Możemy wziąć fizyczne maszyny i na tych fizycznych maszynach uruchomić Kubernetesa. 

Tyle że uruchomienie samego Kubernetesa to już wcale nie jest taka trywialna sprawa. Zazwyczaj schodzi dość dużo czasu na to, trzeba mieć dość szeroką wiedzę, i to taką specjalistyczną, z różnego rodzaju obszarów IT – od sieci, przez tory, czy przez chociażby umiejętność pisania Joomli konfiguracyjnych. 

Naprawdę jest dość duża bariera wejścia. Jeśli ktoś chce i ma na to ochotę, to super, natomiast polecamy raczej korzystanie z usług już istniejących na rynku, takich właśnie jak chmury. Nie wiem Zbyszek, czy zgadzasz się z moją opinią. Pytanie, czy w ogóle Zbyszek instalowałeś kiedyś Kubernetesa? 

 

Z.K.: Wiesz co, nie, ale widziałem, jak chłopaki to robią. 

 

M.K.: A ja ci powiem, że instalowałem i to nawet kilka dni temu miałem okazję przejść cały proces instalacji i zeszło mi dwa dni, żeby to uruchomić i wrzucić na WordPressa. 

 

Z.K.: Maciek, jakbyś wpadł do nas, to byśmy ci dali dostęp do takiego repo, kliknąłbyś  z niego „uruchom” i generalnie ten Kubernetes by ci stanął, łącznie z całym managmentem, przygotowaniem sieci, wstępnym zabezpieczeniem tego itd. 

 

Oczywiście, że tak można. Ja bym tutaj dorzucił tylko jeszcze jedną rzecz. Pewnie już nie będzie zdziwieniem – oczywiście, że zgadzam się z Maćkiem i z tym, co on powiedział, natomiast przy tej całej instalacji Kubernetesa, zastanówmy się, po co większość firm i biznesów miałaby to robić? Jaka jest z tego korzyść? Tak naprawdę wydaje mi się, że kluczowe w dzisiejszym świecie IT jest to, żeby firmy skupiały się na swoim biznesie, a to, co dzieje się pod spodem i w czym to się dzieje, to niech to robią firmy, które się w tym rzeczywiście specjalizują i to robią. 

Wydaje mi więc, że jak najbardziej zachęcałbym również tak jak Maciek do tego, żeby jednak nie tracić czasu na to, zostawmy to zespołom, firmom, które rzeczywiście na co dzień rozwiązują problemy z takim działaniem platformy, a my skupmy się na tym, co jest ważne dla naszego biznesu, skupmy się na naszej aplikacji, skupmy się właśnie na tych ficzerach, skupmy się na tym, jak zwiększyć naszą sprzedaż. Wydaje mi się, że to jest najważniejsze. A to, co jest pod spodem, to niech ktoś to po prostu za nas ogarnie. 

 

M.K.: Ale wiesz co Zbyszek? Tak, żeby już wyczerpać temat do końca, to jest jeszcze coś takiego jak minikube. Czyli takie narzędzie, konfiguracja, która pozwala całego Kubernetesa szybko i łatwo uruchomić na jednym komputerze. Bez kolekcjonowania dużej infrastruktury czy wirtualnych maszyn. I to jest takie rozwiązanie, które można samemu sobie uruchomić na własnym komputerze, chociażby po to, żeby zobaczyć, jak to wygląda. To developer czy programista mógłby coś takiego zrobić, wrzucić sobie jakiś obraz dockerowy, uruchomić, zobaczyć jak to działa. 

To jest takie dość ładnie opisane narzędzie, żeby zapoznać się w ogóle ze środowiskiem Kubernetesa. Natomiast to raczej nie nadaje się do używania produkcyjnie i pewnie nikt zdroworozsądkowo myślący nie będzie na minikube’ie stawiał środowiska produkcyjnego. To już, tak jak Zbyszek mówił, i tak jak ja powiedziałem wcześniej, raczej instalacje, które są przygotowane przez profesjonalistów. 

 

Z.K.: To, o czym też wspominałem, minikube pomaga developerom np. jeżeli chcą sobie uruchomić u siebie na laptopie, coś przetestować, szybko zrobić, to jest bardzo pomocne narzędzie do tego. A idąc już w tę stronę, to znaczy odchodząc może trochę od tematu samego Kubernetesa, ale właśnie w tę, jak łatwo wejść w ten temat, to… Znaczy, mam nadzieję, że mogę to powiedzieć, bo jest to usługa, którą ja znam tylko w jednej chmurze publicznej, bardzo możliwe, że każda chmura ma taki swój odpowiednik. Mianowicie chciałbym powiedzieć o czymś, co się nazywa Copilot i usłudze AWS-owej, gdzie po prostu z Basha na swoim komputerze robię sobie deployment i uruchamiam z wykorzystaniem tego Copilota coś w AWS-ie, to coś mnie w ogóle nie interesuje, a tam pod spodem dźwiga się cała artyleria związana z działaniem właśnie środowisk kontenerowych. 

Ten próg wejścia, nauczenia się może być więc różny. Ale finalnie, zaufajmy tym dostawcom i korzystajmy z tych usług, nie… Jak to się mówi?

 

M.K.: Nie wyważajmy drzwi.

 

Z.K.: Dziękuję, Maćku, dokładnie! Nie wyważajmy drzwi, które są już otwarte. 

 

M.K.: Nie wyważajmy otwartych drzwi, właśnie. 

 

Metod jest wiele, ale to wcale nie jest takie proste. To jest tak – możemy z Kubernetesa skorzystać uruchamiając tę platformę w ramach oferty dostawców dużych chmur, czyli globalnych chmur, ale też naszych lokalnych. Dzisiaj w ofercie większości dostawców chmurowych jest coś takiego jak Managed Kubernetes, który pozwala za pomocą właściwie kilku kliknięć w ramach interfejsu użytkownika, uruchomić cały klaster Kubernetesa i nie zastanawiać się nad tym, jak to zrobić manualnie. Dostajemy całego działającego Kubernetesa, i w ramach tego Kubernetesa możemy już wrzucać tam swoje aplikacje, uruchamiać swoje procesy. Dzisiaj właściwie wszyscy znaczący dostawcy tego rodzaju usługę posiadają, my też.

 

Tak. Słuchajcie, idealnie się uzupełniacie, bardzo dobra puenta. Myślę, że Maciek skutecznie odstraszył od instalowania Kubernetesa na własną rękę i że faktycznie trzeba mieć szereg umiejętności, żeby to zrobić. 

Ale weźmy np. jakiegoś dostawcę takiej usługi, jak np. Oktawave. Czy trzeba posiadać jakieś szczególne kompetencje, umiejętności, żeby z Kubernetesa skorzystać? Jak to wygląda?

 

M.K.: My jako Oktawave dostarczamy Managed Kubernetesa, czyli dostarczamy rozwiązanie, które klient po zalogowaniu do panelu administratora może uruchomić w bardzo łatwy sposób. To jest coś, co wypracowaliśmy wewnętrznie, jest to kawał technologii, która sprawia, że dla każdego klienta my provisionujemy uruchomienie oddzielnego klastra kubernetesowego, więc wszystko jest całkowicie zautomatyzowane, nikt tutaj nie siedzi i ręcznie tych Kubernetesów dla klientów nie uruchamia. 

Ale żeby rzeczywiście do tego dojść, to pewnie tak z półtora roku developmentu nam to zajęło mniej więcej. I wiesz, tutaj kompetencji trzeba bardzo dużo – od storage’u, przez networking, przez automatyzację, przez procesy DevOpsowe, naprawdę masę różnego rodzaju pracy. W zasadzie chcąc uruchomić Kubernetesa samodzielnie, te kompetencje w jakiejś części musimy powielać. 

Chociażby stos sieciowy w Kubernetesie – uruchmiając tego Kubernetesa, dochodzimy na pewnym etapie do tego, że musimy zdecydować, jak ma być zrealizowany stos sieciowy. I mamy do wyboru z 10 różnego rodzaju rozwiązań i chociażby decyzja: „dobra, to co ja mam tu uruchomić? Jakąś FAN-elową sieć, a może Calico, a może jakieś rozwiązanie od CISKA, może jeszcze coś? No kurde nie wiem”. I teraz właściwie z każdego z tych rozwiązać trzeba się doktoryzować, żeby je dobrze rozpoznawać. 

A dostawca, taki jak my, jak AWS, jak Azure już ten proces myślowy przeszli, już wiedzą, które rozwiązanie będzie najlepsze do zastosowania w ich środowisku chmurowym. Uruchamiając Kubernetesa dla klienta, uruchamiają go już kompletnego, dostosowanego do danej platformy chmurowej. Tak że od strony klienta nie są wtedy potrzebne już żadne kompetencje. Klient, uruchamiając taki klaster kubernetesowy nie musi decydować o tym, jaki ma być provider sieciowy, jaki ma być provider storage’owy, gdzie ma być API, co tam ma się dziać po drodze – to wszystko już jest zapakowane, zamknięte, a od strony klienta właściwie jest tylko pobranie kubectla i configa do kubectla, i korzystanie z klastra. 

Potrzebne są kompetencje developerskie przede wszystkim, takie DevOpsowe – mamy teraz klaster kubernetesowy i coś z nim trzeba zrobić, trzeba ułożyć jakiś proces, żeby tam się te aplikacje pojawiły. To jest cały proces developerski i tutaj kluczowe kompetencje są wtedy potrzebne. A nie cały stos kompetencji, żeby tę maszynerię Kubernetesa, te wielkie armaty przygotować, naładować i uruchomić. Klienci tego nie potrzebują dzisiaj, to jest po stronie dostawców. 

 

Z.K.: To, o czym mówi Maciek, przychodząc na stronę aplikacji, stronę klienta, który będzie korzystał, czy korzysta np. z usług kubernetesowych u nas, potrzebne jest też zrozumienie tego, jak to działa. Kubernetes może bardzo pomagać w wielu rzeczach, ale przygotowując nasze aplikacje, musimy o tych rzeczach wiedzieć. Fajnie jest więc mieć po prostu po swojej stronie osoby, zespół, które z tą technologią są w jakimś stopniu zapoznane, które wiedzą, jakie np. metryki definiować tak, żeby potem rzeczywiście móc patrzeć i obserwować to, co się dzieje wna tym środowisku z naszą aplikacją, przygotowywać procesy stricte DevOpsowe, to znaczy dążyć do tego, żeby rzeczywiście wdrożenie aplikacji odbywało się w sposób onlajnowy, w sposób niezakłócający działanie np. usług produkcyjnych, żeby to testować w formie czy to testów automatycznych, czy testów funkcjonalnych etc. To jest cały proces, ale dzięki temu rzeczywiście jesteśmy w stanie mieć potem fajne i odporne środowisko w chmurze. 

 

Nawiązując teraz do tego, o czym Zbyszek mówisz, chciałbym zapytać, cofając się może trochę jeszcze – poruszyliśmy kwestie techniczne, ale to jest kolejny krok, prawda? Na początku organizacja, projekt musi być gotowy, musi być jakaś świadomość, że chcemy z takiego rozwiązania skorzystać. Czy jest jakaś faza rozwoju projektu, faza rozwoju organizacji i firmy, kiedy można powiedzieć: „OK, jesteśmy już gotowi, żeby z Kubernetesa skorzystać”? 

 

M.K.: Jak już jest ugotowana. 

 

Z.K.: Jak już jest ugotowana, nic już nie wychodzi…

 

Nic nie działa.

 

Z.K.: Tak, to jest na pewno moment, w którym warto spojrzeć w tę stronę. 

 

M.K.: Są dwa etapy – albo jesteśmy na pierwszym, takim początkowym etapie rozwoju organizacji i wtedy już myślimy o naszej organizacji w taki bardzo nowoczesny sposób,  tworzymy tę organizację i tworzymy pewnie jakieś procesy biznesowe i aplikacje, które za tym idą i wtedy możemy myśleć o Kubernetesie czy w ogóle o mikroserwisach na samym początku. 

Lub, tak jak powiedziałem przed chwilą, organizacja się ugotowała, czyli nie może postawić kolejnego kroku, bo postawienie kolejnego kroku jest tak niezwykle kosztowne, że nam się już nie opłaca. I wtedy musimy się zatrzymać, zastanowić, jak dalej w ogóle mamy rozwijać ten nasz biznes, te nasze aplikacje IT, bo to o tym mowa. Niewykluczone, że wtedy uzmysłowimy sobie, że tak, potrzebujemy jakiejś wielkiej zmiany i wtedy jesteśmy gotowi. 

To nie jest śmieszne, ale czasami jak człowiek jest np. chory od nadmiaru alkoholu, to musi sobie powiedzieć, że już sięgnął dna, i jak jest gotowy to zaakceptować, to dopiero wtedy może zbudować coś nowego. Nie wiem, czy to jest trafione porównanie, ale trochę sens taki sam. Musimy zdać sobie sprawę, że dalej już nie pociągniemy. Jak sobie zdamy sprawę, że dalej nie pociągniemy w tej konfiguracji, to jest ten moment, kiedy jesteśmy gotowi, żeby zacząć rozmawiać o Kubernetesie, czy w ogóle mikroserwisach. Dzisiaj tematem naszego podcastu jest Kubernetes, ale ogólnie rzecz biorąc architektura mikroserwisów niekoniecznie musi być realizowana w Kubernetesie, możemy to jakoś inaczej zrobić. Niemniej jednak to jest ten moment, kiedy może się pojawić hasło Kubernetes.

 

Z.K.: Jeszcze to, co mi się wydaje tutaj też kluczowe… Bo tak jak Maciek powiedział, w momencie, w którym odpalasz dzisiaj biznes, budujesz aplikacje, chcesz wejść z czymś na rynek – jasne, patrz od razu w tę stronę, to Ci zaprocentuje w przyszłości. Jeżeli jednak jesteś już zagnieżdżony w tym biznesie i posiadasz aplikacje, które już mają swoje lata, dług technologiczny narasta i martwisz się o jutro, czy osiągnąłeś właśnie to dno, o którym wspomniał Maciek, to też od razu nie porywajmy się z motyką na słońce.

To nie jest tak, że my musimy od razu przerobić wszytko i zrobić wszystko. Zróbmy sobie rachunek sumienia, zróbmy rzeczy, które są istotne z punktu widzenia biznesu, które są kluczowe i na tym budujmy, próbujmy to przerobić, ale nie łapmy się od razu za wszystko. Może nie zawsze, bo może ktoś będzie miał więcej szczęścia, ale jednak historia pokazuje, że można wtedy polec przy takiej transformacji, bo to jest kolejne sformułowanie, kolejny zwrot, który się bardzo często pojawia. Transformacja do mikroserwisów jest procesem wymagającym, więc pochylmy się nad tym dokładnie, nie próbujmy od razu rozwiązać wszystkich problemów. Ta technologia pomaga nam w tym, żeby robić to stopniowo. 

Tak jak Maciek powiedział, w momencie, w którym odpalasz dzisiaj biznes, budujesz aplikacje, chcesz wejść z czymś na rynek – jasne, patrz od razu w tę stronę, to Ci zaprocentuje w przyszłości. Jeżeli jednak jesteś już zagnieżdżony w tym biznesie i posiadasz aplikacje, które już mają swoje lata, dług technologiczny narasta i martwisz się o jutro, czy osiągnąłeś właśnie to dno, o którym wspomniał Maciek, to też od razu nie porywajmy się z motyką na słońce. To nie jest tak, że my musimy od razu przerobić wszytko i zrobić wszystko. Zróbmy sobie rachunek sumienia, zróbmy rzeczy, które są istotne z punktu widzenia biznesu, które są kluczowe i na tym budujmy, próbujmy to przerobić, ale nie łapmy się od razu za wszystko.

 

Właśnie, bo to mogą być takie strategiczne, czy też jeśli już sięgamy dna, wręcz życiowe decyzje. A co byście powiedzieli na to, żeby wykorzystać w jakiś sposób albo wpasować powiedzmy Kubernetes w nasz pipeline CI/CD w taki developerski powiedziałbym proces. Czy tutaj możemy mieć jakiś realny zysk, czy to może nam w czymś pomóc? 

 

Z.K.: Oczywiście! W ogóle myśląc o Kubernetesie gdzieś z tyłu głowy zawsze powinniśmy mieć pipeline’y, powinniśmy mieć właśnie procesy CI/CD. Generalnie bez tego ciężko to sobie wyobrazić. W takich starych czasach…

 

M.K.: Czyli całe pięć lat temu.

 

Z.K.: Tak, przed 2014 rokiem bardzo często swoją aplikację mogłeś wrzucać z wykorzystaniem protokołu FTP, coś tam sobie developowałeś u siebie, łączyłeś się FTP-em, podgrywałeś nową wersję. Oczywiście najpierw to przetestowałeś, żeby nie mówić, że testy tylko na produkcji, ale często jednak nie przetestowałeś, wrzuciłeś na produkcję, patrzyłeś, czy to działa. Tak było, wiele firm w ten sposób wdrażało aplikacje. Ba! Podejrzewam, że wciąż jeszcze jest wiele firm, które tak robią. 

Myśląc o Kubernetesie, o mikroserwisach, o takim jakby rozproszeniu, bez procesu, bez pipeline’u, bez automatyzacji tego – zginiesz. Bo to już nie jest tak, że będziesz sobie tym FTP-em wgrywał dalej teraz kolejne jakieś elementy, bo po prostu się w tym wszystkim pogubisz, musisz mieć do tego proces. Czy on się więc wpasowuje? Ja bym powiedział, że te rzeczy są ze sobą mocno powiązane. Myśląc o jednym, myślmy po prostu właśnie w takiej formie. 

 

Będąc developerem, będąc programistą, mogę np. pracować nad aplikacją webową. Idąc jakimś tam mainstreamem, wykorzystuję, powiedzmy Javę, może PHP albo mając jakąś większą fantazję, mogę skorzystać nawet z Haskella. Czy stos technologiczny ma jakiekolwiek znaczenie w przypadku Kubernetesa? Mamy jakieś ograniczenia, czy to jest zupełnie transparentne?

 

M.K.: Nie ma, to właśnie architektura mikroserwisu i zamknięcie tej naszej aplikacji w obraz dockerowy pozwala w tym obrazie dockerowym uruchomić czy skorzystać z dowolnej technologii. A czy my napiszemy ten nasz mikroserwis w C, w Haskellu, w Go, czy w PHP-ie – be my guest!. Pisz, w czym potrafisz, w czym się czujesz najlepiej. Powstaje mocno takie heterogeniczne środowisko, ale czemu nie. Po to mamy tu dockery, aby móc aplikacje w ten sposób zamykać. 

I właściwie – to może już trochę szerzej – patrząc na tempo rozwoju technologii i tempo, z jakim rozwijają się różne języki, co wnoszą do naszego życia, w czym usprawniają różnego rodzaju procesy, to można założyć, że siłą rzeczy po kilku latach od powstania naszej aplikacji na pewno pojawiło się coś, co łatwiej będzie zrealizować w innym języku, niż cała nasza aplikacja. Tak że jeśli tylko chcemy, nie ma moim zdaniem żadnego problemu, aby uruchamiać aplikację w dowolnym języku i ten właściwie problem dostosowania do Kubernetesa nie istnieje, bo zamykamy to w dockerze.  

 

Jasna sprawa. 

Dobrze, wdrożenie Kubernetesa to jedno, to jest jakiś pierwszy krok, ale później to wszystko jakoś działa, musimy to jakoś utrzymywać, dobrze by było przynajmniej monitorować. Czy Kubernetes daje nam jakieś możliwości, narzędzia do monitorowania aplikacji? 

 

Z.K.: Oczywiście, że daje i oczywiście, że jest ich mnogość. W ogóle to, co wydaje mi się, że ma bardzo duże znaczenie przy Kubernetesie ze względu na jego popularność obecnie, w tej chwili dostępność narzędzi, gotowych rozwiązań jest bardzo duża, więc kwestia tego, jak my to zaimplementujemy, jest po naszej stronie. Natomiast community jest po prostu bardzo duże. 

I oczywiście, że pomaga w monitoringu, ale właśnie warto, o czym już wspomniałem, w procesie developmentu myśleć generalnie o tym, co warto mierzyć w tym, co przygotowujemy, przygotowywać do tego metryki, mieć zaimplementowane narzędzia, które pozwalają nam na pokazanie tego, co się dzieje w naszych klastrach, na miejsca, do których będą wpadały logi, te logi będą upgrade’owane, będziemy mieli dashboardy, pokazujące, co w danym momencie, w danej jednostce czasu dzieje się w naszym systemie. 

Tak, Kubernetes w tym pomaga, są gotowe rozwiązania, które można zaimplementować u dostawców chmurowych, ale jednak chcąc – przynajmniej patrząc na to, jak się u nas dzieje – wykorzystać i mieć jak najwięcej informacji, to to wymaga rzeczywiście już zaangażowania, poznania i umiejętności odczytania tego, co warto sprawdzać, na co warto patrzeć. Dlatego, że Kubernetes ma to do siebie, że potrafi logować naprawdę wszystko, więc fajnie jest, żebyśmy wyłapywali też z tego kluczowe rzeczy i używali systemów, które pozwalają nam na odczytanie wartościowych informacji z punktu widzenia naszej aplikacji, biznesu, technologii i działania, po prostu. 

 

Powiedziałeś Zbyszku, że Kubernetes się rozwija, że jest fajne community. Każda technologia, która jakiś czas już istnieje, która się rozwija, ma też pewne bolączki, pewne problemy, z którymi musi się mierzyć. Jakie największe bolączki i problemy, braki związane z Kubernetesem obecnie występują? 

 

Z.K.: Uważam, że m.in. trzeba uważać, co się wykorzystuje. Generalnie korzystajmy z certyfikowanych źródeł na przykład, z certyfikowanych obrazów. Korzystajmy z rzeczy, które zostały sprawdzone, są przetestowane. Bo rzeczywiście można sobie zrobić krzywdę, można sobie trochę obniżyć bezpieczeństwo działania swoich systemów itd. Bo tak właśnie jest – ta popularność powoduje, że jest stały rozwój, ale też oczywiście ktoś myśli nad tym, jak wykorzystać tę technologię do celów zupełnie innych, niż tylko skalowalność, wydajność, elastyczność i rzeczy z tym związane. Przynajmniej mi przychodzi taka rzecz do głowy, że to, z jakich obrazów korzystamy, jest ważne. 

A druga rzecz jest taka, że ta popularność powoduje też mnogość rozwiązań. To znaczy, każde wyzwanie może zostać obsłużone przez szereg różnego rodzaju oprogramowania czy technologii, która się z tym wiąże. I rzeczywiście troszkę metodą prób i błędów albo troszkę wykorzystując np. zespoły konsultingowe, warto dobierać tę technologię do naszych rozwiązań. To głównie bym wskazał.

 

M.K.: Chyba nie należy też zapominać o tym, że jedną z ważnych rzeczy jest też dość wysoko postawiona bariera wejścia do Kubernetesa. Bo my znajdujemy się w tym świecie – ja ze Zbyszkiem – już od wielu lat, dość dobrze rozumiemy, jak działa Kubernetes, zresztą wywodzimy się ze świata technologicznego i pewnie krok po kroczku byliśmy świadomi tego, jak sama technologia dockeryzacji powstaje. 

Niemniej jednak dzisiaj szereg ludzi nie ma takiego doświadczenia. Nie umniejszając, większość jest oczywiście bardzo zdolna, natomiast ten czas potrzebny, żeby zrozumieć jak działa Kubernetes, jak działają procesy w środku, czym w ogóle są mikroserwisy, jak budować aplikacje mikroserwisowe, jest naprawdę dość długi i trzeba poświęcić sporo czasu, żeby się tego naprawdę solidnie nauczyć. To jest pewnie jakąś bolączką Kubernetesa, takiej technologii dość świeżej, co do której jest już dość dużo dokumentów, ale ona wciąż jest jeszcze skomplikowana dla przeciętnego człowieka, nawet tego związanego z IT. 

 

Czy w związku z tym jest to być może jakiś etap przejściowy, powiedzmy, w ewolucji orkiestracji właśnie kontenerami? Jak widzicie przyszłość tej technologii?

 

M.K.: Dockery czy w ogóle środowisko konteneryzacji jest efektem, czy też powstało w efekcie rozwoju technologii w obszarze wirtualizacji też między innymi. Czyli kiedyś mieliśmy fizyczne serwery, i chcieliśmy te fizyczne serwery dzielić – bo mamy jeden duży serwer, a mniejsze aplikacje. Ten fizyczny serwer trzeba było więc jakoś podzielić. W dawnych czasach jeszcze w latach 70. były rozwiązania takie UNIX-owe, nie boję się używać tego słowa, albo wręcz takie, które pozwalały na podzielenie tego sprzętu fizycznie w ramach sprzętu, AX chyba, AS/400 bodajże miało takie możliwości, gdzie fizyczną maszynę za pomocą konfiguracji można było podzielić na szereg mniejszych maszyn. 

Później pojawiła się wirtualizacja i tego rodzaju technologia była dostępna na platformę x86, czyli wszystkie pecety, które używamy. Zresztą technologia x86 jest podstawą działania większości serwerów dzisiaj. Mogliśmy więc dzielić te serwery na mniejsze za pomocą wirtualizacji, ale okazało się, że wirtualizacja to wciąż jeszcze mało, że jeszcze potrzebujemy te środowiska wirtualne podzielić na jeszcze mniejsze komponenty. Nie pamiętam teraz dokładnie, ale kontenery w kernelu linuxowym to są od kilkunastu lat chyba. 

Dopiero po pojawieniu się środowisk wirtualizacji te kontenery nabrały nowego znaczenia i dzisiaj dzielą nam wirtualki na jeszcze mniejsze komponenty. Aplikacje mikroserwisowe są nieduże, więc nie ma sensu stawiać wirtualki, która ma parę megabajtów pamięci czy tam parędziesiąt megabajtów pamięci – to się mija z celem w ogóle, to jest kosztowo nieopłacalne. A mikroserwisy mogą w takim środowisku całkiem nieźle działać. Co będzie dalej? Szczerze mówiąc, ja nie podejmuję rękawicy próby odpowiedzenia na to pytanie. Zbyszek, masz jakiś pomysł?

Na pewno będą rozwijać środowisko orkiestracji, provisionowania, może jakiejś graficznej reprezentacji – mamy Ranchera, który pozwala nam jakieś fajne rzeczy wizualizować. Może w tym kierunku to będzie szło, tak sądzę.

 

Z.K.: Wydaje mi się, że z Kubernetesem i z tą technologią będziemy jeszcze na pewno przez X lat dość blisko, natomiast wydaje mi się, że zmieni się w dużym stopniu sposób użycia i wykorzystania tej technologii. Maciek przywołał tutaj Ranchera – tak, między innymi dziś borykamy się z problemami, chociażby właśnie z instalacją promowej Kubernetesa z jego upgrade’em. Właśnie takie narzędzia typu Rancher bardzo w tym pomagają. Wydaje mi się więc, że mimo wszystko świat tej technologii jeszcze trochę będzie, natomiast będzie zmieniało się wykorzystanie i właśnie będzie obniżony próg wejścia w tę technologię. 

 

M.K.: Też tak sądzę. 

 

Dobrze. To może za jakiś czas się spotkamy, porozmawiamy, zobaczymy, na ile te nasze osądy się spełniły. 

Tymczasem chciałbym jeszcze na koniec was zapytać właśnie o Kubernetes i Oktawave – jakie macie doświadczenie? Już trochę powiedzieliście na ten temat. Natomiast jak pomagacie w tym obszarze swoim klientom?

 

M.K.: Pomagamy w co najmniej dwóch obszarach. Po pierwsze staramy się być partnerem takim, który pomaga firmom w migracji do chmury, i w trakcie tej migracji do chmury także w przejściu na architekturę mikroserwisów. Dostarczamy tu takie usługi konsultingowe, inżynieryjne. Usługi, które pozwalają klientom lepiej zrozumieć architekturę mikroserwisów. My potrafimy wyjaśnić, jak to działa, jakie są korzyści, jakie są benefity ze stosowania w ogóle tej technologii. I przeprowadzamy w zasadzie klienta za rączkę, od jakiegoś takiego audytu, czy takiego spisu z natury co dzisiaj jest u klienta, poprzez projekt architektury, analizę, egzekucję i ostatecznie otwarcie szampana po uruchomieniu w środowisku chmurowym. 

Z drugiej strony dostarczamy także produkt, czyli dostarczamy w ramach platformy Oktawave usługę OKS – Oktawave Kubernetes Service. I jest to taka sama usługa jak w AWS, w Azure, w Google, czyli pozwalająca na uruchomienie klastra kubernetesowego w łatwy sposób. Można się u nas zarejestrować, można założyć konto i tego Kubernetesa za pomocą paru kliknięć otrzymać. 

 

Świetnie. 

Maciej Kuźniar i Zbyszek Kamiński byli dzisiaj moimi gośćmi. Rozmawialiśmy o Kubernetes. Panowie, bardzo wam dziękuję za rozmowę!

 

Z.K.: Dzięki piękne!

 

M.K.: Dziękujemy!

 

Dzięki wielkie! 

Na koniec powiedzcie jeszcze zanim was wypuszczę, gdzie was można znaleźć w internecie, jak się z wami skontaktować? 

 

M.K.: Mailowo! Można do nas napisać maila, można się odezwać na Linkedinie, można do nas zadzwonić. Co jeszcze Zbyszek?

 

Z.K.: Można zadzwonić, natomiast tak sobie pomyślałem w pierwszym momencie, jak powiedziałeś o tym mailu, a wcześniej jak w ogóle technologia wirtualizacji się pojawiała, że trochę odkryłeś nasz PESEL tym samym. 

 

M.K. Czekaj, czekaj Zbyszek, ale ja nie zaproponowałem wymiany wizytówek. 

 

Z.K.: Ale prawie!  Słuchajcie – tak, Linkedin. Nie wiem Krzysztof, wydaje mi się, że pewnie gdzieś tam w linkach to umieścisz. 

 

Oczywiście! Tak jest, wszystko będzie w notatce do odcinka, wszystkie linki zawrę. 

 

Z.K.: Polecam się na Linkedinie generalnie.

 

Dobrze, świetnie. Zatem tam sprawdzajmy. Dodajmy jeszcze stronę Oktawave, która też będzie podlinkowana. 

Wielkie dzięki jeszcze raz z mojej strony! 

Do usłyszenia, cześć!

 

M.K. Do usłyszenia!

 

Z.K.: Dzięki! Cześć!

 

To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Kubernetes pełni obecnie ważne miejsce na liście dostępnych rozwiązań do orkiestracji kontenerów i nic nie wskazuje, żeby szybko miało się to zmienić. Wielu dostawców usług chmurowych, w tym Oktawave, świadczy usługi związane z Kubernetes. Z racji na to, próg wejścia w tę technologię jest znacznie niższy. 

Jeśli ten odcinek był dla Ciebie interesujący lub przydatny, odwdzięcz się, proszę recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz jak zawsze śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Kubernetes. 

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!