CTO Morning Coffee

Dziś jest bardzo pochmurny dzień, to będziemy szukać jak znalazł.

Właśnie miałem chwilę.

Nie wiem, czy dobry to się zobaczy, bo właśnie szukałem swojego telefonu po domu, żeby to zacząć.

Sucha rozrania jak śmietana.

Ale ekosystem Apple jednak pomaga.

Dobrze, żeby nie mawać czasu.

Słonecznie.

O kurde, zapraszam.

Cześć Wojtek.

Cześć, cześć.

Słuchajcie, to żeby nie marnować czasu, widzę, że wszyscy dołączają, więc ja w międzyczasie, proszę, standardowali Tania.

Czyli tak, to jest CTO Morning Coffee, czyli nasze co dwutygodniowe spotkania, gdzie rozmawiamy sobie o tematach dla senior technical leaders i tych aspirujących właśnie do tego typu ról.

Dzisiejszy temat jest mocno meteorologiczny, porozmawiamy sobie o chmurze, ale nie chmurze z perspektywy deweloperskiej, tylko chmurze.

W tym temacie powiemy już bardzo dużo, postaramy się dzisiaj ruszyć ten temat o troszeczkę mniej zwiedzanej strony.

Czy nam kto będzie, to też zależy od Was.

Nasze spotkania trwają godziny.

W ramach tej godziny rozmawiamy sobie w pełnym gronie.

To znaczy, że każdy może zabrać głos, każdy może, jak to się mówi, podnieść łapkę, bo jest w aplikacji Twittera funkcjonalność, gdzie sygnalizujecie, że chcecie zabrać głos i my jako tutaj trzech moderatorów Wam takiego głosu udzielamy.

Jeżeli Was nie zauważymy, nie zauważymy tego, że chcieliście ten głos zabrać, nie zmieniacie się, postaramy się być czujni.

Jeżeli chodzi o naszą dyskusję, to no tak, staramy się zachować taką zdrową dozę profesjonalizmu, czyli nie krytykujemy konkretnych osób, nawet nie krytykujemy konkretnych firm.

Jeżeli coś krytykujemy, to krytykujemy zazwyczaj zachowania, które są złe, patologiczne i tak dalej.

Oprócz tego, w ramach tej naszej tutaj godzinnej dyskusji, no, staramy się trzymać jednak tego głównego tematu.

To jest też ważne, tego czasu nie jest dużo, tych pytań nie pojawia się sporo, w związku z tym zachęcamy do tego, aby w ten sposób się tutaj fokusować.

Jeżeli ktoś jeszcze nie jest zapisany na nasze powiadomienia, to na cityofmorning.cofi może znaleźć landing page'a, gdzie można to zrobić.

Są tam też linki do archiwum poprzednich odcinków.

Panowie, czy o czymś ważnym zapomniałem?

O niczym.

Chyba tyle.

Łasko, to idziemy.

Wojtek, od czego zaczynamy?

Dobra, czekajcie, bo chyba miałem opóźnienie, powinienem być.

Słuchajcie, mam taką wielką prośbę od razu, żeby zaznaczyć...

Niech Wojtka gdzieś wyrzuciła.

Nie, no jest, ja go słyszę.

Powiedzcie, że jest.

Dobra, bo tu wiecie, teraz z X czy z Twitterem kiedyś, to nigdy nie wiadomo, codziennie coś nie działa.

Słuchajcie, od razu chciałem na starcie zaznaczyć, że chcemy przyjąć inną perspektywę w tej dyskusji, bo zawsze w tego typu dyskusjach przyjmujemy perspektywę zespołu inżynierskiego najczęściej i patrzymy z punktu widzenia zespołu inżynierskiego, więc teraz stricte moja propozycja do nas wszystkich jest tutaj, żebyśmy przyjęli perspektywę lidera, który bierze odpowiedzialność za podjęcie pewnych decyzji i lidera, który prawdopodobnie weźmie odpowiedzialność na przykład za produkt firmy, czyli tak naprawdę perspektywę CTO.

I z tym, biorąc to pod uwagę, chciałem od razu wam zadać pytanie, że czym jest właściwie chmura z tego, z tej perspektywy i czym mamy się tu ekscytować, gdzie myślicie jesteśmy z takiego punktu widzenia?

No dobrze, normalnie bym wyciągnął Sebastiana, ale on musi technicznie zrobić pauzę, bo cię nie słyszę, to taka ciekawa opowieść.

Czym jest chmura?

Jak jest to, to każdy będzie miał po prostu inną odpowiedź, to zależy też od perspektywy, gdzie jesteś w firmie enterprise, firmie produktowej itd. i co robisz.

Ja wiem czym nie jest, nie jest rozwiązaniem problemu, to po pierwsze.

Takiego, który gdzieś tam masz w firmie, bo to nie jest remedium na to, że coś ci nie działa.

To czym jest?

To jest narzędzie, to na pewno.

Czyli to jest narzędzie, które pozwala ci ewentualnie, jeżeli go użyjesz, no, coś dowieźć, albo coś wykonać.

I to coś dla mnie to jest eksperyment.

Ja wiem, że to jest mało techniczne i dookoła, ale trochę tak moje postrzeganie się zmieniło.

Mało technicznie zaczynamy dzisiaj.

Kiedyś, znaczy wiesz, jest prawda ekranu, prawda historii itd., ale prawda jest taka, że chmura była sprzedawana jako remedium na wszystko i pchana przez vendorów.

Dużo ludzi wpadło w tą pułapkę, ale tak naprawdę na końcu to jest narzędzie.

To jest faktycznie elastyczne narzędzie, które pozwala ci uruchamiać coś, w zależności co chcesz, co możesz itd.

Szybko eksperymentować.

I to jest dla mnie najważniejsze w tym wszystkim na technologii.

A cała reszta to jest ten...

Ja jeszcze tylko wkręcę, że ja mam taki swój tagline, który używam i głęboko w niego wierzę, że używam na prezentacjach, że chmura to jest compute plus storage plus billiard model.

I tu się kończy.

Cała reszta to rzecz w torbie.

Sebastian, z punktu widzenia osoby, która ma do czynienia zawodowo z chmurą na co dzień, czym według ciebie dla nas jest?

Czym jest chmura?

To jest łatwiej trudne pytanie, bo tak, chmura była hypem przede wszystkim.

Chmura była x modelami makowania usługi.

Te usługi były na różnym poziomie abstrakcji, czyli od poziomu infrastruktury po poziom bazy danych jak endpoint.

Więc chmura była takim mentalnym opakowaniem wszystkich tych modeli usługowych.

To jest inna rzecz.

I chmura jest pewnego rodzaju wytrychem.

Teraz może powiem, o co chodzi z tym wytrychem.

Bo niektórzy ludzie zaczęli po prostu myśleć, że to jest łatwiejszy dostęp do zasobów.

No i fajnie, to też jest jakaś korzyść.

Oczywiście później pojawił się ten sposób myślenia, że chmura to jest też bardzo fajna rzecz, bo można w ten sposób rearchitektować swoje rozwiązania do technologii, które mają wbudowane jeszcze dodatkowe, nazwijmy to, featury.

Czyli na przykład autoskalowanie, uproszczone operations.

I to już było fajne, to już wiele firm jakby to przyjęło i na tym skorzystało.

Natomiast chmura to jest jeszcze inny nie tylko sposób na zmianę architektury, ale też sposób na prace rozwojowe.

Czyli na przykład dzięki chmurze jesteśmy w stanie znacznie skrócić swój cycle time, znacznie skrócić swój loop.

Jesteśmy w stanie w szybki sposób ściągać dużo informacji, również biznesowych, które pomogą nam rozwijać naszą platformę we właściwym czasie.

Dlatego wiele firm, które moim zdaniem nie osiągnęły właściwych efektów wykorzystania chmury, to są po prostu firmy, które nie zmieniły swojego sposobu działania.

Więc no niestety, ale to jest taki koncepcyjny worek, w który wpada dużo rzeczy.

Gdzieś tam koniec końców to jest po prostu, to są po prostu jakieś usługi IT, usługi informatyczne, usługi cyfrowe, jak zwał tak zwał, które są oferowane komuś za pieniądze.

Za usługi cyfrowe będzie 5 zł czerwony.

Tutaj od razu dodam, że zapraszamy wszystkich do dyskusji.

Wiem, że jest z nami wiele osób zawodowo związanych z chmurą, więc zapraszamy do dyskusji, czym właśnie jest z punktu widzenia CTO.

Ja bym powiedział, że do tego, słuchajcie, jeszcze w wielu chmurach była taka obietnica, że razem z tym całym opakowaniem, o którym mówicie, dostajemy też ogromną wiedzę ekspercką od vendorów.

I z tym bywa z mojego własnego doświadczenia ogromnie różnie, że z tą wiedzą dostarczaną nam przez vendorów różnie.

Plus jeszcze druga rzecz, tam jest jeszcze taka łyżka dziegciu spakowana.

