Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do odcinka w opisie albo na Patoarchitekci.io. I oczywiście robimy szkolenia, którymi się chwalimy. Łukaszu, Ty będziesz pokazywał, która nie jest taka łatwa i sprawdzał tych, którzy wiedzą i już wszystko niby umieją. I sprawdzenie jak zbudować z klocków tak naprawdę to, żeby to miało sens.

Łukasz Kałużny: I o czym pamiętać, czyli wszystkie drivery, które są spoza naszych projektów, a powodują, że życie zaczyna się komplikować, albo można je uprościć. A Ty?

Szymon Warda: Dokładnie. Observability, mianowicie APM-y, debuggery, narzędzia do monitorowania wydajności, jak ułożyć to w sensowny stos albo korzystając z czegoś gotowego w postaci Application Insights, albo stawiając to open source’owo w postaci Prometeusz, Grafana Loki, Grafana Tempo i Grafana jako taka + jeszcze Alert Manager. A do tego na koniec jeszcze pobawimy się chwilę PIXI, czyli takim serwismeshowym…

Łukasz Kałużny: Podejściem do observability. A jeżeli chcielibyście któreś z tych szkoleń mieć u siebie w firmie albo inne, to też zachęcamy do kontaktu. Link do całego katalogu szkoleń w opisie. Pora na dzisiejszego naszego gościa Mariusza Dalewskiego. Część z Was może go nie kojarzyć, bo jest z bardzo ciemnej strony mocy, którą można określić jako SysOps/DevOps. Mariusz, jeżeli chodzi o część jego takiego działania w community, w 2015 roku współzakładał grupę facebookową SysOps/DevOps Polska. Na wszystkich grupach grubo ponad 60 tysięcy aktywnych użytkowników. Oprócz tego stacjonarne meetupy, które przerodziły się w fundację i są w całej Polsce. A dodatkowo Mariusz zawodowo prowadzi MDV, czyli firmę, która oferuje usługi gdzieś wokół nie tylko cloudów, ale też innych rzeczy. I dzisiejszym tematem rozmowy z Mariuszem będzie troszkę zobaczenie alternatywnego podejścia do rzeczywistości, którą znamy gdzieś z tego, o czym my z Szymonem na co dzień rozmawiamy. Cześć Mariuszu.

Mariusz Dalewski Cześć, cześć wszystkim. To chyba na dzień dobry, też jak ktoś ostatnio, zacznę od małego sprostowania, jedno D wcięło w nazwie, bo tam jest MDDV, ale jak na ciemną stronę mocy przystało to wiadomo, że coś tu musiało nie zagrać. Ta ciemna strona mocy to tak tylko z nazwy, bo to jednak rynek poszedł w jakimś kierunku i tak naprawdę jakby się zastanowić, w którym roku pytamy o tą informatykę, to to się za każdym razem nazywa inaczej. 30 lat temu nazywało się outsourcingiem IT, 20 lat temu inaczej, wcześniej SysOps/DevOps, teraz nazywa się jeszcze inaczej. A więc gdzieś to tam ewoluuje pod różnymi nazwami. Tak to wygląda.

Szymon Warda: Dobra, to skoro już nazwę sprostowałeś, to w takim razie opowiedz dokładnie, czym się zajmujecie, żebyśmy mieli kontekst, o czym będzie dzisiejsza rozmowa bardziej.

**Mariusz Dalewski: **Fundacyjnie czy firmowo, czy…

Łukasz Kałużny: Zawodowo.

**Mariusz Dalewski: **Zawodowo w MDDV zajmujemy się szeroko pojętym IT, tak jak mówiłem o tych dekadach. Outsorcujemy segment IT od firm przejmując ich kompetencje w tym zakresie, tworzymy nowe rozwiązania IT, wdrażamy nowe rozwiązania IT, migrujemy ich infrastruktury w każdym możliwym kierunku. Obsługujemy ich infrastruktury bieżące, przebudowujemy, współpracujemy z ich działami developerskimi. To jest tak blisko pojęty zakres naszych prac.

Łukasz Kałużny: Słuchaj, dzisiaj chcielibyśmy Cię pociągnąć za język, trochę rzeczy, bo rzecz, którą robicie, w szczególności przy tej współpracy gdzieś developerskiej, tej części trochę startupowej, produktowej, gdzie pomagacie zbudować infrastrukturę, bo to jest jedna z takich rzeczy, z których Was mocno kojarzę. I słuchaj, bo jedną z rzeczy, którą robicie, to praca poza też tymi dostawcami hyperscale’owymi typu Azure, AWS, Google i co poza tym światem tak naprawdę w dzisiejszym momencie istnieje, jacy dostawcy, rozwiązania? Jak to wygląda?

**Mariusz Dalewski: **Myślę, że… Czy w ogóle rozwodzimy się nad tematem dlaczego ludzie patrzą w tą stronę? Czy to nas nie interesuje? Bo jeżeli ktoś w ogóle w tą stronę spogląda, to tak naprawdę ma świat serwerów dedykowanych, czyli wynajmowanych albo własnych maszyn, czyli coś, co było od zawsze i jest nadal. I patrzę zazwyczaj na to z perspektywy kosztów albo z perspektywy blisko niezrozumianego często compliance. Doskonale wiecie, że compliance często jest tematem podnoszonym w temacie środowisk chmurowych jako wielka i trudna rzecz, a tak naprawdę często działy prawne totalnie nie wiedzą jak się z tym zmierzyć. I wynika to bardziej z niezrozumienia tematu i z tego, że komuś się nie chce zastanowić bardziej precyzyjnie nad tym, albo z bardzo dużych naleciałości w firmach, że my musimy to mieć fizycznie tutaj, itd. W ogóle jak coś zawiera wyraz “cloud”, to nie ma żadnej dyskusji, to musi być fizycznie. Nadal myślę, że jeżeli firmy mają potrzebę redukcji kosztów albo realizacji tych potrzeb compliance’owych w jakiś tam swój sposób, to mają do dyspozycji dzierżawę, serwery dedykowane, własne maszyny gdzieś tam stawiane albo swoje datacenter. Tych dostawców na rynku jest kilku. Zabawne, że oni uważają, że trochę przespali erę clouda i trochę tak jest, bo wszyscy idą do clouda i cloud jest gdzieś jakimś nowym rozwiązaniem. I to też nie jest tak, że my się tego bare metalu trzymamy, bo my wyrośliśmy na bare metalu. Uważamy, że bare metal jest ważny dla pewnych rozwiązań, do pewnych rozwiązań ma zastosowanie, do pewnych nie ma, jest kosztowa, czasami efektywna, czasami się to zupełnie nie nadaje. Jeżeli ktoś potrzebuje totalnie skalowanego środowiska, które ma wzrosnąć z sekundy na sekundę, to nie oszukujmy się, bare metal się nie spuchnie, jeżeli kupimy sobie coś. I teraz z dostawców, nie wiem, wymieniamy tutaj nazwy dostawców?

Łukasz Kałużny: Wiesz co, możemy. Nikt nam za to nie płaci, ale możemy pokazać ten alternatywny świat.

