Jak zwykle dzieje się dużo: Maersk, hey.com a AWS i onprem, Microsoft - czy to Serverless czy autoskalowanie? a także Google i Service Weaver for Writing Distributed Applications
…i wiele więcej!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Szymon Warda: Cześć Słuchacie Patoarchitektów Prowadzą Szymon Warda…
Łukasz Kałużny: …i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io/65 albo gdzieś na dole w Twoim playerze do kliknięcia.
Szymon Warda: Dobrze Łukaszu, linki. Co tam masz ciekawego?
Łukasz Kałużny: Dobra, zaczynając może od Maerska - takiej nowej technologii…
Szymon Warda: Doprecyzujmy. To nie jest Maersk, ci od kontenerów.
Łukasz Kałużny: Tak, ale ten Maersk też zajmuje się kontenerami.
Szymon Warda: Tak.
Łukasz Kałużny: Więc jakiś czas temu mówiliśmy o Davidzie Heinemeierze Hanssonie i Hey.com. Czyli taka duża usługa mailowa, która się ładnie zaczyna rozbudowywać w jakimśtam światku basecampów i innych rzeczy. I oni powiedzieli, że wychodzą z AWS-a do onpremu, bo jest tani.
Szymon Warda: Tak, pamiętamy to dokładnie.
Łukasz Kałużny: Tak, dokładnie. Przymierzali się tam u siebie, bo opisali tą drogę, przymierzali się do Kubernetesów i innych rzeczy. Enterprisowa sprzedaż ich odstraszyła, mieli tego dość. Sam Kubernetes w onpremie - stwierdzili, że nie chcą budować specjalnie zespołu i kompetencji pod to, co mnie nie dziwi, ale napisali własnego toola do deploymentu kontenerów, który się nazywa Maersk i napisali to na swoją potrzebę. Pozbyli się tak naprawdę całej otoczki Kubernetesowej i to co robią, to w prosty sposób przygotowują serwer tym toolem i deployują sobie na nim po prostu standalone’owo obrazy kontenerów.
Szymon Warda: Jestem ciekawy za ile - bo to nie jest pytanie: czy, ale za ile dojdą do opcji żeby te kontenery przynajmniej restartować jak nie działają. Potem monitorować i potem będą powoli, ten taki creep będzie szedł w kierunku orkiestracji tego, bo pójdą w tym kierunku, bo to jest potrzebne. Żeby nie było: rozumiem, czemu nie poszli w Kubernetesa.
Łukasz Kałużny: Inaczej - nie, zrobili np. sondy i inne rzeczy, poowijali te template’y, różne rzeczy. Więc ja jestem naprawdę ciekawy. O tak. Jak będzie wyglądało, bo patrząc się jak ja na to patrzę - przez pryzmat Ruby on Rails, czyli gdzieś tam ta wysoka produktywność. No i pytanie właśnie jak to? Czy zostaną przy tym minimalizmie, czy jednak gdzieś skręcą w coś quasi Kubernetesowego?
Szymon Warda: Nie zostaną z prostego powodu, będą rekrutowali ludzi, którzy znają Kubernetesa znałem go możliwości. Szli na zasadzie to by mi się przydało i faktycznie się przydało, bo nie od parady Kubernetes ma tak wysoką adopcję, bo ma dużo rzeczy, które po prostu się przydają. Ma ogromny próg wejścia i tak dalej. To jest w pełni słuszne, ale dlatego właśnie masę firm go bierze po maturze, których my potrzebujemy, więc oni dojdą do tego stanu generalnie w utylizacji, a obecnie stworzyli własnego toola do wewnętrznego deploymentu, co jest jeszcze gorsze.
Łukasz Kałużny: No właśnie tak jest, to dałoby się to prawdopodobnie obalić kawałkiem terraforma i ansemble’a.
Szymon Warda: Raczej - Realnie?
Łukasz Kałużny: Realnie, realnie tak.
Szymon Warda: W ich sytuacji tak, ale w sytuacji jak chcą mieć małą skalę to to właśnie chmura jest odpowiedzią tak naprawdę.
Łukasz Kałużny: Wiesz co, nie będę się… Bo patrząc się na… Jak policzyli sobie, że i tak lecą na opensource, to im się to nie opłaca. Akurat od tej strony tak, jestem w stanie uwierzyć.
Szymon Warda: Ja też jestem w stanie uwierzyć. Tylko pytanie jest takie, jak liczyli? Bo wiadomo, że księgowość jest rzeczą płynną i co wliczasz w koszty i jak te koszty liczysz - to różnie Ci może wyjść. No nie? O to mi chodzi.
Łukasz Kałużny: Tak? Jeżeli tak, różnie możesz wyjść - tylko zobacz, z ich perspektywy i tego… Może tak - z perspektywy, że czy mi się to opłaca czy nie. Pisanie Toola? Tak szczerze? Wątpię.
Szymon Warda: No właśnie, to to jest bez sensu trochę dla mnie.
Łukasz Kałużny: Za to, czy ten powrót ich z cloudu do onpremu się mógł opłacać? Jeżeli tak większość robili na modłę infrastrukturalną na EC dwójkach, a usługi elasticowe były…
Szymon Warda: Tak.
Łukasz Kałużny: Manage są diabelnie drogie, to ściągnięcie tego na open source na VMki na twoich blachach jest tańsze.
Szymon Warda: Jest. Jak się chowa lasy.
Łukasz Kałużny: Tak ,jak pasów nie korzystali, a wiesz utrzymanie nawet dużych baz danych. No nie oszukujmy się, jeżeli posiadasz potrzeba dużo ludzi żeby utrzymać bazę danych w dobrym stanie.
Szymon Warda: Zgadza się, jakoś jestem ciekawy to się rozwinie. Wydaje mi się, że będzie powoli, powoli.
Łukasz Kałużny: Zobaczymy, będzie potem tak, albo będą gdzieś wracali.
Szymon Warda: Tak. Coś jeszcze masz?
Łukasz Kałużny: Wiesz co? Następna rzecz, która jest ciekawa. To w Googlu odkrywają lata 90’te, bo tak bym troszeczkę powiedział patrząc się na podejście. Zostało sobie Service Weaver Framework for Writing Distributed Applications. Czyli jest sobie taki framework do Golanga, jak na razie wydany przez Google jako open source, które ma umożliwić pisanie modularnego monolitu. I uwaga tadam tadam, deployowanie go jako mikroserwisy.
Szymon Warda: Wiesz co, nie powiedziałem że to jest z ‘90tych, bo jak patrzę właśnie na kod, jaki tam jest tak szybko, to też wygląda trochę znajomo do tego co było robione w Service Fabricu dla kodu. Wiele lat temu były takie właśnie opcje, że Service Fabric zanim miał opcje deploymentu tam kontenerów i tak dalej, to można było tam pisać kod C#owy w service fabricu. Wygląda znajomo bym powiedział.
Łukasz Kałużny: Raczej od tej strony tak, tylko tam było takie mocne rozgraniczenie do tego. Tutaj jest tak naprawdę w tym przypadku wszystko ma być ukryte tak naprawdę przed deweloperem. Czyli piszmy, odpalajmy u siebie lokalnie monolit i on nagle automagicznie przez całość, która została tam dodana zacznie się deployować i auto skalować na różne mikroserwisy.
Szymon Warda: Ten service fabricowy kod… też plany były, tam była opcja taka, że tylko trzeba było odpowiednich typów używać, że tam listy były automatycznie rozproszone i tak dalej. Ciekawy kawałek.
Łukasz Kałużny: Tamten był akurat w tym. Wiesz co, dla mnie to jest troszeczkę… Właśnie dość fajnie się wypowiedział Woody na ten temat na Twitterze, że trzeba sobie przypomnieć, że właśnie prawidła rozproszonych systemów istnieją.
Szymon Warda: Zgadza się, ale uważam mimo wszystko, że to jest dobry kierunek, w którym należy iść, no bo… Ukrywać właśnie te rzeczy, bo to jest taki Service Mesh 2.0 bym powiedział, że tak ładnie to rozprasza na poziomie kodu. De facto. To nie jest proste, ale to jest kierunek, w którym zdecydowanie powinniśmy iść.
Łukasz Kałużny: Znaczy wiesz co, jestem ciekaw, raczej: kierunek. Zauważ, że tutaj chowasz synchroniczność, asynchroniczność i inne rzeczy. No właśnie jest takie, że może inaczej. Bardzo mocno chowasz - na początku może to będzie. Wiesz. Jak ktoś takie coś użyje, takiego podejścia… Na początku będzie super. Pytanie jak bardzo się rozjedzie w trakcie.
Szymon Warda: Pytanie jak bardzo to będzie leaky abstraction, to jest takie… Ile będzie automagii i na ile w pewnym momencie to Cię kopnie w tyłek. No nie?
Łukasz Kałużny: No teraz wygląda na sporo automagii.
Szymon Warda: Tak więc może mocno kopnąć w tyłek.
Łukasz Kałużny: Dokładnie.
Szymon Warda: Pewnie to nie jest finalna wersja.
Łukasz Kałużny: Tak, bo to announcement.
Szymon Warda: Podejść będzie bardzo dużo generalnie w weaverze i jeszcze innych rzeczach.
Łukasz Kałużny: Tak, więc jest to ciekawe. Wiesz, patrząc się z takich już dziwolągów. Bardziej mi odpowiada model Dapra, czyli Distributed Application Runtime’u.
Szymon Warda: Tak, zdecydowanie.
Łukasz Kałużny: W szczególności, że też dorobili się paru tych. Może trzeba będzie omówić, bo dorobili się paru nowych ficzerów ciekawych. Dobra, co u Ciebie.
Szymon Warda: Ja… Znowu będzie. Bo dawno żeśmy CloudFlare’a nie chwalili, ale tym razem, tym razem, żeby było ważne - chwalimy go nie za to co wypuścili, ale wypuścili za… Bloga. Post na blogu jest cloudflare’owym, zwie się How CloudFlare Runs Prometheus At Scale. I żeby nie było, nie jest to wpis. On jest długi. W ogóle. Nie jest to wpis o tym jak cloudflare odpala swoje 900parę Prometeuszy. Tak, to spora ilość. Więc totalnie to nie jest opowieść o hiper skali. Nie, to jest super fajny wpis o podstawach Prometeusza. Jak działa, jakie są podstawowe założenia, jakie są dobre wzorce skalowania pojedynczych instancji, nawet i przejście przez zrozumienie wszystkiego w Prometeuszu, żeby mieć taki… Dobry punkt startowy do tego, żeby później rozumieć jak on działa, żeby później rozumieć co nas kopnie z tyłu i żeby później rozumieć de facto jakie ryzyka nam chodzą, skonfigurować go, rozszerzyć itd. Naprawdę dobry wpis. Nie jest totalnie o setkach Prometeuszy pracujących równolegle. Jest o tym bardziej jak nawet pojedyncze instancje odpalić dobrze. I jak działa. Super wprowadzenie.
Łukasz Kałużny: Fajne są właśnie, że w jednym miejscu zgromadzone bebechy, bo pokazują nawet chunki tych metryk. Fajnie rysunkowo, gdzie zostały zapisane w tym momencie w czasie, w tym momencie w czasie. I do tego to służy, więc jest dość fajnie pokazane. Właśnie. Memory mapping Old chunks, Writing blocks to disk, więc to wszystko jest w krokach opisane co.
Szymon Warda: Cały cykl życia.
Łukasz Kałużny: Co pod spodem robi i fajnie też widać tam na przykładach. Właśnie ten wpis fajnie graficznie oddaje, bo jest pokazanie labeli, czyli od tego jak mamy te metryki olabelowane do chunków graficznie więc to są w ogóle super rzeczy.
Szymon Warda: Dużo zrobili dobrze. Tytuł jest totalnie niepasujący do tego co jest w artykule, ale naprawdę jako wprowadzenie do zrozumienia Prometeusza. Super! Nie widziałem niczego tak, żeby w jednym miejscu było tak dobrze zebrane. Polecam zdecydowanie.
Łukasz Kałużny: Tak, jest to super.
Szymon Warda: A tak to mam dwie jeszcze rzeczy, małe rzeczy tak, do dyskusji. Pierwsze - Microsoft wprowadza Serverless do baz SQL’owych. To już od dawna jest.
Łukasz Kałużny: Od dawna wprowadza, o tak, bo one ciągle się pojawiają.
Szymon Warda: Ale tym razem dodali to tego tiera, może typu bardziej, Hyperscale. Czyli mówimy sobie tam 80 CPU, 100 terabajtów danych i tak dalej i tak dalej. Kilka przemyśleń w kontekście tego oczywiście. Tutaj gwałciliśmy oczywiście pojęcie serverless. Bo to nie jest serverless. Ale słusznie!
Łukasz Kałużny: Tylko pozwól mi jedną rzecz powiedzieć. Akurat AWS, serverless, pojęcie serverlessu i dużo osób tutaj przyklaśnie z części AWSowej, że bardzo mocno zgwałcił w swoich produktach.
Szymon Warda: Tak, chodzi mi o to generalnie, że nie mam z tym problemu w tej wersji, bo na czym my mamy ten serverless? Płacimy za stałe użycie. Jak są większe pliki to też za nie płacimy. To się auto skaluje, więc mamy auto skalowanie baz SQLowych, a jak mamy stop computed to po jakimś czasie nam te bazy są wyłączane, że nie ma tam ruchu. Co jest super dobre jeżeli mówimy o takich ogromnych zbiorach danych, bo to jest często… Po prostu odpalamy jakieś raporty, te rzeczy, które pracują w peakach, więc tak naprawdę to co nam to daje to jest auto skalowanie. Przy czym uwaga bo ten hyperscale jeszcze nie ma zatrzymywania. To dopiero będzie w kolejnej iteracji. Ale podoba mi się fakt, że to zdejmuje strasznie dużo Opsów z prawidłowego ustawienia baz relacyjnych i oszczędzania kasy, bo te bazy są z reguły pierwszym albo drugim większym kosztem w jakiejkolwiek usłudze. Jak popatrzymy - a nagle jak wchodzimy do tego tiera serverless, który też jest trochę droższy mimo wszystko, ale zdejmujemy ten cały narzut na zatrzymywanie ich, skalowanie i tak dalej. Więc to bardzo fajny kierunek, w którym usługi podążają.
Szymon Warda: Według mnie.
Łukasz Kałużny: Tak, dla dużych rzeczy spoko.
Szymon Warda: Dla małych to nie ma sensu, nie oszukujmy się.
Łukasz Kałużny: Tak. Znaczy wiesz, zawsze jest sens, bo mieliśmy przecież przypadki nawet z naszych, Szymon, konsultacji, gdzie opłacało się zeskalowywać z ośmiu core’ów do dwóch Postgresy w nocy i przynosiło to niezłe oszczędności.
Szymon Warda: Zgadzam się tylko właśnie jak mówimy, znaczy, ma zaoszczędzisz jak najbardziej. Tylko teraz pytanie ile zaoszczędzisz per godzina pracy? To jak masz 80 CPU, to będzie to zauważalna różnica powiedzmy sobie, no nie.
Łukasz Kałużny: Tak, to jest już zauważalna.
Szymon Warda: Tak więc to mnie naprawdę cieszy. A druga opcja. Google wprowadziło nowe umowy dla klientów. Nazywa się to Flex. Chodzi głównie o to, że tak naprawdę jest trochę łatwiej klientom wejść w lepsze usługi. Nie musi być… Nie muszą nas obowiązywać takie long term agreements, długich umów na przyszłość, wieloletnich itd. Obniżyli próg wejścia i to, co mnie zastanowiło, bo jestem mega ciekaw, bo przez ostatnich paru odcinków mówiliśmy o tym, że właściwie ten cały Cloud, chmura, dorosła i tam już się niewiele dzieje. I to mnie zastanawia - czy jeszcze możliwe jest przetasowanie na tym rynku? Zmiana kolejności?
Łukasz Kałużny: Wiesz co, dobra.
Szymon Warda: Wydaje mi się, że nie do końca.
Łukasz Kałużny: Patrząc się na te rzeczy to jest po prostu model umów w Google’u, chyba z dużych dostawców najbardziej ssał do tej pory.
Szymon Warda: Tak.
Łukasz Kałużny: To tam, patrząc się na osób z takiej mojej perspektywy i teraz - zabawy, jak mówimy o całych przetasowaniach innych rzeczach, nie wierzę, że one się przy tej skali, że się zadzieją. Raczej - jeżeli już, to prędzej dojdzie do zbalansowania. Raczej nie nazwałbym przetasowaniem, ale rebalancing, czyli że może w Googlu przychody urosną, w AWS-ie bardziej spadną i wszyscy się zatrzymają na podobnym poziomie po prostu posiadania trocinków z rynku, tych dużych.
Szymon Warda: Tak, wydaje mi się, że tam się już dużo nie zmieni za bardzo. Tak naprawdę. To jest bardziej ewidentnie odpowiedź Google’a na wymagania rynkowe, na bardziej wymagania sprzedaży, na większy próg wejścia, bo to jest głównie dla korporacji, bo tam jest wprowadzenie planu Enterprise, Enterprise Plus itd. Więc o tym mówimy, ale już tam dużych ruchów nie będzie, jakichś wybuchów, zmian i tak dalej.
Łukasz Kałużny: Nie, słuchaj, wiesz, jak sobie popatrzymy na ten cloud. Multi Cloud dla aplikacji w większości przypadków jest mitem. Jak sobie popatrzysz.
Szymon Warda: Nie, nie jest mitem. Jest zbyt drogim przedsięwzięciem.
Łukasz Kałużny: Dlatego mówię, że z tej perspektywy jest mitem. Ja to oceniam, jako że dla większości przypadków jest mitem i niepotrzebnym… To tak, jak zmiana chmury. To tak jak zmienimy bazę, zmienimy bazę relacyjną, tak będziemy… Zazwyczaj przepisujemy. Jak zaczynam analizować, to kończy się zazwyczaj zmianą produktu albo przepisaniem. Każdy ma jakieś preferencje, każdy ma jakieś wady i zalety. Jak potem bierzesz większość przypadków jakichś architektur, zabawek i tak - plusy i minusy z każdej z chmur i usług, które tam są, one się balansują. Dochodzą, wyrównują, wyrównują się. Nie ma takiego super, że pójdź tam, zrób to, pójdź tam, zrób to, pójdź tam, zrób, zrób to. Jeżeli patrzysz się holistycznie na wszystkie usługi, bo w poszczególnych przypadkach tak znajdziesz przypadki, że w danym cloudzie usług jest bardzo lepsze, ale to jest już taki cherrypicking, który… Lepiej skupić się na jednym cloudzie i przełknąć, że jakaś pierdoła tam gdzieś jest lepiej zrobiona i zrobić sobie porządnie to w jednym miejscu.
Szymon Warda: Tak albo wymagania… Jeżeli chodzi o regulatorów to jest drugi element, gdzie może być twarde - tak.
Łukasz Kałużny: Są chmury prostsze i trudniejsze do zrobienia tego.
Szymon Warda: Tak, dokładnie. Może inaczej, bardziej przygotowane, ogólnie przygotowane?
Łukasz Kałużny: Hahaha, o tak, to lepsze określenie.
Szymon Warda: Dobrze. To ja, tyle. Kończymy na razie.
Łukasz Kałużny: Trzymajcie się, na razie.
Szymon Warda: Hej.