Bardzo niewiele firm, zauważyłem, umie bardzo dobrze w budżetowaniu swoich rozwiązań chmury, więc ta chmura potrafi bardzo delikatnie, spokojnie rosnąć, po czym nagle jak dostaniemy pikiem zużycia, to naprawdę jesteśmy u CFO na dywaniku.

Wybiegasz do przodu, zarósł się z tym Pawła, ale do jednego się odniosę z tą spakowaną wiedzą ekspercką, bo taki nie.

Dlaczego taki nie?

Bo pewnie Ci chodzi o to, że przychodzi potem ktoś, kto powinien wiedzieć, jak ta chmura działa albo coś zrobić i jej tam nie ma, musisz sam dowiedzieć.

Ale ta wiedza tak naprawdę to dostaje się w tym, że ona jest spakowana w ten produkt często albo czasami przynajmniej.

W usługę.

W usługę, dokładnie.

Powinno, wiesz, powinno tak być, natomiast wiecie, mi chodzi, jeżeli jestem CTO firmy, która miała wcześniej jakąś architekturę swojego rozwiązania, no to między tym rozwiązaniem, które jest mi prezentowane na prezentacjach z punktu widzenia vendora, a tym, co ja mam, jest ogromna delta, tak?

I tą delta muszę jakoś zmienić, w sensie zmniejszyć i przeprowadzić jakąś migrację.

Ale postaw się w funkcji CTO takiej, czy w ogóle, wiesz, firmy, która zaczyna i nie ma tego rozwiązania.

I wtedy head start, że nie muszą wymyślać, jak postawić konkretną usługę i tak dalej, kto mógł z niej skorzystać, to to jest ta wiedza, która jest zapakowana.

Poza tym trzeba sobie powiedzieć, po prostu no one size fits all.

To nie jest tak, że chmura rozwiązuje problemy wszystkich firm tak samo.

Paweł stoi w kolejce.

Ja mam małe wrażenie, że przez to, że jechałem windą, to trochę wycięło mi Waszej rozmowy.

I chciałem skomentować to, czym jest chmura, moim zdaniem.

I się tak cofnąć na bardzo wysoki poziom strakti, bo dla mnie to jest po prostu demokratyzacja.

To jest wyświetlany termin jeszcze z czasów, kiedy blogi się pojawiły, z czasów, kiedy się YouTube pojawił.

I to jest bardzo łatwy dostęp do technologii, które po prostu sprzyja innowacyjności.

I dzięki temu mamy mnóstwo aplikacji, których nawet nie jestem tak w stanie na szybko z głowy wymienić, czy usług, z których korzystamy jako zwykli ludzie na co dzień, tylko dlatego, że ktoś po prostu mógł to wykonać bez kolosalnych inwestycji w sprzęt, w infrastrukturę, czy w licencję.

I to jest ten know-how, o którym przed chwilą Tomek też wspominał.

Dzięki za ten głos.

Michał?

Ja tylko bym się odniósł do tego tematu usług, bo gdyby było tak, Tomek, jak mówisz, to jest compute storage i model finansowy, to to by było dla mnie mało atrakcyjne.

Natomiast dla mnie kuszące są usługi.

Nawet nie ta cała skalowalność, której trzeba umieć używać, ten cały dostęp globalny, którego trzeba umieć używać i który nie jest wcale tak atrakcyjny dla wszystkich firm na świecie, ale właśnie gotowość usług, których ja nie muszę od zera konfigurować.

Ja jestem z czasów, kiedy się jeszcze instalowało systemy z CD-romów albo dyskietek, więc jestem stary i jakby nie chcę już tego robić.

Ale to nie jest tylko chodzi o system, ale cały stag dookoła.

Jak mogę go dostać i ktoś go opakował, przygotował i postawił w jakiejś usłudze, która ma jakieś cechy i jakiś model płatności, dla mnie to jest bardzo kuszące.

Jak tego nie mam, to nie chcę się bawić jakimś usługom, jakimś dostawcą chmurowym po prostu.

To jeszcze dodam tutaj, że bardzo często do tego, co mówisz Michał i Paweł, jeszcze bym dodał, że faktycznie w chmurze mamy wzliczone w większości przypadków licencje od razu, dosyć zaawansowane produkty, więc powiedzmy wliczone w pakiecie, bo niejednokrotnie przed chmurą, nie wiem czy pamiętacie, ale zrozumienie ile trzeba zapłacić za licencję SQL Serwera, to była wyższa matematyka powiązana naprawdę z godzinami na telefonie z różnymi osobami z Microsofta.

To znaczy tutaj trzeba uważać z tym Wojtek stwierdzeniem, bo nadal niektóre modele kosztowe chmurowych usług, jak się spojrzy, też wymagają wiedzy z wyższej matematyki i wcale nie są trywialne.

Oczywiście, ja mogę powiedzieć, że dla mnie to jest proste i pewnie wielu z Was, którzy są tutaj, bo spędziliście nad tym dużo czasu, ale zgadzam się z tobą, że model jest uproszczony i ten model licencyjny, który jest zbudowany, super.

Dla mnie super, mniej problemów.

Skoro jesteśmy przy pieniądzach, to ja chciałem wrzucić tutaj troszeczkę inne też od razu, tak jak wiemy, po co i dlaczego, chciałem od razu wrzucić ten artykuł, do którego bardzo dużym echem Davida Hansona się odbił w internecie, czyli We're leaving the cloud, odnośnie Heya i Basecampa.

Sebastian, wiem, że może ciebie teraz wywołam, bo wiem, że mieliśmy sporo dyskusji na ten temat w naszym gronie.

Nie wiem, czy każdy jest tak zupełnie up-to-date z tym, co było w artykule, natomiast to była seria artykułów tak naprawdę, w ramach której 37signals, czyli to jest firma krytykująca właśnie za Basecampem i za Heya, DHH pewnie każdy zna, to jest bardzo znana osoba generalnie w świecie open source i przede wszystkim w świecie rejsowym, a więc DHH i cała jego firma napisali serię artykułów na temat tego, że wychodzą z chmury i napisali, dlaczego wychodzą, napisali, jakie wielkie oszczędności się z tym wiążą, a ja trochę się podoktoryzowałem, jeżeli chodzi o te artykuły.

Tam jest dużo fajnych szczegółów, bo akurat uważam, że całkiem transparentnie do tego tematu podeszli.

Te artykuły mają takie bardzo łapiące uwagę nagłówki, bo tam jest na przykład, już mamy milion dolarów oszczędności na rok.

No jeżeli ktoś zobaczy taki nagłówek, na pewno tu przykuje uwagę.

I rzeczywiście zaczęła się taka dyskusja, czyli komu opłaca się w chmurze być, komu opłaca się z tej chmury wychodzić, jakie są kryteria i jeżeli można w tak krótkim czasie oszczędzić sobie ten milion, no to dlaczego, dlaczego nie?

Ja tak w skrócie podoktoryzowałem się trochę, jeżeli chodzi o ten artykuł.

Te nagłówki trochę są clickbaitami.

To, co jest tam najciekawszego, to tak, po pierwsze, mowa tylko i wyłącznie o HEJ-u.

Basecamp to jest coś, co już w on-premise działa od dawna, co w praktyce oznacza, że jako firma 37signals ma cały czas duże doświadczenie w utrzymywaniu infrastruktury on-premise.

To jest jedna rzecz.

Czyli to nie jest tak, że u nich to jest taki kompletny switch.

Oni tych ludzi już po prostu mają.

Po drugie, jeżeli chodzi o te usługi, z których oni korzystają, to tak naprawdę wszystkie aplikacje, które oni mają, bo to są te dwie główne aplikacje, plus tam jeszcze x i x trochę mniejszych, działają na takim samym, bardzo podobnym stacku.

I teraz ten stack jest bardzo mocno ustabilizowany.

Oni nie są na etapie szukania Product Market Feed, oni nie są na etapie jakiegoś Rapid Growth.

Oni już mają swój dobry, sprawdzony pomysł na stos technologiczny, nie muszą eksperymentować, mają bardzo dużą stabilność tego, co robią.

W związku z tym, tak naprawdę, u nich to faktycznie ten operational excellence, czyli optymalizacja po prostu kosztów działania, no przy całkiem sporej skali, bo oni jednak tego mają na serwują, na przykład, dużej ilości użytkowników, to też powoli zaczyna być bardzo ważny faktor, ważniejszy niż na przykład elastyczność.

No oni już pewnie aż tak tej elastyczności nie potrzebują.

A to, tak, ja tych obserwacji mam więcej, więc może też oddam głos.

Widzę, że Tomek się garnia.

No garnia się, garnia.

Wiesz, już kurwa się znamy, na tyle, że wiesz, że tam coś do powiedzenia będę miał, nie?

Ale wiesz, no bo to trochę do całego naszego spotkania dzisiaj.

No bo change jaki jest, każdy widzi, jeżeli ktoś nie widzi, to niech spojrzy, czyli kontrowersyjny jest, ale trzeba mu przyznać, że ma tam ziarenko zawsze i to czasami dobre, czasami, no zależy, nie?