**Mariusz Dalewski: **Z dostawców, myślę, że prym wiedzie OVH, które też szuka tak naprawdę swojego miejsca w świecie cloud i to pięknie pokazuje, to sama zmiana nazwy firmy, że oni zmienili nazwę na OVH Cloud, że nawet serwery bare metalowe nazywają Bare Metal Cloud. I nie wiem czy ktoś potrafi to wytłumaczyć, jakby heheszki heheszkami, ale to się nie kompiluje. Nie da się tego po prostu przeczytać bez uśmiechu. Ja wiem, że oni to tłumaczą, że to jest cloud na dedykowanych maszynach bare metalowych, czyli takie Reserved Instances z AWS-a. To jest jakby produkt marketingowy na maszynach dedykowanych. Ale nadal to OVH bardzo panicznie szuka w mojej ocenie rozwiązań cloudowych i ucieczki całkowicie od metali w stronę rozwiązań alternatywnych dla Azure’a, dla AWS-a. I z takich molochów nadal jest Hetzner. Jest konkurencyjny cenowo i on pozwala nam na robienie podobnych rzeczy. Tylko te firmy, jeżeli ktoś zaczyna od clouda i zaczyna od tego typu rozwiązań, to przyznam szczerze, że to jest trochę jak zderzenie się ze ścianą i to tak biorąc porządny rozpęd. W sensie, ja miałem okazję obserwować rozwój tej informatyki 25 lat i widząc jak te cloudy się tworzą, jak ta technologia powstaje. I teraz jeżeli ktoś wchodzi na nowo w cloudy, to dla niego to jest od razu, może nie to że przyjemne, ale jest to naturalne dla niego środowisko. I nagle jest to sposób myślenia o informatyce. Jeżeli on nagle wchodzi w system bare metalowy, to dostaje obuchem w głowę, czasami. Mamy np. takie sytuacje z naszymi partnerami, że mamy systemy bare metalowe zdesignowane tam 5, 6 lat temu, takie pełne HA, load balancery, wszystko zrobione by the book, bazy danych w replikacji, systemy jakieś tam replikacji danych. Wszystko pięknie, 8, 10 serwerów. I nagle pada pomysł: to przenieśmy to do Azure. I tego się nie da zrobić tak lift and shift, to trzeba przedesignować całe. I oni tego nie rozumieją. I to znaczy, że to dokładnie ten sam problem jest w drugą stronę. Jakby to nie można tego sposobu myślenia cloudowego przenieść do bare metalu. Jakby trzeba myśleć w trochę inny sposób.

Łukasz Kałużny: Posłuchaj, ciągnąć to z Twojej perspektywy, może taki ten wątek, jaki według Ciebie, to bardziej Twoja personalna opinia, jest status tej części dedykowanej w ogóle on-premowej? Bo czy to będzie kolokacja, własna serwerownia, czy jak powiedziałeś dedyki od dostawców do takich rozwiązań? Jak na to Ty patrzysz personalnie i rynkowo?

Mariusz Dalewski: Ja myślę, że jest to niezbędny element i jako rozszerzenie clouda w pojęciu tzw. chmury hybrydowej, czyli systemów uzupełniających chmurę o zasoby stałe, które są bardzo efektywne kosztowo, które są być może zlokalizowane w bardziej efektywnym i efektownym miejscu, które są być może lepiej ulokowane pod kątem wymogów prawnych, lepiej zarządzane pod kątem tych wymogów prawnych. W sensie nie mówię, że one w cloudzie są lepiej albo gorzej, tylko z perspektywy myślenia danej firmy lepiej. Ona sobie myśli, że tak jest lepiej, bo nie potrafi np. zrobić tego inaczej, bo to raczej kwestia umiejętności. Ale koszty to też oczywiście kwestia jest jakiejś tam percepcji, rozmiaru, itd., bo to dochodzą koszty zarządzania. Ale wydaje mi się, że jako rozszerzenie chmury o pewne bardzo tanie zasoby stałe, to to jest rewelacyjne, bo jeżeli w mądry sposób to wykorzystamy, to możemy mieć dużo mocy obliczeniowej tanio pod warunkiem, że nie musimy jej skalować i możemy ponosić stały koszt.

Szymon Warda: Wspominasz właśnie, nazwijmy to taki bare metal, jako rozszerzenie chmury, uzupełnienie chmury w pewien sposób. Ale jak tak patrzymy na to, jak z reguły kojarzy się taki bare metal, to jest takie, że to są maszyny, które ktoś wchodzi przez remote desktop np., konfiguruje ręcznie, to są takie nieucywilizowane po prostu maszyny, na których cały czas chodzi. A jak to wygląda? Czy to obecnie da się ucywilizować? Czy to dalej jest na zasadzie generalnie wyślij maila, żeby mieć maszynę za trzy tygodnie? Bo chmurka jest taką zwinnością, wszystko jest ładnie, można tam ogarnąć. A taki właśnie bare metal to jest takie: ktoś musi przyjść ze śrubokrętem niemalże.

Mariusz Dalewski: Myślę, że ten brak cywilizacji to też takie bardzo dawne lata dziewięćdziesiąte, czyli dostawcy tacy mocno ogarnięci. To oni po pierwsze dostarczają serwery bare metalowe w sekundy i to są prawdziwe wartości. Jeżeli tam nie chcemy jakiś customowych parametrów, czyli bierzemy to, co jest na półce, a to z reguły jest dobre, to naprawdę jesteśmy w stanie dostać nowe bare metale od ręki. Kwestia jakiejś tam instalacji systemu, ale nadal. Nie będę tutaj się opierał na jednym dostawcy. Ale to jest tak, że jesteśmy w stanie po pierwsze zamówić serwer przez API, zainstalować serwer przez API, zainstalować wirtualizator przez API. Bo z mojej perspektywy bare metale nie istnieją bez wirtualizacji. Oczywiście są wyjątki od tej reguły, ale ja się bardzo mocno trzymam wirtualizacji, bo ma ona dla mnie dużo zalet na bare metalach, daje nam większą możliwość kontroli, daje nam jakąś większą możliwość migracji. Jeżeli jesteśmy w cloudzie i mamy jakąś maszynę, to się w ogóle nad tym nie zastanawiamy, że my chcemy ją gdzieś przenieść. Na bare metalu, jeżeli chcemy przenieść się do maszyny z jednego miejsca na drugi i nie chcemy jej powoływać od zera, to warto mieć tą wirtualizację. I teraz dlatego tą wirtualizację według mnie trzeba mieć albo móc taką całą maszynę powoływać od zera as a code. A więc wracając, jesteśmy w stanie powołać całą taką maszynę od zera as a code przez API dostawcy i zprovisionować całą maszynę później do warstwy hypervisora, a później terraformem na poziomie hypervisora zrobić resztę. A więc to nie jest tak, że ten cloud i możliwości as a code cloudowe są jakoś tutaj odmienne strasznie. My jesteśmy w stanie używać tych samych technologii i tych samych funkcji bare metalu. Ja jestem zwolennikiem tego, żeby doprowadzać do pewnej warstwy, do takiej równowagi pomiędzy tymi systemami, żeby te bare metale podciągać do… Jeżeli, nie wiem, mamy farmę EC2 jakichś obliczeniowych w cloudzie, to te bare metale podciągamy sobie do tych wirtualek obliczeniowych i od tego momentu traktujemy te wszystkie maszyny dokładnie tak samo. Zapewniamy tylko warstwy wirtualizacji, zapewniamy warstwę sieci, jakiś router z IPSec do clouda i od tego momentu wszystkie te maszyny mają być dokładnie tak samo traktowane i nas już to nie interesuje, tylko provisionujemy je inaczej. Teraz provisionujemy je przez API Cloud Providera, raz provisionujemy je przez hypervisor do naszego portalu. A więc to absolutnie nie jest siermiężne. To już nie są te czasy, to zupełnie śrubokrętów tam nie ma.

Łukasz Kałużny: Dobra. Wiesz co, to ja sobie przeskoczę do trochę innego pytania, bo wjechałeś w taki ciekawy temat. Zaczynając, jak wygląda w takim razie aktualne operations dla w ogóle rozwiązań, które weźmiemy sobie tak jak mówimy na żelastwie i innych typu rzeczach jak chcesz zrobić to nowocześnie? Bo tu już padło dużo razy słowo właśnie API, traktowanie jak cloud.

Mariusz Dalewski: Trochę zależy jak definiujesz operations. Czy mówisz o warstwie systemu, warstwie aplikacji, warstwie hardware’u?