Ale właśnie to, co on zrobił, no to napisał, my jako Basecamp wychodzimy z chmury, zaoszczędzimy masę pieniędzy, pokazał cyfry i tak dalej, nie?

Ale punkt pierwszy, jak odpaleli hej, to weszli w chmurę, nie?

Dlaczego?

Bo właśnie sprowadza się do tego, że jakby chcieli to robić wcześniej, nie, no to ponieśli by tą inwestycję, którą teraz ponoszą, bez wiadomości, czy mają klienta.

Więc robili eksperyment na chmurze i dopiero potem, jak już mieli klientów i tak dalej, to policzyli koszty.

By the way, nie wiem, czy pamiętasz, a co było triggerem do tego wyjścia z chmury, to wcale nie był też tam koszt infrastruktury, tylko tam jeszcze, to się wszystko zaczęło od tego, że jedna z firm wystawiła im rachunek za soft do zarządzania tym, nie?

I oni, jak zabrakli ten soft do zarządzania tym, to zaczęli kombinować, no, koszt był jakiś tam abstrakcyjny.

Tak, no, niemiecka firma, tak, dokładnie.

Tak, tak, i on powiedział, że to was powaliło, że będę płacił tyle za soft do zarządzania kubernetesem, upraszczałem, tam, orkiestracji i tak dalej.

No i zaczął się skrojać po głowie.

Tylko właśnie, VHA to jest bardzo specyficzny przypadek i ja nawet próbowałem z nim dyskutować, no ale jestem za mały w rankingach tam internetowych, no bo to jest przypadek właśnie takiej firmy, która jest mała, nimbo, mocno osadzona, ma duży REWE, krótko mówiąc, nie pokazują, ale można sobie policzyć.

Ma bardzo specyficzny produkt, czy produkty już w tej chwili.

Jest bardzo wąsko osadzona, tak jak mówisz, oni nie muszą eksperymentować, plus mają ludzi.

I teraz jesteśmy po drugiej skali, bo ja akurat pracuję z Enterprises.

Enterprises często nie mają ludzi albo muszą ich kupić, co jest ciężkie, mają vendorów.

Mają dużo legacy, mają dużo jakichś narzutów i tak dalej.

Dla nich oni nie mają tego stacku, tych umiejętności, które ma VHA ze swoją firmą.

Więc jeżeli kupią rozwiązanie, to o którym mówił Michał, i to rozwiązanie im spowoduje, że będą mieli mniejszy problem z ludźmi, albo przedłużą sobie życie systemu o x lat, albo szybciej wytworzą następne systemy, aplikacje, to dla nich jest to według mnie gain.

Teraz finansowo, jak to wychodzi, to bardziej jest kwestia zrozumienia tych modeli niż to, czy to faktycznie stanie się, czy nie.

Bo tam koszt to jest wynikowa tego, co się dzieje, jak to robisz i gdzie z tym idziesz.

Więc ja rozumiem punkt VHA.

Dla firm, które są w jego pozycji, według mnie takie ćwiczenie ma sens.

Zresztą Stack Overflow pokazuje to od lat, o ile pamiętam.

Nie wiem, czy dalej to robią, ale kiedyś pokazywali swoje koszty, przeliczali to itd.

Ale takie zgeneralizowanie, jakie on zrobił, nie za bardzo.

No co macie?

To przepraszam, mogę coś dodać?

Jasne zdanie, proszę ci bardzo.

Bo tutaj i Sebastian, i Tomasz, ja się oczywiście z wami zgadzam, po prostu dlatego, że macie rację i to jest zdrowe spojrzenie.

Nie można wrzucić do jednego worka firmy produktowej, technologicznej, startupu, który idzie w chmurę dlatego, że dostaje tyle benefitów i incentywów, że generalnie przez pierwsze trzy lata, jak się dobrze zakręci między vendorami, to nie zapłaci za infrastrukturę.

A enterprise'ów, które mają legacji właśnie, tak jak Tomek mówił, które decyzje podejmują zazwyczaj kilka lat za późno, muszą to nadgonić, muszą wydać ogromne pieniądze na partnera, takiego chociażby jak firma, w której pracuję, czy też firma, w której poprzednio pracowałem.

To są ogromne koszty i tego się praktycznie nie da wtedy zrobić optymalnie.

I te wejścia w chmurę, zwłaszcza te takie pierwsze, mówimy o firmach, które podjęły te decyzje dziewięć, siedem lat temu, to ten dług technologiczny związany ze złą adopcją chmury.

Przecież dziewięć lat temu nie było takiego pojęcia jak na Dicksona, przynajmniej ja wtedy nie słyszałem.

I oni wszyscy muszą robić kroki wstecz.

A inaczej zachowuje się firma, świetny zespół IT, bo to wszystko są ludzie, dajmy na to, techniczni, albo 90% ekipy to są, nie wiem, ex-developerzy, obecni developerzy, devopsi, oni inaczej się adoptują i oni mogą sobie wybierać opcję między chmurami, między opcję multi-cloud versus hybryda.

Dzisiaj chyba każdy z nas potwierdzi, że przede wszystkim chodzi o pieniądze i vendorzy są w tym dobrzy, natomiast my jako ludzie, którzy doradzamy takim klientom, no to jak ktoś dzisiaj stwierdza, że no idźcie do chmury, najlepiej all in, bo będzie super, tak, bo chmura jest do wszystkiego, to chyba to już zostało zabite, tak, właśnie przez wiele artykułów repatriacji i po prostu zdroworozsądkowym podejściu do chmury.

I myślę, że tego zdrowego rozsądku tu wychodzi przy finopsach najczęściej.

No słuchajcie...

Jak bardzo jest to, jak bardzo właśnie organizacja często się nie zmieniła, jest niedojrzała i potraktowała chmurę jak kolejną technologię w IT do kupienia, a to tak zwyczajnie nie działało.

Kolejną kolokację serwerów.

Ja dodam jeszcze tak do tego, co Daniel powiedział, że teraz z kolei jest hype na wychodzenie z chmury.

Jak napiszesz artykuł, weszliśmy all in do chmury, to powiedziałeś...

Tak, tak, dokładnie, tak.

Więc trzeba się jakoś w ogóle wyróżnić, a do tego, co Tomek powiedział, ja tej sprawy nie znam, dokładnie nie czytałem tych artykułów, wszystkich nieprzygotowanych, ale wygląda na to, że to Kubernetes spowodował, że chcieliby wyjść z chmury, a nie sama chmura.

Nie, nie, to ci podeszło.

Słuchajcie, słuchajcie, tutaj mam bardzo fajny wątek i pojawiło się kilka już punktów, czyli ja bym chciał tutaj skonkretyzować to pytanie, czyli kiedy warto korzystać z chmury, a kiedy warto spojrzeć na swoje własne może jakieś rozwiązania lub tudzież inne.

Ty, Tomek, powiedziałeś o prototypowaniu, Daniel powiedziałeś właśnie o tym, że możemy tak naprawdę, jeżeli mamy braki w talencie, jeżeli chodzi o chmurę, możemy właśnie, infrastruktury, możemy się wspomóc, więc pytanie konkretne i zapraszam do dyskusji, kiedy warto, kiedy nie i jak to z waszego punktu widzenia właśnie wygląda, jeżeli chodzi o perspektywę osób, które dają rekomendacje np. dla zarządu.

To jest świetna okazja, nie mogę się powstrzymać, więc pojadę Tomkiem bardzo szybko, więc narysujcie sobie mapę Wordlay'a, ale tak zupełnie poważnie.

No jakoś ta serwerlessowa mapa Wordlay'a nie zadziałała, już czekam i czekam i się nie doczekałem.

Ale też powiem dla wszystkich, o co mi chodzi, chodzi mi o to, że spójrzcie sobie na swoje zależności, spójrzcie sobie na rolę, którą tutaj pełni infrastruktura, spójrzcie sobie, czy to jest rzeczywiście specjalizacja w ramach infrastruktury albo jakaś optymalizacja pod kątem waszego scenariusza, który np. być może odstaje od zupełnie genycznych scenariuszy, może wy faktycznie wykorzystujecie w jakiś bardzo specyficzny sposób.

Ja pracowałem w firmie, słuchajcie, która napisała swój własny HTTP serwer.

Brzmi jak totalnie crazy, natomiast rzeczywiście ta firma miała tak specyficzny scenariusz, gdzie te HTTP serwery, one nie były używane do serwowania jakiegoś np. nie wiem, statycznego kontentu, one były do bardzo szybkiego zbierania tak naprawdę klików z internetu.

W związku z tym miało to sens.

I tamten poziom optymalizacji był do tego poziomu, że musiał mógł być wykorzystywany tylko jeden rodzaj Unixa ze względu na jakieś biblioteki, które były w ramach Kernela, co było bardzo kłopotliwym oczywiście zależnością.

Natomiast wtedy to się sprawdzało i miało to jakiś tam głębszy sens.

Więc wyobraźcie sobie taką mapę, może z tej mapy faktycznie wam wyjdzie, że jakaś optymalizacja infrastruktury ma po prostu sens.

W Polsce jest firma, która używa takiego terminu na takie rzeczy, Sebastian, nazywali na to hołmizmy.

Oni akurat napisali własny serwer SSH, bo mieli takie potrzeby.

Utrzymanie tego jest strasznym dramatem.

Ja pracowałem w firmie, która chciała napisać własnego hibernata, firma z Krakowa bodajże.

Każdy ma pomysł, który chce napisać, ale tutaj wracając trochę do Wojtka, no bo tak, mamy takie właśnie, znaczy każdy z nas może wyciągnąć przykład firmy, która powiedziała, wchodzę w chmurę, po prostu wydała kupę kasy, gdzie są w tym samym miejscu, mają komputer, gdzie indziej.

Niektórzy z nas mogą wyciągnąć przykłady firm prawdopodobnie, które zrobiły bardzo sensowne rzeczy, czyli wymyśliły sobie biznes model, do wniosku, że zrobią to sprawnie i zbudowały to w oparciu o chmurę.

Nikt nie będzie się nalazł z punktu widzenia technologii, tylko np. właśnie jak szybko to zrobiły i osiągnęły z tego sukces.

Jest masa przykładów w pośrodku.

Mamy też takiego DHH, który powiedział, mi się to nie opłaca.

No i teraz pytanie.

Wiadomo, że nie wszystkim się będzie opłacać albo niekoniecznie musi.

Ja pamiętam, jak ja byłem na jednych z takich pierwszych spotkań x lat temu w Polsce i ktoś powiedział, że tutaj spotkaliśmy się, nie?

I ktoś mówi, no tutaj chcielibyśmy wejść w chmurę, bo będzie tanie.

Ja mówię, no to na dzień dobry sobie wyjaśnimy, taniej nie będzie, nie?

No to było pytanie, to po co się zapytaliśmy.

No to jeżeli chmura, wchodzić tak lub nie, no to pytanie jest, po czym decydować, tak?

Czyli na co popatrzeć pod kątem tego zbudowania, tego określenia pod tytułem, czy nam się to opłaci czy nie, czy w ogóle, żeby zdecydować, czy chcemy to próbować.

To ja zadałbym Ci, Tomek, zawsze pytanie, a co Ty chcesz w ogóle osiągnąć?

Zadałbym tym, którzy są po tej drugiej stronie.

Bo po pierwsze, żaden klient nie będzie Olin, jak byśmy zdecydowali, ale pewnie każdy będzie w jakimś tam hybrydowym środowisku dla różnych rozwiązań może mieć troszeczkę inne podejście.

Więc pytanie jest, co jest tym sukcesem, który nazwałeś?

Bo już wiemy, że nie koszty.

To pytanie, co jest, Tomek, sukcesem?

Nie no, to ja zadałem pytanie, więc wiesz.

Obywajcie się konsultacjami, żeby mogli spróbować ograć domek.

Długo.

Ja myślę, że słuchajcie tutaj, tak jak Sebastian Ty powiedziałeś, że każda firma ma tak naprawdę pewne bardzo specyficzne, może nie każda, ale wiele firm będzie miała specyficzne swoje potrzeby i trzeba właśnie się zastanowić, co się opłaca.

Ja mogę powiedzieć, że z mojego doświadczenia teraz zawodowego, na przykład to, na co jest mocno wstawione w mojej firmie, to globalne skalowanie, które jest lokalne.

I teraz dlaczego ta lokalność jest też bardzo ważna?

Wymogi regulatorów.

Czyli jeżeli byśmy chcieli mieć, wiecie, swoje własne rozwiązanie, to pasowane do globalnych wymagań rynku finansowego, to to jest gigantyczna wiedza, którą trzeba zdobyć, to wszystko trzeba zbudować, to wszystko trzeba utrzymać i to wszystko trzeba rozwijać.

Więc na przykład pod tym kątem to się opłaca, czyli innymi słowy.

Co w danym momencie myślę, że warto spojrzeć, po co optymalizujemy?

Dobra, słuchajcie.

Na razie pojawił się jeden, tak naprawdę, punkt.

To ja to powiedziałem, a potem Michał trochę.

To jest pytanie, po co to robimy.

Czyli wychodzi, że głównym pytaniem jest tak naprawdę, po co to robimy, narysowanie tej mapy itd.

To jest to, co ja powiedziałem, to jest narzędzie na końcu.

Dniejczej odpalił hej na chmurze, bo mu pozwoliło odpalić szybko i zobaczyć, czy zarobi pieniądze na hej.

I przeskalować się, wiedział, że mu to nie upadnie.

Jak już wiedział, ile zarabia, to sobie przeliczył, czy mu się to opłaca, czy nie.

Więc chyba to jest bottom line tego wszystkiego, już oprócz wszystkich innych rzeczy.

Przy okazji, jeżeli ktoś ma jakieś swoje hinty, to niech się odezwie i powie.

Wiem, że Szymon w kolejce chwilę.

Ale no właśnie, to się zawsze rozbijało to, że jeżeli tam wchodzimy dlatego, że myślimy, że zaoszczędzimy pieniądze, to jak tego nie przeliczymy, to nie zaoszczędzimy.

Jeżeli wchodzimy tam dlatego, bo nas ktoś przekonał na konferencji, to będzie z tego disaster.

Ja niestety widziałem więcej tych przypadków, gdzie ktoś wchodził bez zadań i sobie pytał, dlaczego.

No tak, to zależy, wyjdzie na końcu.

To ja bym jeszcze chciał dotknąć przy okazji, jak rozmawiamy, słuchajcie, dotknęliśmy kosztów, dotknęliśmy hype'u.

To jeszcze jeden hype, który przy chmurze właśnie bardzo często pojawia i w ostatnich latach też był bardzo modny, czyli multi-cloud.

Co o tym myślicie?

Gdzie jesteśmy z multi-cloudem?

Ja bardzo nie lubię tego określenia, bo to tak naprawdę nic nie znaczy.

Tak naprawdę powinniśmy wyróżnić kilka rodzajów tego, co można mieć na myśli z multi-cloud.

Znaczy ja w moim modelu mentalnym mam przynajmniej trzy, bo są firmy, które na przykład z definicji są chmurowo-agnostyczne, czyli tak naprawdę mają stack, który da się zdeplojować w każdej chmurze z różnego powodu, z jakiegoś tam powodu regulacyjnego.

Są firmy, które, powiedziałbym, nazywają się, ich podaje się z AnyCloud z kolei, one są bardzo podobne.

Jakby tu różnica jest taka, że one nie tylko mogą być deplojowane w każdej chmurze, ale one są deplojowane w wielu chmurach, bo na przykład to są firmy B2B, które mają dużych klientów i faktycznie często są deplojowani w infrastrukturze swoich klientów.

W związku z tym to jest w ogóle część ich jakby oferingu, no oni nie mają innego wyjścia.

Są takie firmy z kolei, ja nazywam to best of breed, czyli która z definicji na przykład ich value proposition polega na tym, że kombinacja technologii albo technologie są w jakimś sensie unikalne i oni rzeczywiście wybierają, wybierają sobie jakieś usługi od wszystkich providerów cloudowych, nawet tych mniejszych bezspecjalizowanych, tylko i wyłącznie po to, żeby mieć z tego taki patchwork, ale no to jest rzeczywiście jakiś unikalny patchwork, który według nich daje jakieś takie synergie, których inaczej by nie uzyskali.

Więc to są zupełnie różne podejścia i każdy z nich angażuje wiele chmur, ale angażuje je w sposób inny.

No ale koniec końców na drugim końcu spektrum też można być one stop shopem, czyli jak już się decydujemy na jednego vendora, to jedziemy z tym jednym vendorem.

No dobrze, ja popełniłem kilka tekstów, więc można mnie skrawdzić co myślę, to trochę, ale też można zmienić zdanie, nie?

Ja uważam, że w ogóle, wiesz, wejście w multicloud to jest podniesienie sobie poziomu skomplikowania o jeden poziom, nie?

Jak ktoś mi mówi, że chce mieć multicloud i tak dalej, to dokładnie zadaję pytanie, dlaczego, nie?

No niestety, byłem konsultantem, ale taki nawyk.

Ale dlaczego to jest ważne?

No bo, wiesz, wejście w jedną chmurę, czy w jednego vendora, nie?

No to jest, po pierwsze, trzeba zmienić sposób myślenia o tym, jak to robisz, to faktycznie jest jednak duży shift, nie?

Po drugie jest kwestia poznania tych wszystkich modeli, narzędzi i tak dalej, cen i tak dalej, i tak dalej, wyszkolenie ludzi, zbudowanie sobie jakiś pattern, wejście w to i tak dalej.

Teraz wejście w drugą to jest powtórzenie tego samego, nie?

W trzecią to jest powtórzenie tego samego.

Może już trochę mniejszy narzędz, ale jednak, nie?