Łukasz Kałużny: Wiesz co, ja patrzę co masz, system operacyjny do góry. Czyli tak jak mówisz, masz wirtualizator, bo raczej na tej warstwie niższej za dużo się jeszcze… Oczywiście te wszystkie rozwiązania dostały API, ale wygląda jak wygląda w niektórych miejscach. Ale mówię o takiej, porównując pracę, np. Mariuszu jako DevOps wykonujesz jakieś operacje na chmurowych zasobach, powołujesz jakąś infrę pod aplikację. A jak to wygląda jak powiedziałeś, że masz już ten bare metal, jak to w ogóle wygląda też narzędziowo?

Mariusz Dalewski: Jeżeli przyjęlibyśmy takie skromne założenie, że mamy maszynę do cofania w czasie, jesteśmy z jakieś 8 miesięcy do tyłu i VMware nie zrobił tego co zrobił, o czym możemy zaraz porozmawiać, bo to jest też bardzo interesujący wątek, to prawdopodobnie masz VMware’a i do tego VMware’a, na tym WMware pracujesz z terraformem. I to jest Twoje całe operations. Pracujesz tak samo terraformem, jak tarraformem na AWS-ie czy Azure. Just like that. Nie wiem, czy odpowiedziałem na Twoje pytanie, ale to jest ten poziom różnic.

Łukasz Kałużny: Tak, chciałem, żeby to wybrzmiało od Ciebie.

Mariusz Dalewski: Bo to się do tego sprowadza tak naprawdę, że maszyny kreujesz terraformem oczywiście, innymi obiektami. I jak to w terraformie, pomiędzy dostawcami chmur publicznych są różnice w definicji, ale masz takie same problemy, takie same wyzwania, tak samo się zastanawiasz, jak się definiuje dyski i tak samo się zastanawiasz czy możesz podmienić root volume, czy możesz go zeskalować, czy on jest share’owany, czy on jest w tym samym AZ-cie, czy jest na tym samym dysku, czy tam data store? Dokładnie te same problemy, dokładnie te same rozwiązania, w sensie sposób myślenia o tych problemach. Oczywiście na bare metalach nie masz niektórych rozwiązań, bo jeżeli myślisz o bare metalach, to nadal patrząc na chmury, będę pewnie częściej odwoływał się do AWS-a, myślisz o samych EC2. A więc nie masz całego tego zaplecza AWS-owego, tam dysków twardych, które gdzieś tam mógłbyś sobie przenosić, EPS-ów, żebyś mógł je kopiować pomiędzy AZ-tami, itd. Ten Twój bare metal jest taką…

Łukasz Kałużny: Namiastką.

Mariusz Dalewski: Może bardziej nie chodzi mi o to, że namiastką, tylko jest takim samotnym roninem w serwerowni i on z innymi roninami nie rozmawia za bardzo. Teraz jak ten ronin ma jakieś tam zasoby, to on się może komunikować już na poziomie maszyn wirtualnych, które ma. Ale jeżeli chciałbyś, żeby on replikował jakieś dane, dyski, itd., to tu się zaczyna problem. Tu się nagle zaczynają rozmowy o macierzach dyskowych, to olbrzymie koszty, albo jakichś software’owych rozwiązaniach, to na VMware tego nie zrobisz, albo będą bardzo duże koszty licencyjne. A więc trzebaby na tym etapie się zastanowić, czy na pewno warto. Myślę, że to może ograniczać w pewnym sensie użycie jako takie, rozszerzenie chmury, bo czasami nie warto replikować rozwiązań, które mamy gdzieś indziej, bo one mogą być dużo droższe. Można też zreplikować te rozwiązania na warstwie już systemu operacyjnego i to bardzo często się robi w środowisku bare metalowym. No tylko trzeba sobie zadać pytanie, jakie mamy potrzeby i podejść do tego na takiej warstwie patoarchitektonicznej i rozwiązać ten problem w odpowiednio patologiczny sposób.

Łukasz Kałużny: Słuchaj, to może tak, czyli trochę podsumowują, patrząc na to, ten cały stos DevOpsowy od strony narzędziowej za wiele się nie różni, jeżeli na to patrzymy, czyli CI/CD, powoływanie mesh, jakiś monitoring, logi. To jest prawie że ta sama tematyka, jeżeli na to popatrzymy.

**Mariusz Dalewski: **Powiedziałeś logi. I teraz pod hasłem logi może kryć się np. jakiś cloud watch. I teraz jeżeli Ty o logach myślisz o jakiejś usłudze zewnętrznej, to możesz logi wszystkie wysyłać do usługi zewnętrznej. Jeżeli chciałbyś logi z hypervisora oglądać, to będziesz oglądał je w sposób inny. Ale w AWS-ie nie oglądasz logów z hypervisora, bo nawet nie wiesz o ich istnieniu.

Łukasz Kałużny: Nie interesuje Cię ta warstwa, tak.

**Mariusz Dalewski: **Tak, nie interesuje Cię ta warstwa. A więc tak, jeżeli chciałbyś, to co może Cię interesować, a co prawdopodobnie czasami nawet tego nie rozważasz, to to, że jeżeli wdrażasz jakieś rozwiązanie w AWS-ie, to ono często ma szereg różnych integratorów poinstalowanych. Nie wiem, odpalasz EC2, to ona ma tam to config integrator, coś takiego, który pozwala np. na łączenie się IAM-em do SSH. I teraz Ty możesz być nieświadomy tego, że Ty to dostajesz jako dodatek, a na bare metalu to nikt tego za Ciebie nie zrobi. Na szczęście w przypadku maszyn wirtualnych nie ma zbyt wiele takich integracji. Tam nie ma tak, że logi jakieś same wypływają. To nie jest EKS, gdzie bardzo dużo rzeczy się już dzieje samo, że jest dużo tych integracji. Ale trzeba być świadomym tego, że jakieś integracje w przypadku EC2 mogą być. Ale tak, jakby generalizując to oczywiście tak, to to jest ten sam stos. Chcesz używać jakiegoś systemu do logowania to możesz go używać. Możesz też wypychać logi do cloud watcha jakbyś chciał, to żaden problem. Da się to zrobić dokładnie tak samo, jak z EC2, tylko nie z roli IAM-owej, bo Twój bare metal nie jest w stanie się uwierzytelnić do AWS-a, tylko tam będziesz musiał jakoś to wypchnąć przez API Key.

Szymon Warda: Dobrze, a tak cały czas mówimy o wirtualkach i wirtualkach, o takim bare metalu i w tych alternatywnych chmurach i w tych dużych chmurach. Ale wydaje mi się, że nazwijmy to, te alternatywne chmury nie stoją już tylko wirtualkami. Co tam w ogóle jest poza wirtualką? Bo nie oszukujmy się, już coraz mniej chętnie będziemy stawiali maszyny wirtualne, czy to będą dedykowane czy wirtualne, zwirtualizowane, itd. Czy tam są jeszcze jakieś usługi, z których można skorzystać, gotowce?

Łukasz Kałużny: I czy mają sens?

Szymon Warda: Też ważne pytanie.