I teraz pytanie...

Ja się nie zgodzę, ja bym powiedział, że jeszcze komplikujesz, bo jeszcze musisz pewnie jakoś pomiędzy tym wszystkim się połączyć, analizować koszty i w ogóle.

Większość to jest stopień skomplikowania, nie?

Już poziom publikacji.

I jak ktoś na dzień dobry przychodzi i w ogóle mówi o tym, że to jest jego pierwszy krok, czyli my chcemy wejść w chmurę i chcemy mieć multicloud, bo chcemy się zabezpieczyć i tutaj pada wiele, o tym jeszcze porozmawiamy.

No to generalnie, według mnie, to jest przepis na porażkę.

Podejście pick and choose, takie typu sas robimy na tym, czyli na przykład bierzemy sobie office od tego vendora, jeden office, przepraszam, a na przykład jesteśmy na sztaku takim, albo widziałem takie podejście pod tytułem dane zbieramy na jednym sztaku, ale prezentujemy je na drugim.

To już ma większy sens, nie?

Ale żeby zrobić multicloud, taki pod tytułem świadomie korzystamy z wielu vendorów, żeby się zabezpieczyć przed jakimś ryzykiem, to naprawdę trzeba być po pierwsze świadomym, dojrzałym i mieć dobrze zbudowany ten case.

I przyznam się szczerze, że według mnie to ma sens dla bardzo małego procentu firm.

Dokładnie tak, jak mówicie Tomasz i Sebastian.

Ja dodam jedynie, to jest moje spostrzeżenie.

Uważam, że regulacje, zwłaszcza te KNF-owe w Polsce, wywołały jakiś taki dziwny mindtrap u klientów, którzy już kilka lat temu przychodzili do nas, no bo też jakby w roli konsultanta występuję najczęściej do klientów i to jest taki tekst o tym, że oni muszą by design po prostu mieć strategię multicloud, nie?

To jest super dla takich jakby firm jak moja, tak?

Natomiast czy to ma ogromny sens dla klienta?

Śmiem twierdzić, że nie i tutaj bardziej stoję po stronie Tomka.

Naprawdę wejście w jedną chmurę i kilka SAS-ów na około to jest wystarczająco dużo dla większości firm.

Strzelam 80%, a w Polsce pewnie więcej.

A jak chcemy się bawić w multicloud, taki prawdziwy, tak?

Czyli nie właśnie, że nie wiem, używamy Power BI, a Ofisa, a nie wiem, Infra IT, trzymamy na gówno, tak?

To poziom skomplikowania, poziom, nie wiem, luk bezpieczeństwa, ilość dobrze skonfigurowana sieć i zarządzanie tym wszystkim, oczywiście z uwzględnieniem kosztów, to jest koszmar, na który firmy zwyczajnie nie są gotowe.

I współdupione miliony, miliony, naprawdę.

Tutaj wejdę ci tylko z jedną rzeczą, bo odniosę się do lokalnego rynku.

Na lokalnym rynku u nas czasami są różne...

No bo akurat o te regulacje konkretnie mi chodziły, tak?

Właściwie spełnienie wymagań regulacji globalnie to jest jeden z tych przypadków, gdzie multicloud akurat może mieć sens dla firmy, bo po prostu...

Tak, ale czasami jest to, wiesz, jakby błędne założenie, że koniecznie od front day one muszą...

Dokładnie, ale...

Tak, no bo chodzi o potrzebne...

Rozumiem, zgadzam się.

Jednym z tych istotnych case'ów, które ja spotkałem, to było dokładnie.

Słuchajcie, my mamy takie wymagania regulatora, one nakładają na nas takie wymagania x, y, z.

Nie mamy innego sposobu zrobienia tego w taki sposób.

I wtedy jesteśmy pokryci od strony regulacyjnej.

Kosztuje nas to więcej, technicznie jest nightmare, ale robimy, co możemy.

No słuchajcie, żeby tak podsumować...

Nie są regulowane, albo nie są regulowane aż tak mocno, nikt im śruby nie przykręca, a i tak trwia w takim mentalnym podejściu, aż będzie taniej, bezpieczniej, lepiej, jak zrobimy multicloud.

I to jest to, o czym mówiłeś ty, Tomek i Daniel, może nie dokładnie tymi słowami, co jest błędne, moim zdaniem.

I to jest po prostu drogie i kosztowne, i również niebezpieczne.

To słuchajcie, tak żeby podsumować.

Kiedy według was...

To jest dobra strategia.

Kiedy pójście...

Ty, Tomek, wymieniłeś kilka punktów, więc bardzo chętnie jeszcze może bym wywołał kilka innych osób.

Kiedy według was zdecydowanie warto to rozważyć?

Cherry pick na konkretnych serwisach.

Czyli naprawdę znamy offering, wiemy, co jest nam potrzebne i sobie wybieramy z tej chmury biorę to, to i to i mam uzasadnienie A, biznesowe, B, techniczne i pokrycie w zespole wiedzy.

Wtedy to naprawdę ma sens.

Ale to dotyczy, nie wiem, ilu promila naszych klientów może.

Ja myślę, że ten promil jest większy.

Spójrz w ogóle na programistów Java, albo ludzi, którzy się znają na offeringu Microsoftu.

Więc ja myślę, że ta kadra to jest naprawdę bardzo duży argument za tym, ale generalnie dopóki nie jesteś regulowany, a jak jesteś albo wydaje ci się, to to sprawdź.

Jeżeli prawnicy ci powiedzą, że musisz, to wtedy tak jak przed operacją idziesz do drugiego lekarza i prosisz o osobną opinię, sprawdź to drugi raz i tylko wtedy.

Wydaje mi się, że koszty związane z zarządzaniem dwoma chmurami, z tym, że musisz ludzi zatrudnić, z tym, że musisz zatrudnić ludzi z dwóch w ogóle przeciwnych obozów, często, którzy muszą się dogadać, albo kogoś, kto ogarnia a minimum dwie chmury, co już jest w ogóle, ten mit też już wpadł, że jesteś specem od wielu chmur, jest tak wielki, że to w ogóle tak łatwo się po prostu poślizgnąć albo spalić miliony, że bardzo, bardzo, bardzo ostrożnie.

Ja mam jeszcze kilka case'ów, takich bardzo rzadkich.

Ten, który wspomniałem, czyli sytuacja, w której jesteśmy B2B, jesteśmy zależni od naszych klientów i deployujemy w ich chmurach.

A my mamy swojego Sasa.

To jest jeden case.

Inny case to jest taki, gdzie mamy do czynienia na przykład z bardzo specyficznym hardwarem albo z bardzo specyficznymi warunkami, w których ten hardware pracuje i czasami zdarza się tak, że musimy to, co zwykle uruchamiamy w chmurze, uruchomić gdzieś tam on-premise.

W związku z tym, to co robimy, robimy tak zupełnie cloud agnostic, czyli gdzieś w ogóle tak konteneryzujemy, żeby dało się to puścić nie tylko i wyłącznie w chmurze.

No i wtedy z definicji jesteśmy cloud agnostic i w sumie też możemy to uruchomić w każdej chmurze, bo skoro możemy też na on-premise, to w każdej chmurze.

To jest kolejny case.

Inny case, który też jest rzadki, jest to raz z nas trzy, czyli jeżeli nie wystarczy nam globalna infrastruktura jakiegokolwiek, nawet największego profilera chmurowego i czasami walczymy o tę latencję na jakimś w ogóle już chorych poziomach, no to też czasami zdarzają się firmy, które przez to wybierają multi-cloud.

I z takich najczęstszych przypadków to chyba wszystkie wymieniłem.

Dziękuję.

Zapomniałem o tym case'ie właśnie Mainland China, gdzie czasami nawet jak chcemy trzymać się jednej chmury, to gdzieś ten Alicloud nam się wciśnie albo coś takiego.

To się zdarzało i te decyzje były podejmowane wtedy ze względu na ten firewall w Chinach i brak entity tak zwanego, czyli tego bytu prawnego na terytorium Chin.

Ja mam pytanie do szanownej grupy ekspertów tutaj.

Jedna chmura i własny data center to już multi-cloud, czy nie?

Czy to jest hybryda?

Dla mnie to hybryd jest, ale to też, wiesz, definicja, nie?

Nie idziemy w ten sposób.

Słuchajcie, Karolina do nas dołączyła.

Cześć Karolina.

Cześć.

Jeszcze możemy mieć taki case, że jedna firma przyjmuje drugą firmę.

Jedna firma używała jednego, usługi jednego vendora.

Druga firma używa usługi innego vendora.

No i z tego punktu widzenia jakby mamy od razu na wstępie multi-cloud i ciekawe byłoby dla mnie jakby rozważenie, jak w tym momencie podejść do takich spraw jak governance, czy landing zone.

Bo to może być spore wyzwanie.

I wtedy na takim przypadku widać, że firma staje przed zupełnie nowymi wyzwaniami.

Uwzpólnienia modelu kosztów, uwzpólnienia konwencji nazywniczych, uwzpólnienia operations i podejścia do security.

Nie wiem, czy w praktyce się z czymś takim spotkaliście, ale myślę, że w przypadku dużych graczy i globalnych rynków jest to jak najbardziej realny scenariusz.

Tak naprawdę słyszałem o takich scenariuszach, ale nie mam z tym doświadczenia.

Zakładam, że albo przepisują, albo żyją po prostu w multi-cloudzie.

I najczęściej jest taka, że im większa firma, tym większa szansa, że ona i tak już jest multi-cloudowa, chcąc, nie chcąc i świadomej, bądź nieświadomej.

Jeden z takich przykładów jest bardzo znany.

Firma Amazon przejęła firmę Whole Foods, czyli dużego dostawcy zdrowej żywności na rynku amerykańskim.

Ona korzystała z Ofisa i ktoś, kto zajmował się IT w Amazonie, powiedział, no nie, no bez przesady.

Znaczy, akurat Microsoftowego Ofisa, tak?

Nie ma sensu, żebyśmy cokolwiek zmieniali.

Firma działa, firma jest finansowo zdrowa.

Nie ma wartości.

Tyle.

Takich case'ów jest też dużo w Polsce i to znaczy nie muszą być jakieś bardzo duże firmy.

Czasami mniejsze firmy też decydują się, słuchajcie, operacyjnie działamy rozłącznie, nie?

Gdzieś tam na jakimś poziomie jakaś czapeczka będzie, ale z jakichś różnych powodów jest dalej sens działać ze sobą.

Już wejdę, bo próbowałem dwa razy, ale ci trzy.

Karolina, M&A to jest bardzo ciekawy temat, dlatego że M&A to jest tak skomplikowana rzecz, której tak wiele firm nie udźwiga, że bardzo często to IT pozostaje rozdzielone bardzo długo i się robi blue and tape po prostu, nie?

Ja więcej nie widziałem firm po M&A, ale kilka takich M&A dużych robiliśmy nawet jako firma, pomiędzy kilkoma vendorami i tak dalej, ale też dochodzisz do któregoś momentu powiązania takiego operacyjnego, spinasz jakieś rzeczy technicznie i potem bardzo długo to po prostu, albo w bardzo wielu przypadkach to zostaje i każdy operuje, to jest trochę to, co chłopaki powiedzieli, każdy operuje jednak niezależnie z piętym jakimś tam common layer, na przykład identity, security i tak dalej, nie?

Wiesz co, to bardzo przypomina mi przypadek jednego z klientów, dla którego pracowałam, który wszedł w trzy chmury plus czwartą dedykowaną dla Chin i oni do każdej chmury mieli odrębny zespół odpowiedzialny za landing zony czy implementację governance dla danej chmury.

W ramach całej firmy mieli bardzo ogólne, bardzo ogólne, taki już nawet nie governance, tylko taki, można to nawet nazwać control plane i mieli program pójścia do chmury jako cała organizacja, ale jakby wszystkie zespoły, znaczy nie było czegoś takiego, żeby, znaczy tych punktów styku było stosunkowo niewiele.

Kombinowali z różnymi narzędziami do zarządzania, zarządzania wszystkimi trzema platformami na takiej zasadzie, żeby mieć jedno źródło prawdy o wszystkich zasobach, ale to tylko to.

Natomiast wszystkie inne rzeczy, nawet na poziomie rozliczania kosztów i na poziomie współpracy z ich controllingiem dla każdej chmury było to robione oddzielnie.

Ja myślę, że nawet my, tak jak jest Karolina, że dwie firmy się łączą, które obie są dołóżmy w AWS-ie i dwie były nawet ogarnięte od początku, w sensie landing zone zostały przygotowane i tam nie było żadnej partyzantki, to i tak przy pewnej skali, jak masz miliony użytkowników i ci ludzie korzystają z twoich systemów non-stop, to jest w ogóle trudne połączenie tego, nawet jeżeli jesteśmy w jednym ekosystemie, bo są inne podejścia, inne wewnętrzne standardy i sama jakby migracja i łączenie tego w całość, to nagle obcy klient staje się naszym klientem, co nie?

I jak go wprowadzamy do analizy biznesowej, to jest bardzo trudne i często trwa lata.

Zasumowując trochę cały wątek, mówię, M&A to jest bardzo ciekawy case, w ogóle możemy wziąć na PC, ściągnąć kilku ludzi, bo jak w tych procesach po prostu bardzo często wychodzi, że efort, który by trzeba włożyć i koszt nie jest umierny do osiągniętego zysku.

I po prostu jak ludzie na to popatrzą, to bardzo szybko dochodzą do wniosku, że okej, to zmigrowanie tego wszystkiego, przepisanie i tak dalej, i tak dalej, to będzie nas tyle kosztowało i nic nie uzyskamy oprócz tego, że będziemy mieli jedno środowisko.

I po prostu tak to zostawiają.

To tak bym podsumował.

Po prostu koszt versus game biznesowy.

Słuchajcie, to zaraz obok jest jeden temat, który na pewno bardzo chciałem poruszyć i tutaj zaproponować nam do dyskusji, bo do kilku rzeczy nawiązaliście.

Temat, który bym nazwał, słuchajcie, mitami chmury, tak?

Czyli ta chmura była nam sprzedawana jako remedium na wszystkie nasze bolączki, tak jak rozmawialiśmy.

Więc to, że może się skalować w nieskończoność, to, że wiecie, te usługi są od razu dostępne, że SLA wynosi, wiecie tam, tych dziewiątek na prezentacjach bardzo dużo, więc moje pytanie, jak to z punktu widzenia właśnie lidera, jak to bardzo często tutaj są głosy, że doradzaliście takim osobom, to może spytam się mity i rozczarowania.

Jakie, z jakimi się spotkaliście ciekawymi smeczkami?

Oczywiście od razu tutaj przypomnę naszą zasadę.

Nie wymawiamy nazw firm, tylko, słuchajcie, mityczne...

Jak ktoś może i chce.

Nazwy możecie.

Tak, więc pytanie do was.

Co ciekawego widzieliście?

Jakie mity i właśnie ograniczenia, z jakimi się spotkaliście?

Dobra, zacznę od początku.

Jeden już rzuciłem.

Prawda jest taka, że ludzie wchodzą w chmurę jakimś wyobrażeniem, który jest zbudowany niestety przeważnie na marketingu i jakiejś takiej oszczympendzie.

Bo też ustalmy, nie?

Tak szczerze, kompletnie.

Przynajmniej, okej, czekajcie, mój punkt widzenia, bardzo wiele firm wchodzi w chmurę tylko dlatego, że inne firmy weszły w chmurę, nie?

Czyli patrzą i mówią, o, chmura, okej, dobra.

Wszyscy to robią, to ja też to zrobię, nie?

No i pierwszy taki mit to zawsze to są koszty, nie?

Czyli wszyscy mówią, okej, będzie taniej i tak dalej.

To jest przeważnie zbudowane przez vendorów, nie?

Albo tego, kto sprzedawał.

To nie musi być vendor.

Vendorzy nie są ostateczni.

Oni nawet czasami potrafią wyprostować, ale to już zależy, z kim się porozmawia.

Więc pierwsza taka miskoncepcja jest dokładnie taka, że to jest okej, to wejdziemy, przemigrujemy się, będzie szybko, ładnie i w ogóle będzie super.

I to bardzo wiele firm wpada w tą pułapkę.

Teraz, żeby mnie zajmował ten, to rzucę taki kompletnie odjechany w drugą stronę, nie?

Czyli generalnie jest klient, przychodzi klient, rozmawia i mówi, żeby było jasne, rozmawiałem w zeszłym roku, tak?

I mówi, ja słyszałem, że na tym, na chmurze to się tylko czawy da uruchamiać.

Czy to prawda, nie?

Więc generalnie ludzie nie edukują się i przez to mają kompletnie jakieś odjechane wyobrażenia.

Po pierwsze, co ta chmura może, jaki będzie miała wpływ itd.

To jest ta kosztowa bajka, nie?

A druga najczęściej, nie?

Czyli przeniesiemy się do chmury, przeniesiemy te maszyny, w ogóle wszystko zacznie działać lepiej itd.

A druga to jest kompletnie odjechane jakieś wyobrażenia, co to robi, jak to robi itd.

Tomek dołączył do nas, jak usłyszał o mitach, to może niech powie.

Tak, pojawiły mnie trzy najczęstsze z tych.

O dwa już w sumie padły.

Pierwszy to jest taki, że w chmurze jest bezpiecznie.

Jak idziemy do chmury, to będziemy bezpieczniejsi.

I bardzo wiele osób w pierwszej kolejności zapomina, że na dzień dobry jest nawet o wiele mniej bezpieczne, niż wychodząc z własnego dęta center, podłupią pewną fizyczną izolację, którą mieli.

I tej magii tam nie ma w chmurze.

Drugi to jest też to, co Wojtek powiedział, że chmura jest stabilna i że nasze usługi będą tam stały, nie padały i działały.