Mariusz Dalewski: Właśnie i to jest druga część pytania, która trochę wyklucza pierwszą część pytania. Oczywiście, że są. Tylko teraz spójrzmy na to, co się na tym rynku wydarzyło. Mamy trzech głównych dostawców chmur, którzy rozwinęli się wiadomo do jakich rozmiarów. I mamy dostawców chmur, nie wiem którego rzędu, pewnie ktoś to nazwał, ktoś to policzył. I oni przespali trochę. I oni się obudzili, że oni nigdy nie będą takim Azure, AWS. I teraz oni zaobserwowali, że ok, my musimy zacząć dostarczać usługi naszym klientom. Serwisy, a nie serwery, bo oni chcą usług. Oni chcą Prometheusa as a Service, oni chcą Kibanę, oni chcą SQL-a. I teraz jak spojrzymy na to, jak takie firmy wyrastają, to one często mają bare metale, potem mają VPS-y, potem na tych bare metalach w VPS-ach stawiają usługi. To bardzo często idzie bardzo wolno. A taki AWS, ktoś to fajnie powiedział, jakoś czytałem to w tym tygodniu, że to takie firmy, które startują z jakiegoś takiego bardzo dużego legacy, one od razu mogą iść w dobrym kierunku. I one się nie muszą zastanawiać, że one obsługiwały bare metale od 30 lat i mają ten ciężar obsługi tego wszystkiego i one to muszą dalej obsługiwać. AWS nie musiał się w ogóle tym zastanawiać i zaczął wdrażać wszystko od razu jako usługi, a cała inna konkurencja została z tym. I teraz odpowiadając na Wasze pytanie, oczywiście, że tak. Mamy historyczne VPS-y, które w mojej ocenie oczywiście, disclaimer, to co powiem zaraz będzie bardzo krzywdzące i oczywiście, że nie mam racji i oczywiście, że znajdzie się ktoś, kto powie, że to nieprawda, ja się oczywiście pod tym podpisuję, ale VPS-y co do zasady działają na współdzielonych zasobach. One, jak są współdzielone, to zawsze ktoś komuś coś zabierze. Mogą być oczywiście bardzo mało współdzielone, albo mogą być zarezerwowane, ale nadal działamy nie na swojej maszynie. Jak nie działamy na swojej maszynie, to efekt jest taki, że jesteśmy bardziej podatni na jakieś awarie, jesteśmy bardziej podatni na problemy, bo działamy w jakichś tam kontenerach, czy w jakimś tam innym rodzaju namespace’owania, czy w jakiejś tam wirtualizacji. I te technologie mają inne swoje problemy. W bare metalach, w których sami zarządzamy swoją maszyną, mamy dużo większy wpływ na to, gdzie nasze zasoby odpływają i wiemy, że maszyna obok nie zje nam zasobów wtedy, kiedy ich potrzebujemy. A więc mamy VPS-y, które oczywiście, że są, działają, ale w skrajnej sytuacji, o czym się wielokrotnie przekonaliśmy, może się nagle okazać, że nie ma IOPS-ów do odtworzenia bazy danych wtedy, kiedy jej naprawdę potrzebujecie. I nic z tym nie zrobisz. I nie ma ich. Ty masz zrobić restore i leci ten restore i po godzinie restore’a IOPS-y giną. I to nie jest taka technologia jak w AWS-ie, że Ty absolutnie wiesz wszystko, bo AWS charge’uje za wszystko. Ale to ma pewne zalety, bo oni też wszystko muszą mierzyć i wszystko muszą udowodnić. Wiesz absolutnie wszystko w tej materii o swojej maszynie. Jak znikną Ci IOPS-y, to do pewnego poziomu jesteś w stanie powiedzieć: zniknęły mi, bo tu mi zniknęły kredyty, bo tu się dzieje to, bo tu się dzieje tamto, itd. Nie jest to dla Ciebie taki black box. A w wielu takich starszych technologiach VPS-owych to nie są drogie usługi i nikt się tam nie spodziewa tego typu rozwiązań profesjonalnych, to nikt się nie spodziewa jakiegoś wysokiego SLA, takich rzeczy, to oczekiwania też są dużo mniejsze. Więc to jest słabe.

Łukasz Kałużny: Słuchaj Mariusz, a jak ta cała część, idąc za tym, passowa, którą dorzucają ci wszyscy dostawcy?

**Mariusz Dalewski: **Właśnie, kolejny punkt są passy. Te passy są zbudowane gdzieś tam obok i te passy są odpowiedzią na te potrzeby rynkowe. Te firmy bardzo często uczą się dopiero stawiania tych passów. Jakby ok, wszyscy mają prawo robić to dobrze. Ale spójrzmy na czystą matematykę. Ile lat ktoś świadczy passy, to jest ile lat i tyle lat zdobywania doświadczenia. I to tej matematyki tu się nie oszuka. To działa, ale to nie jest często ten poziom jakości. Nie wiem, przykład, bez wymieniania nazw, przykład SLA dla alternatywy dla S3. S3 wiadomo jakie ma SLA i wiadomo co się dzieje jak S3 pada. I teraz dostawcy, ci nie główni, praktycznie wszyscy dają odpowiednik S3, bo to jest jakiś standard rynkowy, musi być, każdy daje. Więc wiecie, tam się zdarzają takie problemy, których w cloudzie takim poważnym, nazwijmy to, dużym, w ogóle byś się nie spodziewał. Np. uploadujesz plik i on się nie pojawia. W ogóle jakby nie rozważasz, że taka rzecz może się pojawić. I teraz pytanie supportu jest takie: jaki dostałeś error? Jakby nie masz w zwyczaju notowania errorów od API, bo traktujesz to tak bardzo bezpiecznie, że jak uploadujesz plik i nie zgłasza erroru, to plik się pojawił, albo coś w tym stylu. Albo API np. nie działa przez 40 minut i jakby odpowiedzią jest to, że dobrze, odejmiemy tam X zł od faktury. Jakby to są tego typu problemy i one wskazują na to, że te firmy się uczą świadczyć te usługi.

Szymon Warda: Tak mi się nasuwa takie proste pytanie. Wnioskując z tego co mówisz, to passy na tych mniejszych chmurach po prostu nie mają większego sensu, bo to jest pchanie się w problemy tak naprawdę? Bo jak słyszę te opowieści, to dla mnie to nie ma żadnego sensu.

Mariusz Dalewski: To jest, nie chciałbym skrzywdzić absolutnie wszystkich, bo na pewno są dobre passy. Na pewno znam ekipy, które robią te passy, one na pewno w wielu warunkach działają. Ale tak się zdarza, że passy u głównych dostawców chmurowych, z których korzystamy bardzo dużo… No ok, jakby DNS-y w AWS-ie, nie znam bardziej rozwalonej usługi, jeżeli zacznie się ją sprawdzać, niż DNS-y w AWS-ie. Tylko, że mało kto ją sprawdza. I oni chyba o tym wiedzą i non-stop ją flapują. A jak zacznie się to sprawdzać, to się okazuje, że non-stop nie działa. Ale inne usługi naprawdę są dużo wyższej jakości. I teraz te passy, zauważcie, że te wszystkie firmy, one patrzą na takiego AWS-a, Azure’a czy GCP-a i one widzą, że muszą te passy robić. A więc one pracują nad jakością tych passów, one dodają nowe passy. A więc to nie jest tak, że te usługi są na pewno złe. Ja też nie przetestowałem wszystkich tych usług. My, jako zespół, ludzie, z którymi ja pracuję, znam, itd., więc absolutnie nie mogę się wypowiadać na temat wszystkich, ale znam dużo tych usług i naprawdę z wieloma tymi usługami coś jest nie tak. Dlatego my osobiście, jeżeli korzystamy z dostawców metalowych, to takie rzeczy wdrażamy sobie sami, bo za nie jesteśmy w stanie ręczyć przed naszymi klientami. Jeżeli potrzebujemy wdrożyć object storage, to wdrażamy sobie bare metale, VMware’a MinIO i jedziemy. Ja się nie zastanawiam, że mi padnie object storage od dostawcy, za który powiedziałem: jest, działa, a później świecę oczami, że to nie jest S3, bo S3 ma SLA-a, a tutaj dostawca powiedział, że działa, a później pół godziny nie działało i kurcze każdy jest zdziwiony i jeszcze plików nie ma.

Szymon Warda: Ok, a z takich, bo mówimy o passach, passach, a usługi zarządzane, mianowicie mówiąc prosto tak naprawdę zarządzany Kubernetes, bo to jest taka usługa, która sensownie ok, to jest taki poziom automatyzacji, który wydaje mi się, że z nim można pracować, jest dość łatwy, jest to Kubernetes, tylko w trochę innej odmianie smakowej, powiedzmy sobie. Jak to wygląda?

Mariusz Dalewski: No to otwierasz puszkę Pandory, proszę bardzo.

Szymon Warda: Wiem, specjalnie.

Mariusz Dalewski: Kubernetes, dostawcy Kubernetesa np. wymyślili sobie, tacy mniejsi dostawcy passowi, że np. IOPS-y w Kubernetesie nie są potrzebne. I że np. dysk dla workerów, ten dodany do maszyny głównej, tworzysz sobie workera, dodajesz sobie, czy tam node’a, wiadomo o co chodzi i on przychodzi z jakimś tam głównym dyskiem i on ma jakieś tam IOPS-y. Jak dodasz do niego drugi dysk, jakby nie masz innej opcji, możesz dodać drugi dysk. Ten drugi dysk np. nie ma już takich IOPS-ów jak ten pierwszy i też nie masz wyboru, nie masz wpływu. I nagle się okazuje, że ten Kubernetes po prostu na tych IOPS-ach nie działa, a nikt tego nie przetestował, nie wie. I teraz te firmy widzą, że jest Kubernetes, że trzeba, ale totalnie gubią się we wdrażaniu tych technologii. Oni bardzo chcą to robić, ale te rozwiązania często bywają siermiężne, albo bywają… Widać, że tam jest problem wieku dziecięcego rozciągnięty na lata. O, to jest dobre określenie.

Szymon Warda: Jeżeli byśmy bylibyśmy w OVH i chcielibyśmy Kubernetesa, to to co mówisz, to jest: postawmy sobie go sami i sami nim zarządzajmy, bo trzymanie go jako usługi zarządzanej przez jakąś mniejszą chmurę po prostu, oni się dopiero uczą i nie ma co za bardzo uczyć się z nimi.

Mariusz Dalewski: Pomidor. Mamy w OVH Kubernetesy na bare metalach. Wiecie, to to nie jest EKS, jakby to nie są te usługi. Ja też kiedyś patrząc na to, jak się EKS rozwija, to EKS na początku też był słaby i jeszcze brali za niego kasę. Ale ciężko było to uargumentować. Ale teraz to zaczyna naprawdę przyjemnie śmigać i zaczynają nawet doganiać Googla w niektórych funkcjach, co naprawdę, w tych złych też zaczynają ich doganiać niestety. Czyli upgrade’owanie na siłę niektórych rzeczy albo pobieranie kasy. Ale to ponownie, jeżeli chcesz mieć większą kontrolę nad tym wszystkim, to… Np. Digital Ocean, o, to jest dobry case, mamy klientów, którzy środowisk developerskich, stagingowych, trzymają Kubernetesy w Digital Ocean ze względu na cenę. Normalnie swoje środowiska mają w GCP-ie i jakby nie stać ich na to, żeby odpalić sobie te środowiska deweloperskie w GCP-ie tak just like that, ale w Digital Ocean jest spoko i to im wystarczy na potrzeby deweloperskie. Ale w tym roku produkcję wdrażamy na Kubernetesie w GCP-ie. I tutaj to oni są tym usatysfakcjonowani. A Kubernetes jest o tyle wygodny, że tam jest bardzo duża warstwa abstrakcji na wszystkim, a więc oni… Jeżeli to działa, to nie da się na tym popłynąć, pod warunkiem, że dostawca tego wybitnie nie skopał. Czyli tutaj ten wyraz “działa” i “skopał” należy bardzo mocno zaakcentować. My u jednego dostawcy mocno popłynęliśmy na wdrożeniu przez IOPS-y, bo się okazało, że po prostu bazy danych, które gdzieś tam były, a klient sobie zażyczył, bo to było środowisko deweloperskie też, że deweloperzy mają powoływać bazy danych i one tam mają się jakoś provisionować, fiksturki jakieś, maile, itd. Te IOPS-y ginęły po prostu, bo dostawca założył, że worker zapomniał o IOPS-ach tam, nie wiem, ptaszka nie zaznaczył: dodaj IOPS-y do Kubernetesa. Jakby ich nie było.

Szymon Warda: To żeby urealnić, bo co raz mówimy, że te chmury mniejsze, dlatego, że koszty, taniej, itd. Jak bardzo taniej? Tak, żeby dać skalę osobom, które nas słuchają. Ile można zaoszczędzić mniej więcej?

Mariusz Dalewski: Ile można zaoszczędzić? Jak robimy cenniki w drugą stronę, to z reguły… Bardzo nie chcę powiedzieć “to zależy”, bo doskonale wiecie, że to zależy. Ale może najpierw powiem od czego to zależy. Po pierwsze, musimy porównywać gruszki do gruszek, śliwki do śliwek. Czyli jeżeli będziemy porównywać środowiska nieporównywalne, typu nie wiem, jakieś passy, jakieś wyuzdane usługi w AWS-ie, itd. do środowisk barr metalowych, to jest nieporównywalne. Jeżeli byśmy porównywali same maszyny do maszyn wirtualnych, itd., to tu się to robi bardzo ciekawe, bo mieliśmy projekty, w których obcinaliśmy koszty z 20 tys. dolarów do 8. I to wynikało z konkretnej architektury klienta zbudowanej w konkretny sposób i jakby klient wylądował z architekturą hybrydową. AWS jest do tego, żeby był w tym, w czym jest mocny, a dedyki były do tego, żeby były w tym, w czym one są mocne i w cenie, i w zasobach, które są w stanie w tej cenie dostarczać. Jeżeli chodzi o liczenie w drugą stronę, to ja gdzieś w głowie zazwyczaj we wstępnych rozmowach z partnerami stosuję mnożnik, że razy 4. Czyli jeżeli płacisz za serwery teraz w OVH np. X, to jak masz myśleć o OVH, o AWS-ie, to licz się z kosztem razy 4, tylko to są takie wstępne rozmowy, żebyś… Oczywiście one pewnie będą mniejsze, bo ten koszt, który podałem, to nie jest razy 4, ale chodzi o rząd wielkości, żeby w ogóle wiedzieć o czym rozmawiać, żeby się nie okazało, że my zaczniemy rozmawiać o migracji, a klient powie: o Jezu, to ja nie wiedziałem. To jest mniej więcej tego typu różnice finansowe.

Szymon Warda: Takie wylanie kubła zimnej wody: czy jesteś na to przygotowany po prostu?

Mariusz Dalewski: Tak, tak, tak, tak. I to celowo, bo wiele razy mieliśmy takie sytuacje: bo ja chcę AWS-a. To robimy AWS-a i wysyłamy link do kalkulatora i nagle jest: uuuu, a możemy połowę tych zasobów obciąć? A to zależy ile ma pan szczęścia w utrzymaniu infrastruktury, bo wtedy całość opiera się na szczęściu, a nie na architekturze albo na ilości studentów, którzy klikają restart cały czas.

Szymon Warda: Tak też można. Ale dobra, ok, bo właśnie próbuję przypomnieć sobie taki przypadek, use case dla użycia, bo cały czas mówimy o kosztach, to jest najbardziej oczywistym, szczególnie jak już mamy mniej więcej tą skalę wielkości. Trochę wspominałeś o tym, że powiedzmy kolokacja danych, jakieś tam rzeczy compliance’owe mogą wystąpić. OK, a są jeszcze jakieś inne argumenty czemu pójść w te mniejsze chmury? Jakieś takie czemu się firmy na to decydują? Możesz powiedzieć po prostu, że nie, to też jest dobra odpowiedź, to będzie.

Mariusz Dalewski: Właśnie wiesz, leci teraz w głowie seria IF-ów, na końcu jest odpowiedź echo: nie, jeżeli nie wyjdzie. Nie wiem, czy znam inną odpowiedź na to pytanie niż koszty. Bo spróbujmy na to odpowiedzieć w inny sposób. Chmura jest znacznie lepsza, jeżeli chodzi o skalowanie. Chmura jest znacznie lepsza, jeżeli chodzi o zakres usług. Chmura jest znacznie lepsza, jeżeli chodzi o łatwość zarządzania. Ale z drugiej strony też wymaga dużo większych kompetencji. I teraz ktoś może chcieć korzystać z bare metali głównie tak naprawdę ze względu na te koszty, albo ze względu na to, że nie rozumie, że nie może pokonać swojego compliance, że nie może pokonać tego zastępu prawników, z którym współpracuje, że nie ma dobrego działu prawnego, który byłby w stanie wytłumaczyć działowi prawnemu swojego klienta, że wyraz cloud nie oznacza, że jego dane znajdą się, będą publiczne gdzieś tam, tak. Szczerze myślę, że teraz to są jedyne argumenty, że nie ma już innych, tylko prawne i tylko finansowe.