I też ludzie sobie nie zdają sprawy, jak szybko koszt rośnie w funkcji tego, jaką stabilność chcemy uzyskać.

Tutaj są podrazdy.

I dodam, że też zakładamy, że vendor umie w stabilne usługi.

Że nie tylko nasze usługi będą stabilne, tylko że usługi vendora będą stabilne.

Ja nawet na świecie myślałem o usługach vendora bardziej niż o naszych.

Wiem, że ten dobry kod, który dobrze działa w chmurze, to jest w ogóle zupka.

Ale umieliśmy mówić o CPI, a nie o inżynierach.

A trzeci to jest, że da się być cloud agnostycznym.

I to jest dla mnie jeden z największych mitów.

No bo tak, jak firma zaczyna myśleć o byciu cloud agnostycznym, zaczyna mówić konteneryzacja, kubernetesty i tak dalej.

Ale prawda jest taka, że to jest tylko wierzchołek góry lodowej.

No bo tak, skonteneryzujemy, postawimy na kubernetesie.

Ale kubernetest to co?

Bierzemy zarządzane od vendora?

No to już się trochę mocno wiążemy.

No po co?

Może na gołym metalu, na VM-kach?

No to poziom skomplikowania o wiele rośnie, ale VM-ki też trzeba zgabernować.

Trzeba postawić wokół tego sieciówkę jakieś wejścia.

A co ze storage'em, z bazami danych?

No okej, storage, zrobimy abstrakcję na kubernetesie, ale bazy danych muszą być.

SQL jest przenośny tak długo jak jest przenośny, potem nie jest, więc zawsze musimy nasze aplikacje przerzucać do konkretnej implementacji SQL-a.

To co?

Będziemy stawiać bazy danych na metalu i tak dalej.

I ta cloud agnostyczność, ona bardzo szybko pęka w szwach.

O wiele szybciej niż się komuś, kto próbował to praktycznie zrobić, kto nie próbował to praktycznie zrobić, mogłoby wydawać.

Więc jak dla mnie cloud agnostyczność to jest bardzo duży mit.

Bo jeżeli ktoś chce się szybko przenieść z jednej chmury na drugą, to musi tak naprawdę aktywnie, chociażby w kompletnej rozdzielności, mieć to środowisko po obu chmurach i mieć je przetestowane, żeby ono działało.

Tak to pół roku albo i więcej, zanim on w drugiej chmurze wstanie.

Takie moje top 3 mitów odnośnie chmury.

To ja się zgodzę co do tego buzzwordu, że jesteśmy agnostyczni, bo też próbowałem i to nie działa.

Nie zgodzę się do końca, ale to pewnie te słynne IDPEN z tym bezpieczeństwem, bo był w pewnym momencie, zgadzam się, taki hype po tych wyciekach, że dobra, to chodźmy do chóry, tam będzie bezpieczniej.

I moim zdaniem to może być prawda, jeżeli zrobiłeś to dobrze.

Miałeś, nie wiem, dobrego partnera, vendor ci pomógł, ale generalnie był taki hype właśnie, że chodźcie do chmury, bo będzie bezpieczniej.

Także tutaj tak 50-50, można by pewnie podyskutować.

A mój ulubiony to ten najstarszy chyba, że chodźmy do chmury, bo nie trzeba zarządzać infrastrukturą, więc w ogóle wypieprzymy nasz dział IT i będzie taniej.

Łączy się z tym taniej w chmurze, które też jest mitem oczywiście.

Ja jeszcze mam podobną opinię na temat wypowiedzi Tomka.

Nie zgadzam się co do bezpieczeństwa.

Uważam, że w chmurze jest większe, natomiast zgadzam się, że to jest mit o tym, że można przenosić swoje aplikacje pomiędzy chmurami w świat diagnostycznym.

Ja tylko wejdę w obronie Tomka trochę w tym, ale tak jakby kontekst.

Dlaczego po przejściu do chmury jest bezpieczniej?

Bo to miejsce, z którego wychodzimy, jest w takim stanie, że nawet jak je przeniesiemy do chmury, to będzie lepiej niż jest w tej chwili.

No tak, ale takie są realia, bo w większości wypadków to w ogóle żadna firma prywatnie nie ma startu do takich data center, no największej trójki, nie wiem, jak jest w Chinach.

Znaczy, na przykład obronie sam siebie w chmurze może być bezpieczniej, o wiele bezpieczniej, nawet bymi się mi to argumenty, które już padały, pod tytułem mamy gotowe wszystkie rzeczy związane z różnymi wymogami typu compliance i tak dalej.

Tak, to wszystko w chmurze jest.

Natomiast większość organizacji na dzień dobry patrząc na chmurę myśli, ja tam po prostu pójdę i będzie bezpieczniej.

I to nie jest prawda.

Zrobienie bezpieczniej chmury dla różnych specjalistów i tym podobnych rzeczy.

To jest myśl, który kraży, że ludzie myślą, po prostu przeniosę swoje wordprody do chmury.

Tak, jeżeli mówimy, że sama migracja rozwiąże nasze problemy, to oczywiście pełna sprawa.

Tak, ale tutaj znowu dochodzimy, albo przynajmniej ocieramy się o koszty, bo jak ja zaczynałem z chmurą jakieś 6 lat temu, to lift and shift był w ogóle wszędzie, o nim słyszeliśmy, ale o tym już nikt nie mówi, przynajmniej w tej chmurze, w której ja pracuję, bo to po prostu się nie sprawdziło.

Nie będę mówił, że to było kłamstwem, ale to było wielką pomyłką.

Lift and shift okazał się być mega drogi dla klientów i stąd też niektóre firmy zdecydowały się wyjść i stąd też się mówi, że chmura jest droga.

Ale jak się robi chmurę dobrze, to chmura może być tańsza.

I kolejna rzecz, która jest niesamowitą zaletą dla firm może bardziej dojrzałych, to jest coś takiego jak unit economy.

W chmurze jesteś w stanie policzyć, ile kosztuje Cię pojedyncza transakcja.

Nawet do tego stopnia, że Twój klient klika po różnych stronach Twojej aplikacji webowej.

To jest kompletnie niepoliczalne w on-premie.

I ja byłem na dwóch projektach w dwóch bankach jeszcze powiedzmy 15 lat temu i dokładnie wiem, że liczenie kosztów i przydzielanie, alokacja ich pomiędzy różnymi aplikacjami jest cholernie trudne, to jest mało powiedziane.

W chmurze to się da zrobić i to pozwala pójść na dużo wyższy poziom współpracy pomiędzy IT i biznesem i ten temat wątek, bo nie jesteśmy wszyscy znudzeni od czasów, kiedy Agile powstał, ale on jest ważny, co nie?

No bo ten CTO mityczny, o którym tutaj rozmawiamy, on nie dostał kasy po to, że się bałeś technologią, tylko po to, żeby pomóc zarabiać pieniądze firmie, co nie?

I to jest ogromna zaleta, że te koszty można bardzo łatwo połączyć z zyskami i powiedzmy z biznesem ogólnie mówiąc.

Dzięki za te głosy, bardzo fajnie to podsumowaliście.

Ja bym chciał, bo mamy jeszcze parę minut tradycyjnie, jeden temat, który nam się tutaj wszystkim spodobał i chciałem was zagadać.

Słuchajcie, jaka jest przyszłość chmury, czyli co widzicie, jakie trendy i taka wielka prośba, może nie dotykajmy jakichś oczywistych, tylko takie smaczki, jakbyście mogli wyciągnąć te parę minut, żebyśmy zdążyli się podzielić jakimś ciekawym doświadczeniem.

Sebastian, może ja ciebie teraz wywołam do tablicy, bo dawno się nie wypowiadałeś.

Znaczy, ja widzę kilka rzeczy, które wyglądają dosyć ciekawie.

Pierwszy to jest popularność modelu open core, czyli ludzie robią biznesy dookoła produktów open source'owych i robią te biznesy zazwyczaj jako menedżowane usługi.

Powstały nowe licencje, które spotkały się z dużą krytyką środowiska open source'owego, ale właśnie umożliwiają rozwoj tych modelów i to powoduje, że powstają bardzo ciekawe mikrochmury specjalizowane, czyli na przykład jakaś baza danych, która jest przepisanym na przykład jakąś, powiedzmy, kawką ze zgodnością na poziomie protokołu, natomiast jest przepisane gdzieś tam w niskopoziomowym C z wykorzystaniem dobrodziejstw NVMe, czyli działa dziesięć razy szybciej, tak tu oczywiście w cudzysłowie, niż ta oryginalna napisana na JVM-ie.

To oczywiście jakiś taki głupi przykład, akurat się Red Panda inspirowałem, natomiast prawda jest taka, że są produkty, które może nie to, że robią breakthrough, ale czasami przez tą zgodność in, zgodność protokolarną, są replacementem drop-in egzystujących usług i robią niesłą furorę.