Szymon Warda: Jasne.

Łukasz Kałużny: Jeszcze o jednym ukrytym koszcie tych rozwiązań, bo jak powiedzieliśmy sobie, że jest… Mamy warstwę w chmurze passową, weźmy np. jakiegoś RDS-a czy jakiś blob storage jak S3. Jak ma się utrzymanie potem tego lokalnie? Tak zupełnie z praktyki, jak duży jest, bo rozmawiamy o koszcie infry do infry, a tak jak powiedziałeś nie porównasz sobie jabłek do jabłek, gruszek do gruszek I jak bardzo jest to duży narzut potem, jeżeli to jest jakiś rozwijany soft, rozwijane rozwiązanie, jak bardzo jest to narzut, Twoim zdaniem, względem tego, że tam jest usługa typu manage, a tu jednak musisz zarządzić tym samodzielnie i żeby było up-and-running? Czy to jest zauważalna różnica? Czy można porównać, że tu męczymy się z dostawcą chmurowym, a tu po prostu męczymy się ze swoimi rzeczami?

**Mariusz Dalewski: **Myślę, że to prędzej Gartner byłby w stanie wyliczyć niż ja, ale spróbuję.

Łukasz Kałużny: Bardziej pytam o obserwacje, bardziej Twoje obserwacje patrząc się na całokształt, kiedy świadczycie taką usługę.

**Mariusz Dalewski: **Dawno temu, jak te usługi passowe się pojawiały, to panował taki nurt, że usługi passowe utrzymują się same, nic nie trzeba robić i w ogóle, klikasz i zwalniasz DevOpsów. A w ogóle w GitLabie jest taki checkbox “auto DevOps” i jak go zaznaczysz to już możesz zwolnić wszystkich. Teraz chyba jesteśmy już w trochę innych czasach i ta świadomość jest dużo większa, że usługi passowe jednak pomimo tego, że są takie świetne, to jednak wymagają utrzymania. To utrzymanie wygląda trochę inaczej i wydaje mi się, że wymaga ono mniej czasu, ale też wymaga innych kompetencji i dlatego ciężko jest je porównać. I problemem może być paradoksalnie wiedza. Bo żeby utrzymywać passy, musielibyśmy spojrzeć na rynek kadrowy, na różne pokolenia, kto jaką ma wiedzę, kto kiedy wchodził w informatykę i z jaką wiedzą startuje i w jakim zakresie chce się rozwijać. Ja mam trochę lat doświadczenia i patrzę na to trochę ze swojej perspektywy. Ale jeżeli spojrzymy na osoby, które zaczynają przygodę z informatyką kilka lat temu, to zupełnie nie mają wiedzy na temat utrzymywania systemów informatycznych tak od podszewki. I dla nich utrzymywanie systemów baz danych na przykładzie AWS-a może od zawsze oznaczać utrzymywanie RDS-a, żeby był aktualny, że miał backupy, że miał certyfikat, żeby miał jakiś tam, żeby był taki click ops albo jakiś terraform, czy coś w tym stylu. I teraz ta wiedza z zakresu utrzymania tego na poziomie systemu operacyjnego, ona paradoksalnie zanika. Może się okazać i ja to też obserwuję, że osoby, które mogą mieć bardzo wysokie kompetencje z zakresu cloudowego, one paradoksalnie nie wiedzą, jak dotknąć systemu operacyjnego, żeby go utrzymać w należyty sposób. I to trochę zależy od tego, jakim zespołem dysponujemy. Bo jeżeli mamy zespół z kilkunasto, kilkudziesięcioletnim doświadczeniem, to utrzymanie baz danych czy odpowiedników typu mini o tym podobnych, to jest żaden problem. To jakby utrzymanie czy passa, czy utrzymanie tych usług na bare metalu, to jest to samo. Ale dla osoby, która ma trochę inny wachlarz kompetencji, to może być problem. Jeżeli spojrzymy na to, że się starzejemy, że umieramy i to jest nie do zatrzymania, to chyba jednak taniej w chmurze.

Szymon Warda: Już teraz wiem czemu ta ciemna strona mocy.

Łukasz Kałużny: Szymon, też się z niej częściowo wywodzisz.

Mariusz Dalewski: Pokolenie Z jakby to teraz programuje w Cobolu, no ludzie.

Łukasz Kałużny: W naszym też mało kto.

Mariusz Dalewski: Dlatego wydaje mi się, czy byśmy chcieli, czy byśmy nie chcieli, to jest jedna z rzeczy, które ja się na studiach dowiedziałem i bardzo sobie studia za to cenię, trzeba bardzo mocno przeć do przodu, jeżeli chodzi o wiedzę i o pilnowanie tego, żeby nie być wykluczonym technologicznie. I nie chodzi o nasze mamy, nie chodzi o naszych rodziców, bo to też ważne, ale też chodzi o informatykę, żeby się nie zamykać w swojej strefie komfortu i uważać, że jest mi tutaj, w tym miejscu dobrze i ja dostosuję cały świat do siebie, bo ten świat się nie zatrzyma i on nie dostosuje się do nas. Tylko z bólem próbować iść do przodu, bo na pewnym etapie, za rok, dwa, pięć obudzimy się w sytuacji, że ten świat już jest 5 lat dalej, a my nadal uważamy, że nasze przyzwyczajenia były najlepsze i nikt sobie z tego nic nie zrobił. Dlatego wydaje mi się, że ta wiedza z zakresu utrzymania niskopoziomowych systemów gdzieś na jakimś etapie powoli będzie zanikać. Nie byłoby dobrego podcastu bez użycia wyrazu AI, który pewnie też w jakimś zakresie może to pomoże. Ale też w naturalny sposób, jakby naprawdę śmiejemy się z umierania trochę, ale też te kompetencje gdzieś tam będą też zanikać, będą się przenosić w inne miejsca, te systemy będą coraz bardziej obudowane. Bo rzeczywiście pod takim RDS-em jest to zwykły system, tylko jest utrzymywany masowo i na pewnym etapie już nikogo to nie będzie interesowało, co tam jest pod spodem, a więc kompetencyjnie będziemy mieli gdzieś kiedyś pewnie problemy z utrzymaniem systemów operacyjnych, tych niskopoziomowych.

Szymon Warda: To ja w takim razie wrócę, bo wobec tej takiej ciemniejsze strony, o której mówimy, bo mówiliśmy o tym, że ok, wszystko fajnie, fajnie, z tych passów, mniejszych chmur może niekoniecznie warto korzystać, bo to inni się dopiero uczą, więc weźmy sobie po prostu wirtualki i postawmy sobie własne systemy, sami za nimi odpowiadamy, jak nie działa, to wiemy co nie działa. Ale teraz w kontekście tego, co Ty mówisz, to mi się nasuwa takie proste pytanie: ok, czy warto? Bo faktycznie cenowo zaoszczędzamy, tak, jest taniej, ale w tym momencie płacimy za kompetencje, które musimy mieć, żeby systemy utrzymać, żeby one działały. Więc czy te kalkulacje się… Komu się ona opłaca? Dużym korporacjom? Małym firmo:m? Średnim firmom? U kogo warto zrobić kalkulację, że ok, może część maszyn przeniosę np. na OVH, żeby zmniejszyć koszty np.? A kto nawet powiedziałby, że nie warto, w ogóle nie myśl o tym? Po prostu nie tędy droga, nie zaoszczędzisz finalnie.