Także wydaje mi się, że taka innowacja na poziomie mikrochmur to będzie trend, no bo nie da się być najlepszym we wszystkim, no to po prostu nie działa, tego się nie da kupić na przykład za pieniądze.

Także jest coraz więcej fajnej innowacji tego typu, to jest taki pierwszy trend, który widzę, a inny trend, który widzę, to jest też to, to jest taki, powiedziałbym, convenience, czyli pojawiają się na przykład usługi po prostu jako endpoint.

My już w ogóle nie chcemy się wcale bawić z infrastrukturą.

Jest duży, był duży hype w środowisku, zachęcięcie się serwerless-owością i takim modelem pay-as-you-go, i jak już się raz tego dotknie, to ciężko się potem od tego odkleić, a więc w przypadku takich funkcji, takich serwisów, które są stateless, jak na przykład Lambda, to bardzo fajnie działało, no ale już mniej fajnie działa w przypadku tych, które są stateful, bo pojawiają się ograniczenia, pojawiają się pewne rozróżnienia, pojawiają się pewne nieporozumienia, jeżeli chodzi o to, jak rozumieć tego typu usługę.

Więc usługi na przykład database as an endpoint, a jeszcze dodatkowo z bardzo fajnym wykorzystaniem AI, to będzie już mój ostatni komentarz, to też wydaje mi się, że to jest przyszłość.

A o co chodzi z tym AI-em?

Chodzi właśnie o tą bezobsługowość, że kiedyś mieliśmy bazę danych, w których trzeba było wykonać całkiem sporo jakichś ręcznych operacji.

I te ręczne operacje, to mam na myśli takie, począwszy od tego, że nie wiem, deklarujemy jaka kompresja kolumny, jaki typ kolumny, deklarujemy jakie indeksy i jeszcze bawmy się w jakieś wakiumy, niewakiumy.

Natomiast na chwilę obecną, ten tak zwany AI, który tak naprawdę jest po prostu fajnymi modelami, które zostały nakarmione bardzo dużą ilością danych operacyjnych, jest w stanie bardzo wiele jeszcze robić za nas, w sposób zupełnie transparentny.

Czy to nie jest produkt pewnej znanej firmy, która miała zaorać pewną inną firmę?

Wiesz co, to już jest wiele produktów wielu firm.

Także powiem Ci, że chyba wiem, na kogo masz na myśli, natomiast to już jest trend, który jest, według mnie, widać powszechnie.

Nie, no, ale to jest sensowne...

Mogę komentarz...

Usunięcie pracy takiej zwyczajnej, nie?

Tak, daj mi, proszę.

Już nie wiecie, co do AI-a się zgadzam.

Ja chciałbym, i to bardziej są takie moje indywidualne przemyślenia ogólne, nawet nie chodzi o trend, bo trend jest, czyli sassify everything, tak?

I Ty trochę, Sebastian, do tego nawiązałeś, mówiąc o endpointach, czyli totalnej wygodzie.

I teraz tak, oczywisty plus i każdy dyrektor IT, z którym ja rozmawiałem, poziom enterprise, żeby było jasne, żebyśmy właśnie nie mieszali tego, nie?

To bardzo chce albo sasa, albo taki endpoint do usługi, czyli dostaje to, co chce i nie muszę tego utrzymywać.

I teraz to, co ja myślę, jeżeli chodzi o long term i przyszłość, jest ogromna bitwa o to, co się stanie, jak się totalnie sassyfikujemy.

Bo już patrząc na tych największych graczy, mówię tutaj o SAP i SAP Rise, mówię o Oracle, mówię o, nie wiem, Salesforce'ach, czy nawet o zwykłym Atlassianie, tak?

Przejście na sasa u nich, jak sobie ktokolwiek odpali Excelka i policzy, a przecież ci CFO w enterprise'ach nie są głupi, long term wychodzi drożej.

A jeszcze nie wiemy, na ile spadnie jakość usługi, gdy, że tak powiem, ktoś zmonopolizuje rynek.

No, SAP moim zdaniem takim monopolistą lekkim jest.

I naprawdę klienci są mocno niezadowoleni.

Takie sygnały do mnie docierają.

Więc tu jest ta jasna strona tego endpointa, a wydaje mi się, że być może wylądujemy w dość mrocznej przyszłości, kiedy ten rynek już się tak skrystalizuje, prawda?

I będzie taki podzielony tort i oni będą generalnie cenowo i jakościowo robili, co chcieli.

Po prostu masz rację, ale tylko pomyśl też o tym, że jeżeli jest taka sytuacja, że jest jakaś, powiedzmy, w nawiasie, w cudzysłowie, trwała nierównowaga na rynku, czyli jest usługa, która ma bardzo mocną pozycję, a z drugiej strony jest po prostu zbyt droga, no to to jest zawsze zaproszenie do konkurencji.

Ja na to liczę, Sebastian, wiesz o co chodzi.

I większe rozdrobnienie, bo w oboce SAP-ów na przykład to było niemożliwe, bo jednak SAP tak naprawdę robił wszystko.

Tak, dlatego tak nawiązuję do tego SAP-a, nie?

Bo to jest taki król, którego bardzo ciężko obalić, ale już powoli niektóre...

Przy większym rozdrobnieniu to wygląda trochę inaczej.

Czas nam się kończy.

Ja mam tak trochę bardziej do technologii, bym wrócił z tymi moimi predykcjami i wszyscy wiemy, co to jest infrastructure as code.

Wydaje mi się, że ten temat zostanie pociągnięty z pomocą również sztucznej inteligencji na zupełnie nowy poziom, gdzie my jako programiści i architekci będziemy bezpośrednio definiowali te infrastruktury, a chmura sama ją nam będzie definiowała na podstawie tego, jak aplikacja jest używana.

I tutaj szybko wejdę w jakiś przykład.

Powiedzmy, jak wiadomości pomiędzy dwoma mikroserwisami możemy przesyłać na wiele różnych sposobów, my nie będziemy tego definiowali, bo znawca nam dobierze najlepszy sposób ze względu na to, jaka jest nam niezbędna szybkość i również jaki jest wolumen tych wiadomości.

Albo może w pierwszej kolejności poprzez wolumen, bo to jest najłatwiejsze.

Ja może zamknę małą klawiaturę, najpierw anegdotyczną.

To, co powiedziałeś, to będzie bardzo farfetczne, bo ja w ogóle jestem w Windows 3 i nie wiem, czy ktoś w ogóle wie, że Microsoft miał taki projekt, który służył do tego, że wkładasz płytkę, bo to miała być płytka jeszcze, do serwera i on szuka twoją sieć i właśnie robi to, co powiedziałeś.

Instaluje wszystkie produkty i powoduje, że komunikują się ze sobą same i nie musisz ich konfigurować, połączyć pomiędzy nimi itd.

Ja też pamiętam z zamierzchłych lat takie coś, co się nazywało model Driven Architecture, że wyrysły WML-u i system powstaje i wiesz, że już programiści nie będą potrzebni.

Trochę to w przyszłości chmury też postaram się, z mojej strony taka opinia, żeby to już trochę domknąć.

Według mnie są dwa główne trendy, one będą z dwie strony szły.

Z jednej strony chmura będzie znikać po prostu, bo będzie przychodzić bardziej utility, tą konfigurację AI i tego typu rzeczy, co powiedzieliście, i ona po prostu zacznie znikać.

Z drugiej strony będziemy mieli bardzo długi ogon firm, które będą dalej wpadały w pułapkę przenoszenia infrastruktury itd.

To będzie trwało prawdopodobnie następne 20 lat dalej, więc będziemy mieli dwie prędkości.

Induży będą je utrzymywać.

Dlaczego?

Bo ta pierwsza to im napędza innowacje, ta druga napędza rewe jeszcze bardzo długo.

Dzisiaj jest 9.32.

Michał, jak się pytał wcześniej, kto się pytał, na ile musimy nastawiać, powiedziałem, że na godzinę.

Słuchajcie, będziemy zawijać.

Dobra dyskusja.

Pytanie, czy powinniśmy zaplanować dogrywkę.

Łapki w górę.

Zresztą ja chcę wiedzieć, co na pewno, bo sporo nam zostało.

Zostawcie nam łapki w górę, zostawcie nam komentarze, czy warto dotknąć, ale sporo tematów nie zdążyliśmy dotknąć.

W Krakowie słonecznie, w Warszawie pochmurnie, jak w innych częściach świata, nie wiemy.

Będziemy zawijać The City of Morning Coffee.

Zajrzyjcie na naszego YouTuba podcast, tam są archiwa.

To też się pojawi, ale za dłuższą chwilę, więc jak macie kogoś, kto by chciał to posłuchać, to taki link działa forever.

Możecie go wysłać komuś, jak kliknie, to odsłucha.

No co, miłego weekendu.

Dzięki bardzo, trzymajcie się, hej.

Trzymajcie się, pa, pa.

Napisy stworzone przez społeczność Amara.org Dziękuję za uwagę i do zobaczenia w kolejnym odcinku.