Mariusz Dalewski: Myślę, że to nie jest pytanie u kogo, tylko pytanie w jakich systemach. Że warto? Warto u każdego, bo kto, to raczej wskazuje na skalę. Duże korporacje będą miały bardzo dużą skalę, jeżeli u nich to warto zrobić. Małe firmy będą miały małą skalę. Warto to zrobić w systemach, w których łatwo jest to wdrożyć bez właśnie ponoszenia jakichś szczególnych kosztów. Czyli np. jak mamy potrzebę, nie wiem, liczenia czegoś cały czas w jakichś bardzo określonych warunkach, że potrzebujemy cały czas procesory non-stop do liczenia jakichś rzeczy, jakieś konkretne procesory i wiemy, że w AWS-ie one kosztują tyle, a w OVH, który powiedziałeś, kosztują tyle i wiemy, że potrzebujemy je cały czas, cały miesiąc, bo serwerów nie kupimy na minutę. Oczywiście są jakieś tam warianty, to już kwestia marketingu i nie będziemy szczególnie wyważać otwartych drzwi. Czyli ten overhead na wdrożenie całej tej technologii nie będzie jakiś szczególnie duży. Czyli postawimy ten serwer, postawimy wirtualizację, wdrożymy VM albo nawet bez tej VM, czysty metal spinamy tunelem albo jakąś tam naszą wewnętrzną technologią i on już liczy, to to jest miejsce, że ten overhead nie przerasta tych kosztów pozostałych i zaczynamy oszczędzać. Tu myślę, że warto. Bardziej chodzi o rodzaj rozwiązania, a nie gdzie. W dużych firmach zaoszczędzisz po prostu dużo więcej. Tutaj po prostu trzeba spojrzeć na to, które rozwiązanie potrzebuje np. stałej mocy obliczeniowej, albo które rozwiązanie potrzebuje jakiegoś rodzaju np. cache stałego, jakiegoś backupu, że np. dane chcemy gdzieś składować, a w cloudzie one mogą być drogie, albo jakiś rodzaj przechowywania danych, albo jakiegoś offloadowania ruchu, czy coś w tym stylu. To myślę, że bardziej trzeba myśleć o ramie i procesorze, w tym kierunku bym patrzył, niż jakichś innych usług.

Szymon Warda: Ok. A w takim razie załóżmy, że komuś faktycznie, ktoś stwierdził, że chce w to wejść, po prostu chce spróbować. Od czego polecasz, od czego zacząć, co zrobić, jak jest pierwszy, drugi czy trzeci krok, jak np. zna OVH albo powiedzmy Digital Ocean?

Mariusz Dalewski: Ponownie będę używał AWS-a jako przykładu. Z mojej perspektywy ważne jest, żeby tych metali nie traktować w jakiś szczególny sposób, bo to się przestanie opłacać. Więc na przykładzie z drugiej strony, w OVH odpalamy sobie instancję bare metal, zamawiamy sobie serwer bare metal, instalujemy na nim system albo goły, typu jakiegoś tam Linuxa, albo właśnie ten wirtualizator, nieszczęsnego VMware’a, albo jakiegoś innego hypervisora. Myślę, że spinamy VPN-a z cloudem. To już zależy od tego jakie mamy potrzeby co do bezpieczeństwa, jakiej technologii używamy. Bo jeżeli prowadzimy jakieś obliczenia, chcemy przesyłać jakiś ruch, to kwestia jest tego co z szyfrowaniem danych w spoczynku, w tranzycie, czy musimy się tym przejmować czy nie. W OVH możemy też stworzyć odpowiednik takiego VPC, to się nazywa vRack, więc możemy sobie zrobić na serwerze taki router, spiąć się z tym routerem VPN-em i wtedy zacząć traktować nasze wirtualki na serwerze dedykowanym w OVH tak jak EC2 w AWS-ie. I potem już nie myśleć o nich w żaden szczególny sposób. Po prostu mamy adresację po lewej w AWS-ie, adresację po prawej w OVH, już korzystamy z nich dokładnie tak samo, kwestia tylko powoływania. W AWS-ie powołujemy przez CLI-a AWS-a, a tutaj przez terraforma do VMware’a, albo jakieś skrypty do innego hypervisora, którego sobie zażyczymy.

Łukasz Kałużny: Słuchaj, to może teraz polećmy sobie jedną rzecz, trochę powiedziałeś osiem miesięcy wstecz i VMware. My też parę razy już w naszych shortach to męczyliśmy i też widzimy ten problem na rynku. Właśnie, teraźniejszość i przyszłość tego, co widzisz właśnie w tej części całej, że tak powiem, dedykowanej onpremowej versus właśnie jak leci zainteresowanie i co te technologie zmieniają?

Mariusz Dalewski: Rozumiem, że słuchacze wiedzą, co się wydarzyło i tu się syncować nie musimy.

Szymon Warda: Możesz w 5 słowach przybliżyć.

Łukasz Kałużny: Tak, jednym zdaniem to przybliżyć.

Mariusz Dalewski: Broadcom kupił VMware’a 3 i zaorał 5. W każdym razie zlikwidował licencje darmowe, licencje płatne przemnożył razy 4, czasami razy 8, czasami więcej, zlikwidował kilkaset różnych systemów, kilkaset różnych produktów, systemów licencjonowania ujednolicając te systemy. Zlikwidował program partnerski, potem nawiązał nowy, zlikwidował współprace, potem nawiązał nowe. Nikt nic nie wie, nikt nie wie jaka jest przyszłość, a co najważniejsze, bo w sumie nie wiem, czy to powiedziałem, zlikwidował darmowego VMware’a i zlikwidował też najniższego komercyjnego VMware’a. I teraz jakie są tego konsekwencje? Konsekwencje są, jeżeli spojrzymy z perspektywy udziałowców Broadcoma, wspaniałe akcje Broadcomu, po prostu wystrzeliły do góry. A z perspektywy rynku IT już to tak różowo nie wygląda. Bo tak, środowiska akademickie, które się uczyły na VMware od lat, może będą mieli jakiś program akademicki, ale jako że VMware’a darmowego nie ma, to pozamiatane wszystko. Zrobili to na tyle perfidnie, że usunęli darmowego OSX-a wstecznie. Skasowali trzy wydania darmowe wstecznie i unieważnili wszystkim darmowe licencje wstecznie. Każdy kto miał darmowe licencje na koncie, to już je stracił. Jeżeli nie miałeś skopiowanych tych kluczy, to już ich na tym koncie nie masz. I teraz to był jeden z głównych hypervisorów, który był…

Łukasz Kałużny: Najpopularniejszy.

Mariusz Dalewski: Tak, zarazem był najniższego rzędu, który mógł być Enterprise’owy, jeżeli zakupiłeś licencje Enterprise’owe, był zarazem najpopularniejszym, jeżeli chodzi o rozwiązania Enterprise’owe takie najwyższe. A więc jeżeli wchodziłeś w VMware’a, to mogłeś i od niego zacząć i na nim skończyć, w zależności od rozmiaru firmy. Mogłeś być najmniejszą firmą na świecie i największą, nie miało to znaczenia. I teraz problem jest taki, że nie możesz zacząć od VMware’a, bo już nie jest darmowy. Te licencje stare to trzeba by się z prawnikiem skonsultować, ja jeszcze nie mam jakiejś twardej opinii na ten temat. Te klucze technicznie rzecz biorąc działają. Czy używanie ich teraz jest legalne? To nie wiem. Te obrazy ISO, jak ktoś ma w folderze downloads na komputerze, to one też działają, ale już ich pobrać się nie da. Pierwsze licencje komercyjne, które były całkiem fajne i które kosztowały tam kilka tysięcy dolarów, one już kosztują razy 4. Więc jeżeli robiło się wdrożenie za 2 tys. dolarów, to teraz kosztuje to 8 tys. dolarów. I co najfajniejsze, to 2 tys. dolarów to było jednorazowo + opcjonalny support, który tam kosztował ileś co roku, opcjonalny, bo licencję miałeś lifetime.

Łukasz Kałużny: Wieczystą.

**Mariusz Dalewski: **Tak, a teraz te 8 tysięcy dolarów to jest co roku, bo co po roku produkt zakładamy, że się wyłączy, bo to jest subskrypcja na rok tylko. Więc VMware tak naprawdę napędził rozwój Proxmoxa w olbrzymi sposób. Ja tak prywatnie szczerze mówiąc nie mam jeszcze rozwiązania tego problemu. Pojawiło się kilka różnych rozwiązań alternatywnych wcześniej, typu Nutanix. Za Proxmoxem nigdy nie przepadałem, Hyper-V nienawidzę i nie wiem. VMware’a używałem od wielu lat, znaczy używałem tych wszystkich, to nie jest tak, że Hyper-V nie używałem, mam. A mam też zdanie wyrobione jakby na temat każdej prezentacji.

Łukasz Kałużny: Nie preferujesz.

**Mariusz Dalewski: **Tak, ale z jasnych powodów. I tak samo teraz muszę wybrać któryś i nie ma na razie na rynku jakiegoś takiego produktu, który by tak dobrze spasował się jak VMware. I to jest problem. To jest bardzo duży problem, bo gdybyśmy rzeczywiście rozmawiali tam, nie wiem, te 8 miesięcy temu, to sytuacja wygląda banalnie. A teraz? Ja nawet nie wiem szczerze mówiąc, bo nie sprawdzałem, ale zakładam, że dostawcy chmurowi dają możliwość reinstalacji na VMware’a tego darmowego jeszcze, bo nie wycofali, bo on był darmowy, jest, itd. Ale tych kluczy licencyjnych teraz nie dostaniesz, tych darmowych. Te darmowe klucze licencyjne są dostępne w internecie, ale mówię, to jest… Nie wiadomo czy to…

Łukasz Kałużny: Jest problematyczne.

**Mariusz Dalewski: **Tak, to jest problematyczne prawnie i należałoby rozważyć, czy to jest legalne czy nie. A zakupienie tych kluczy to są horrendalne koszty z perspektywy tego, że produkt był darmowy do jakiegoś tam mikro poziomu i ten poziom nie był taki mały, bo on pozwalał na uruchomienie jednej maszyny do ośmiu CPU. A więc jeżeli nie planowałeś postawić wirtualizacji po to, żeby odpalić jedną VM-kę ze wszystkimi CPU, które są na maszynie, to Ty tej licencji tak naprawdę mogłeś w ogóle nie potrzebować. Bo jeżeli Ty odpalasz wirtualizację po to, żeby odpalić jedną VM-kę, to błąd prawdopodobnie popełniłeś wcześniej. Ale jeżeli planowałeś odpalić, nie wiem, 20 VM-ek, to pewnie nie chciałeś odpalać więcej, bo i tak jakieś ha i tak masz więcej tych serwerów niż jeden itd. Więc zaorali, zaorali rynek bardzo mocno i pewnie z rok, dwa, trzy i VMware w mojej ocenie może tracić palmę pierwszeństwa w Enterprise’ach. W cloudach się cieszą, w Proxmoxie szampany otwierają.

Łukasz Kałużny: Nutanix pewnie też, jako że całe appliance też w tym.

Mariusz Dalewski: Wszyscy inni dostawcy hypervisorów się cieszą. Vim, który zawsze był z VMware’em mocno połączony i z Hyper-V, jak tylko zaczęły się cyrki z Broadcomem napisał: przymierzamy się do zrobienia wsparcia dla Proxmoxa. A był taki produkt, nie pamiętam nazwy teraz, nie chcę przekręcić na wszelki wypadek, który opierał się na tym, że dostarczał backup dla rozwiązań takich dla których Vim nie dostarcza, czyli dla Proxmoxa np. I nagle te roszady na rynku spowodowały, że absolutnie wszyscy płaczą. Jakby Vim musi dorabiać support dla Proxmoxa, tamci nagle mają Vima w swoim bucket’cie. Nikt nie ma VMware’a. Po prostu nie ma się z czego cieszyć i pewnie jeszcze długo nie będziemy. Nie wiem czy Wy już coś wybraliście, myślicie, macie jakieś zdanie, ale dla mnie osobiście to dramat.

Łukasz Kałużny: Wiesz co, zdanie jesteśmy ciekawi, patrzymy też na klientów w tym momencie, bo to jest takie i ciekawe decyzje. Raczej moim zdaniem najgorzej mają dostawcy, ci hostingowi, którzy dostarczali VM-ki na VMware jako Enterprise Private Cloud z licencjami, tam mają najgorzej, bo ceny chyba urosły tam najbardziej.

Szymon Warda: Ceny Private Cloudów na VMware…

Łukasz Kałużny: Urosły.

Mariusz Dalewski Mamy podstawy sądzić, że urosły albo urosną.

Łukasz Kałużny: Raczej gdzieś w pierwszych wyliczeniach dla małych widziałem, bo tam się już trochę wylało, że czterokrotnie. Więc to będzie. A z ciekawości, jak jesteśmy przy trendach i poruszyłeś ten wątek: odpalanie VM-ek na Kubernetesie. Już na to patrzyłeś czy nie?

**Mariusz Dalewski: **Nie patrzyłem i tak samo jak nie patrzyłem na swap Kubernetesie. Dla mnie to są rzeczy, które nie powinny mieć miejsca. Tam na pewno w Kubernetesie ktoś się przekręca i mówi: nie po to wymyślałem Kubernetesa, żeby takie rzeczy robić. Jakby nie, nie patrzyłem i nie do końca czuję, czy to jest dobry kierunek rozwoju dla tej platformy. Myślę osobiście, że chyba próbują za dużo…

Łukasz Kałużny: Upchnąć.

**Mariusz Dalewski: **Za dużo upchnąć, za dużo złapać i ten swap jest tego trochę idealnym przykładem, bo nie wierzę, że nie zaimplementowali swapu od początku, bo nie umieli, bo to jest Google, tylko oni bardzo świadomie podeszli do tematu: u nas nie ma swapu, bo swap to zło. I nagle stwierdzili: dobra, to my już zaimplementowaliśmy swap po 5 latach, to teraz, czy tam nie wiem, po 8, to teraz będzie swap. I tak, nie, tam się jakieś zmiany dzieją, które raczej są w mojej ocenie negatywne, ale to czas pokaże. Jakby może, może ja też zmienię zdanie. Nie, nie sprawdzałem VM-ek na Kubernetesie.

Łukasz Kałużny: Bo jak o tym rozmawiamy, bo ja teraz patrzę tak na tej zasadzie, że Red Hat inwestuje w VM-ki na OpenShift’cie, jak popatrzysz, jako alternatywę dla ich Red Hat Virtualization, która była. Dlatego zadałem to pytanie.

**Mariusz Dalewski: **Tylko, że jak się nad tym zastanowić, nie researchowałem tego mocno, jak się trochę nad tym zastanowić, dlaczego Red Hat może to robić, to polityka jest odpowiedzią pewnie na to pytanie. A polityka zazwyczaj jest słabym doradcą technologicznym, więc pewnie nie warto się tym interesować. Bo jeżeli coś jest driven by i tu wstawiasz “polityka”, to pewnie nie warto. Przy czym jak mówię nie czytałem, nie interesowałem się do końca, ale tak to wygląda z Twojego opisu.

Łukasz Kałużny: Dobra. To chyba będziemy zamykać już dzisiejszy odcinek.

**Mariusz Dalewski: **No dobrze, dziękuję Wam bardzo.

Szymon Warda: Dzięki wielkie.

Łukasz Kałużny: Dzięki, trzymajcie się, na razie.

Mariusz Dalewski: Cześć!