W najnowszym odcinku “Patoarchitektów” zanurzamy się w głębinach sztucznej inteligencji, rozprawiając o najgorętszych trendach i kontrowersyjnych technologiach, które wstrząsają branżą IT.
Przez meandry LLM-ów (Large Language Models), rzucamy światło na gorączkowe zmagania z AI i otwieramy debatę na temat przyszłości serverless oraz infrastruktury jako kodu.
Rozgrzebujemy nie tylko technologiczne potyczki między gigantami jak Nvidia, Google czy Microsoft, ale też wnikliwie analizujemy wpływ tych technologii na codzienną pracę programistów i architektów.
Nie zabraknie pikantnych opinii na temat mikroserwisów, modulitów, a także przemyśleń na temat opensource i jego miejsca w ekosystemie chmurowym.
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka znajdziecie lewo, góra, w opisie. Dobrze Łukaszu, co wygrzebałeś?
Łukasz Kałużny: Dobra, to lecimy, dzisiaj bardzo u mnie LLM-owo.
Szymon Warda: Dzień jak co dzień.
Łukasz Kałużny: Tak, dzień jak co dzień. Pierwszy link z The Wall Street Journal i wreszcie to, co trochę też gdzieś tam mówię, że z całym tym, nazwijmy to, AI-em, rzuceniem się na GenAI, to jest gorączka złota i że kurz zacznie kiedyś opadać.
Szymon Warda: I tak jak zawsze najwięcej zarobią ci, którzy sprzedają siekierę.
Łukasz Kałużny: I łopatę, więc cała zabawa z łopatą, czyli w tym wypadku Nvidia i parę innych, ale tutaj zabawa z łopatą jest taka, że klienci, early adopterzy, zaczynają się zastanawiać czy Copilot jest warty swojej ceny dla M3.6.5.
Szymon Warda: Akurat to jest ciekawe, bo akurat to jest jedna z tych usług, których bym nie podejrzewał o to, żeby się nie zwróciła, że tak powiem.
Łukasz Kałużny: Tylko że ludzie patrzą, zobacz, że jedyna skuteczna rzecz, która jest, to są dwie funkcje w tym momencie, jak popatrzysz. To jest recap ze spotkań.
Szymon Warda: Przydatne, zdecydowanie.
Łukasz Kałużny: I tylko po angielsku, to też trzeba powiedzieć.
Szymon Warda: Ogólnie to wszystko najlepiej działa po angielsku.
Łukasz Kałużny: Ale chodzi o same funkcje. I druga rzecz, która będzie, to gdzieś podsumowanie maili.
Szymon Warda: To akurat jest przydatne.
Łukasz Kałużny: Dobra i koniec funkcji. I teraz sobie popatrz, ok, dla pojedynczych użytkowników, ale czy to się zwraca szeroko w firmie?
Szymon Warda: Wydaje mi się, że właśnie o to chodzi. Dla pojedynczego użytkownika to jest tak niewielki koszt versus pensja tego użytkownika, że to ma sens, jak najbardziej. Kupienie tego na chybcika wszystkim w firmie nie ma sensu, to się z tym zgodzę, bo to będzie realnie duży koszt, który będą wykorzystywali tacy bardziej power userzy, ludzie, którzy mają jakiś tam technologiczny sznyt. Spora część ludzi dalej trzyma wszystkie swoje pliki na pulpicie tak naprawdę…
Łukasz Kałużny: Ale całość pokazuje, w sensie te Copiloty dla PowerPointa i innych rzeczy nie potrafią więcej niż na demach i to w o wiele gorszej jakości.
Szymon Warda: I nie będą potrafiły tak naprawdę. To dalej będą toole, z których zysk będą mieli ludzie odrobinkę techniczni, którzy będą chcieli się nauczyć. Masa ludzi przychodzi do pracy, chce robić to tak, jak robiła przez ostatnie 10 lat i nie ma w planach zmienić swojego podejścia.
Łukasz Kałużny: Ale wychodzi na to, że darmowy Copilot wystarczy większości.
Szymon Warda: Tak, większości wystarczy. Dopiero ci, którzy chcą i się po to zgłoszą, dopiero im trzeba to kupować i tam ten zysk z inwestycji będzie istotny.
Łukasz Kałużny: W szczególności, że w darmowym, to jest też ciekawostka w sumie, zmienił się ostatnio limit znaków na 18000 znaków. Jeżeli używamy go w formie notebooka, to już w ogóle w większości załatwia sprawę.
Szymon Warda: Powinna, zdecydowanie.
Łukasz Kałużny: Dobra, co u Ciebie?
Szymon Warda: Łukaszu, ja mam słówko dnia, czy może nie dnia, ale wydaje mi się, że roku, tak poważnie mówię: Modulith. Nie Monolith, Modulith, czyli monolit składający się z modułów.
Łukasz Kałużny: Czyli ktoś wymyślił nową nazwę na modularny monolit.
Szymon Warda: Oczywiście, że tak. W ogóle nazwa pochodzi ze Springa i Spring wypuścił swój cały framework, bo oczywiście generalnie, bo jak można pisać systemy nie mając frameworka? Przecież w tym momencie nie wiadomo gdzie zacząć.
Łukasz Kałużny: Jak można robić coś w Javie nie mając nowej nazwy na to.
Szymon Warda: Mamy kilka linków tutaj w ogóle tego. Wyszedł artykuł quasi naukowy, jak się go przeczyta, to nie jest taki bardzo naukowy. On generalnie bada popularność fraz, dwóch właśnie, Modulith Springowy i Google Service Weaver, oba to są właśnie frameworki do pisania właśnie modularnych monolitów tak naprawdę i bada właśnie jak bardzo mocny wzrost jest tak naprawdę, szczególnie 2023, to praktycznie wyleciało pionowo użycie. I w ogóle coraz więcej artykułów, pewnie też się spotykasz z tym, że jest odnośnie tego, że mikroserwisy be, a modularny monolit, albo po prostu jakieś tam systemy trochę większe niż mikro, to już sensowne. Pomijam fakt, że zataczamy kolejne koło i po prostu zamiast pisać te serwisy dobrze skupiliśmy się na elemencie mikroserwisy i wracamy do tego samego. Ale zastanawiam się czy to 2024 nie będzie takim rokiem po prostu powolnej mimo wszystko śmierci mikroserwisów.
Łukasz Kałużny: Wiesz co, ale dla mnie Service Weaver jest tym samym co [język obcy 00:03:52], czyli do kosza.
Szymon Warda: Bez dwóch zdań tak, ale bardziej pokazuje to, że to jest szukanie jakiegoś sposobu na ułożenie większych niż mikroserwisy i oczywiście nanoserwisy, jeszcze te mikro, piko i w ogóle tego było sporawo, ułożenie tego w jakieś sensowne ramy technologiczne, bo to w tym kierunku pójdzie. Mikro nie mają żadnego sensu. Ładne serwisy podzielone domenowo to jest to.
Łukasz Kałużny: Dobra, tylko zobacz, że i teraz bawimy się nadal w całość, gdzie jest rozsądna analiza biznesowa? Inaczej, nazwijmy problem, tu w ogóle nie mamy problemu z developmentem. Bounded context zaginął, analiza biznesowa i ogólnie projektowanie modelu systemu. I teraz jak sobie popatrzysz, to jest ważne, że model systemu to nie jest jego logiczna implementacja, w jaki sposób go zaimplementujemy, jak będzie wyglądał kodzik i inne czyste gówienka, które tam zrobimy wokół. Tylko to jest powiedziane sobie jak on przetwarza te dane, jak je przechowuje, jakie ma encje, jaka jest logika i tego nikt nie robi. Kiedy ostatnio widziałeś, żeby ktoś poświęcił i zamodelował system zamiast go kodować?
Szymon Warda: Nie mam na to czasu. Łukasz, nie wygłupiaj się.
Łukasz Kałużny: Musi być demo z niedziałającym UI-em.
Szymon Warda: Ale tak nabijając się generalnie, to tak, rola analityka systemowego człowieka, który wie wszystko o systemie tak naprawdę praktycznie wymarła, tak naprawdę, tu się zgadzam. Mikroserwisy się sprawdziły w sytuacji właśnie takich systemów zwinnych, bo tam po prostu mogliśmy dodawać te systemy, dodawać i dodawać. Monolity były trudne, bo musieliśmy zmieniać wszystko i mieliśmy duży zakres rażenia, ale odbiliśmy się od mikroserwisów. Widać po prostu, że to jest nie utrzymywalne tak naprawdę.
Łukasz Kałużny: Tak jak od funkcji, innych rzeczy, bo rozwiązujemy technologią problemy, które są w zupełnie innym miejscu.
Szymon Warda: Problemy miękkie, tak, to się nie sklei.
Łukasz Kałużny: I zobacz, mikroserwisy powstały do rozwiązania problemów miękkich. Raczej miękkich, raczej bardziej super twardych, czyli skalowania organizacji inżynierskiej.
Szymon Warda: Tak, tylko że powstały dla organizacji typu Netflix, bo tam się to zaczęło, dla zespołów, gdzie mieliśmy kilkuset developerów, a nie 20. Taka mała różnica.
Łukasz Kałużny: Nawet inaczej, Ty miałeś po 50, 60 w projekcie i też nie wymagało to mikroserwisów.
Szymon Warda: Absolutnie nie wymagało, naprawdę, w zupełności nie wymaga. Ale w ogóle słówko “modulith” jest perełką dla mnie. Wydaje mi się, że będziemy więcej o nim słyszeć, tym bardziej, że już mamy słówko kluczowe i można dalej szerzyć i chwalić się na Twitterze czy tam na X-ie. Co tam masz dalej?
Łukasz Kałużny: Dobra, może na razie bez nabijania się. Ciekawa rzecz, Google wypuścił nowe opensource’owe LLM-y, czyli Gemmę i benchują się do Llamy, że są wydajniejsi od Llamy. To jest ciekawy kierunek. Patrząc jeszcze, że w zeszłym roku, mniej więcej rok temu poszła analiza, że największym zagrożeniem dla ich biznesu jest opensource.
Szymon Warda: Wydaje mi się, to jest takie mówienie w kontekście pod regulatorów i wcale tak nie jest, wydaje mi się. Będziemy o tym rozmawiali z naszym pewnie przyszłym gościem, tak że generalnie taki damy zwiastunek, że tak powiem.
Łukasz Kałużny: Tak, to patrząc, wypuścili odpowiedniki wielkością, żeby się porównać do Llamy. I to jest taka ciekawostka, że to idzie i tych lokalnych modeli pojawia się coraz więcej. Pytanie, kiedy zaczną się pojawiać możliwości zbudowania przez nas, dotunowania małych lokalnych modeli?
Szymon Warda: Właśnie, bo powiedziałeś to słowo kluczowe. Ja bym rozgraniczył, wewnętrznych modeli, to mogą być duże modele, które chodzą w organizacji i lokalnych na lokalnej maszynie, to co sobie Nvidia wypuściła, chat na RTX.
Łukasz Kałużny: Raczej docelowo zobacz, weźmiesz telefon, zobacz jakie to jest idealne miejsce, żeby pojawił się tam wstępny model.
Szymon Warda: Zgadza się. Wydaje mi się, że jeszcze kawałek drogi, musimy poobcinać te wszystkie rzeczy zewnętrzne, żeby to się ładnie tam zmieściło.
Łukasz Kałużny: Na pewno, wiesz, jest jeszcze dużo.
Szymon Warda: I nie będzie łatwo. Dobra, to ja znowu żeby trochę zbalansować Twoje LLM-owe tudzież AI-owe elementy, to mam serię trochę przemyśleniową, artykuł na InfoQ, który wieszczy koniec Serverlessa, koniec IaC-a, że to będzie zastąpione przez composition as code, CaC i przez kompozyty w ogóle. Artykuł jest całkiem niezły, jest dość długawy, ale jest całkiem niezły. Nie ze wszystkim się zgadzam, ale punkty pewne ma całkiem niezłe. Odnośnie Serverlessa, zauważyłem jedną prawidłowość i tu bym się z nią zgodził, że umiejscowienie, coraz więcej serwisów, te usługi chmurowe, one mają coraz więcej dodatkowych funkcjonalności: cato routing, API Gate, wszystkie Gatewaye mają teraz routing, mają parsowanie URL-i, niektóre dorobiły się np. mapowania requestów, że mamy taki request wejściowy, możemy go zamienić na zupełnie inny schemat, itd. To samo mamy z eventami, że możemy filtrować, możemy batchować, możemy też mapować je, itd. I coraz mniej tego kodu jest wymaganego po stronie kodu developera tak naprawdę, coraz mniej musimy pisać. I oni przez to wieszczą całą śmierć w ogóle serverlessa, tudzież to, że cały FAS, Functional Service, nie będzie już tak bardzo potrzebne. Według mnie bzdura, bo całą serię artykułów, gdzie on po prostu pokazuje, że ma wartość. Ale jeden element mnie zastanawia i jestem ciekawy co o tym myślisz? Bo o ile przenoszenie pewnych funkcjonalności, typu batchowanie, itd., do usług jako taki ma sens, bo to jest kod powtarzalny, platforma powinna to obsługiwać.
Łukasz Kałużny: Można wynieść funkcjonalność.
Szymon Warda: Tak, ale mamy teraz takie tematy typu właśnie mapowanie schematów, zmiana schematu requestów, albo zmiana schematu eventów, czyli taki, jak ktoś jeszcze pamięta, czyli takie mapowanie, że to pole tu, to pole to, wzbogacamy, tak wygląda to pole, takie pisanie po prostu transformat JSON-owych, czy tak dalej. I to już jest śliskie.
Łukasz Kałużny: W zależności jaką Ty masz tam logikę.
Szymon Warda: No właśnie,. Ja bym powiedział więcej, a skąd wiesz jaką będziesz miał logikę za pół roku?
Łukasz Kałużny: Cała zabawa będzie, że powinniśmy przestać się martwić co będzie za pół roku. W sensie i teraz zobacz, dojdź do tego, jeżeli zaczynasz robić na takich klockach i nie masz na to miejsce w kodzie, to znaczy, że będziesz w stanie się potem przepisać na kod w miarę elastycznie.
Szymon Warda: Ja bym wolał inny kierunek. Zamiast tego, żeby usługi były po prostu, napiszmy sobie transformatę płaską, po prostu dajmy możliwość łatwego wywołania funkcji. Wolę to mieć w funkcji, wolę mieć w funkcji generalnie coś-tam propertyA=propertyAB, propertyAC= A + B, itd., to jest, zamiast mieć takie głupie mapowania w formie jakiegoś tam pliku konfiguracyjnego. Bo ja się kiedyś bawiłem, fajny system w ogóle, ale to na dłuższą metę jest nie utrzymywalne.
Łukasz Kałużny: Raczej wiesz, to jest Enterprise Service Bus, które zakończyły swoją karierę.
Szymon Warda: Tak, dlatego uważam, że ruch w kierunku tego, żeby te serwisy, usługi właściwie miały coraz większe możliwości, takie techniczne typowo, ma to sens. Transformaty śmierdzą mi. Ale teraz kolejna teza z tego artykułu i to jest dość ciekawa, hiperspecjalizacja. O co chodzi? To, że powstaje coraz więcej serwisów, usług dostarczanych wokół opensource’u, które dają pewne wąskie bardzo funkcjonalności. Czyli nie powstają takie SAS-y z jedną usługą, nic więcej. I teraz ciekawostką jest to, że to ma sens. Np. taki Mongo Atlas jak najbardziej ma sens. Cały, co Confluent Cloud robi wokół Kafki, generalnie to ma sens.
Łukasz Kałużny: I teraz jedna rzecz o przypadkach, o których mówisz, to zobacz, że one są hostowane u hyperscalerów i masz je dostępne u hyperscalera.
Szymon Warda: O to właśnie mi teraz chodzi, bo to właśnie był mój teraz element, o którym chciałem pogadać. To jest to, że Mongo Atlas można hostować w Azure, generalnie w innych usługach. Spoko. Confluent Cloud też. Ale jest duża grupa tych właśnie takich wąskich opensource’ów, które nie są hostowane kompletnie właśnie w chmurach, mają swój własny hosting. I teraz ciekawostka to jest, wydaje mi się, że to będzie w tym kierunku szło, tylko teraz jak do tego podejdziemy w kierunku generalnie sieciówki prostej, żeby to chodziło jednak po prywatnej sieci, że to nie jest hostowane właśnie w tych GCP, AWS-ach i Azure’ach. Bo wobec tego będzie musiało w jakieś rozwiązanie pójść, którego obecnie nie ma. Więc jestem ciekawy, czy te nasze duże chmury wchłoną te obszary, czy jednak oni będą trzymali się osobno.
Łukasz Kałużny: Zobaczmy, bo to jest taka, z kimś tam miałem dyskusję, może kiedyś trzeba będzie do tego wrócić, masz kilka rodzajów firm, jak sobie popatrzysz, na rynku. My jesteśmy przyzwyczajeni pracować z firmami. Jak teraz popatrzysz na jedną rzecz, my albo pracujemy ze startupami, software house’ami i firmami, które mają na tyle duże działy IT, że albo zamawiają software na swoje potrzeby, albo ten software house mają u siebie. I jest cała nisza, że tak powiem, firemek, startupów SAS-owych i innych takich rzeczy, któremu ktoś coś robi ad hoc, ktoś, kto nie interesuje się bezpieczeństwem, governancem i takimi rzeczami. I nie ma powiedziane jak ma jego infrastruktura wymagać, nie ma żadnej myśli przewodniej jak będzie wyglądał ekosystem u niego w firmie i co tam wszędzie się znajdzie. Raczej nie, inaczej, to nie zginie, ale to nie wybuchnie dalej. To już osiągnęło swój pułap i teraz zresztą mówienie, że weźmy pierwszego Vercela, który jest na liście, to jest po prostu static content hosting gdzieś tam, który ma CloudFlare, możesz odpalić sobie w GitHubie, u każdego dostawcy cloudowego masz na to jakieś rozwiązanie. Więc to jest mówienie, że tam kawałek opensource’owy jest zintegrowany i oni żyją z tego, że kontrybuując do open source’u i go drive’ując dokładają u siebie jakieś tam rzeczy i to będzie żyło w swoich niszach.
Szymon Warda: Zgadzam się, ale też mam kontrargument. Zobacz na ekosystem, który istnieje wokół mobilki. To jest po prostu ekosystem, który żyje kompletnie poza dużymi dostawcami chmury. Całe publikowanie, CI/CD do tego, itd., to jest poza chmurą kompletnie, ponieważ ludzie od backendu, frontendu, bazy danych tego nie ogarniają, stwierdzili: ogarnijcie sobie to sami. I to jest wycięte w ogóle z tego całego systemu.
Łukasz Kałużny: Masz tam Firebase’a, który jest królem + rzeczy na jakichś funkcjach i innych rzeczach. Bo wiesz, to jest, tak jak powiedziałem, startup, SAS-owa część i tyle.
Szymon Warda: SAS-owa, ale tam nie jakieś dane są, tam jakieś połączenia są, więc wydaje mi się, że temat będzie rósł razem z czasem i będziemy się powoli godzili, że dla pewnych zestawów danych będziemy po prostu lecieli po publicznej sieci z odpowiednim oczywiście, itd.
Łukasz Kałużny: Raczej, że będą takie. Zauważ, że firmy już wyrosły z tego, żeby pisać swoje wewnętrzne aplikacje mobilne i już ten trend zginął.
Szymon Warda: Ale dalej ktoś to musi robić generalnie, ktoś to robi i z software house.
Łukasz Kałużny: Raczej nie, ja mówię o wewnętrznych. Ja nie mówię o takich, że internalowe apki zginęły, zewnętrzne, to jest zupełnie inny świat.
Szymon Warda: A internal w ogóle nie ma już nigdzie żadnego sensu. Nie oszukujmy się. Trzeci element z tego artykułu całkiem ciekawy, composition as code. To jest ciekawy kawałek. Mianowicie twierdzą, że bicepy, terraformy, itd., umierają, że ludzie przerzucają się w kierunku Plumi czy też AWS Cloud Development Kit. I teraz argumentacja “czemu?” zaskoczyła mnie, powiedziałbym, że też trochę mocno. To jest to, że np. developerzy potrzebują w funkcjach dynamicznie tworzyć infrastrukturę i do tego w ogóle te języki deklarowalne się nie nadają. To jest absolutną bzdurą, totalną bzdurą. Ale faktycznie na rynku widać dość mocno trend w kierunku tego, że ludzie nie lubią tych języków deklarowanych. Często to, że nie lubią, wynika z tego, że nie rozumieją i wszystko pisaliby w jednym swoim języku. Są dwa ciekawe trendy. Kiedyś generalnie było to, że developer musi znać dziesięć języków po prostu i każdy ma inny język. A teraz wchodzimy, kolejna skrajność, znam CSharpa, to będę robił wszystko w CSharpie.
Łukasz Kałużny: Raczej wróć: znam framework i pełen zestaw bibliotek.
Szymon Warda: Tak, na tym się kończy.
Łukasz Kałużny: Bo to już się do tego sprowadza.
Szymon Warda: Tak, ale jednak mimo wszystko jest ruch w tym kierunku i dla mnie on nie jest wcale jakiś pozytywny, bo te deklarowalne języki są dużo czytelniejsze. Teraz czytanie, jak się tworzy infrastrukturę w kodzie, to jest horror tak naprawdę, z całym szacunkiem.
Łukasz Kałużny: Inaczej, gdzieś to będzie miało swoje miejsce.
Szymon Warda: Będzie.
Łukasz Kałużny: Ja np., inaczej, wyciągając, żeby już nikogo nie wylewać z kąpielą, znajdę ileś i znowu wracamy do profilu firm, bo to jest zabawa. Jeżeli chcesz cokolwiek poukładać, prawdopodobnie tego w ogóle nie dopuścisz, bo w tym momencie pisanie takiego composition as code powoduje, że Ty nawet nie wiesz gdzie masz zadeklarowaną infrastrukturę. Do tego stopnia, że jak ktoś przychodzi, on nawet nie wie gdzie ma jak to przeaudytować, zobaczyć co jest. Druga strona, zrobienie w kodzie bezpiecznej konfiguracji. Jak ja sobie popatrzę jak u dostawców cloudowych wygląda np. bezpieczna konfiguracja usług, to ten developer, który chciałby w tym kodować, jak dostanie na twarz to, co ma zrobić, to się zapłacze.
Szymon Warda: Wracamy znowu do wewnętrznej platformy. developerskiej, czyli do IDP.
Łukasz Kałużny: I teraz znowu trafiasz, Szymon, na to, że znowu trafiasz inaczej. Jeżeli nie masz naprawdę 50, 60 osób, to nawet pierwsze inwestycje w IDP nie mają sensu.
Szymon Warda: Zgadza się, ale Łukasz zobacz, bo Twoja teoria jest taka, że małe firmy będą korzystały z Plumi, bo mają mało developerów, DevOpsów i generalnie i tak będzie. A duże organizacje będą korzystały ładnie z bicepa, itd. Ale te małe organizacje, one kiedyś urosną i przez to potem będą próbowały do swoich potrzeb, czyli po to żeby były bardziej Enterprise, itd. Więc wydaje mi się, że to jednak urośnie bardziej niż Ci się wydaje. Czy to jest dobry kierunek? Nie wydaje mi się.
Łukasz Kałużny: Dla terraforma to na pewno będą… Inaczej, Plumi już jest alternatywą w pewnym sensie, jak na to popatrzysz.
Szymon Warda: Będzie alternatywą dla bicepa, czy dla terraforma.
Łukasz Kałużny: Przepraszam, jak teraz przyjdzie jakaś kodująca małpa i spróbuje w infrze zrobić za dużo logiki…
Szymon Warda: Tak, jest, to będzie mega podobnie.
Łukasz Kałużny: I wiesz, że tak się stanie i sobie poucinają ręce, bo to jest małpa z brzytwą. Wiesz, bo teraz np. robimy pierwsze prawidło, które leci za tym, za całą układanką. Co z podziałem uprawnień, że nagle kod ma tworzyć po zdeployowaniu jakiejś usługi w cloudzie?
Szymon Warda: Zgodzę się, ale też są takie case’y, np. typu bazy, które są dynamicznie tworzone albo sytuacje multitenance’owe, które doskonale wiesz, że istnieją i tam te bazy, dlatego tam przydałoby się jakoś stworzyć. Terraform się do tego nie nadaje.
Łukasz Kałużny: Tylko wiesz, zobacz, jak mówisz o multitenant, to już bazami wjeżdżamy w temat B2B.
Szymon Warda: Tak, tak, oczywiście.
Łukasz Kałużny: Realnie. I tu już zaczyna się perspektywa, że masz już pierdyliard zazwyczaj rzeczy, jak chcesz zrobić B2B i chcesz sprzedawać coś do dużych. Bo zazwyczaj, no sorry, jeżeli potrzebujesz multitenance z wydzieloną bazą danych chcesz sprzedawać do dużych.
Szymon Warda: Albo masz coś bardzo mocno regulowanego.
Łukasz Kałużny: Tak i zaczynamy zabawę, że to już ta droga się nie sprawdzi. I onboarding takiego klienta zupełnie inaczej wygląda.
Szymon Warda: Ale masz też case taki naprawdę, że jednak masz te przypadki, że musisz dynamiczny, terraform się nadaje, bicep nadaje się dużo lepiej, ale dalej masz jakiś taki backpropagation, konfigurację masz odrzuconą w wielu miejscach. Jest to upierdliwe. Czy mi to pomoże? Nie, nie pomoże, absolutnie to nie rozwiązuje problemu, ale widać, że ludzie szukają. Dobra, lećmy dalej. Co tam masz? Bo to jest temat na długą dyskusję.
Łukasz Kałużny: Co do tego, potestowałem Plumi, inne podejścia. Za duża dowolność kodowania powoduje u mnie, że jest to na nie.
Szymon Warda: Ja się z Tobą w większości zgodzę. Bardziej mi chodzi o to, że rynek w tym kierunku będzie szedł. Będziemy widzieli ciekawe rzeczy.
Łukasz Kałużny: Lecimy. Następna rzecz to LLM-y, dla równowagi. To Mistral i Microsoft ogłosili swój partnership. Jeżeli chodzi o model, który wydają gdzieś tam, w testach dogania GPT4, jak sobie popatrzymy, w zależności kto i jak testował, pomińmy to już. I trzy ciekawe rzeczy, które są w partnershipie. Po pierwsze, Microsoft oczywiście daje moc obliczeniową.
Szymon Warda: Cóż by innego? Dokładnie.
Łukasz Kałużny: Tak. Druga rzecz, to że model będzie dostępny w modelu Model as a Service w AI Studio. I to jest też ciekawy sposób tego hostowania, że nie musisz się martwić, wyrzucasz. I druga rzecz, co jest najciekawsze z tego wszystkiego oczywiście i pokazuje całość, Microsoft szuka sobie dywersyfikacji w całym tym, mimo, że postawił na OpenAI-a, to pod spodem dywersyfikuje. To również, że będą współpracować na temat trenowania, w szczególności, uwaga, AI Research właśnie Microsoftu i Mistrala, bo Mistral jest francuski. Będą pracować wokół dla wybranych tych, for selected customers including European public sector workloads.
Szymon Warda: Wydaje mi się, że ten zakup będzie też elementem właśnie takim, że…
Łukasz Kałużny: Raczej zakup, to jest jeszcze partnership, nie zakup, jeszcze nie.
Szymon Warda: Partnership, niech będzie partnership tego, że MS ładnie patrzy na Europę i MS w przeciwieństwie do AWS-a, jest Europą realnie zainteresowany. Więc elementy governance’u i compliance, jeżeli chodzi o europejskie prawo, to jest wartość Mistrala w dużej mierze.
Łukasz Kałużny: Dobra. Co u Ciebie?
Szymon Warda: Ja będę kończył. Właściwie mam tylko jeszcze jeden link, zestawienie. Jeden z założycieli startupu dzieli się po czterech latach co mu zagrało, co mu nie zagrało. Kilka rzeczy, które zwróciły moją uwagę. Po pierwsze, czemu wybrali AWS-a kontra GCP? Dlatego, że opiekun do AWS-a był przy nich i się nimi opiekował, a od GCP generalnie mogli sobie tylko maila wysłać co najwyżej.
Łukasz Kałużny: Ale klasyka.
Szymon Warda: Ale fajnie pokazuje, bo w obecnej sytuacji co, czy masz jakieś bardzo mocne elementy, które przy wyborze chmury? Powiedzmy Azure, jak potrzebujesz być bardzo mocno, jeżeli chodzi o firmy. AWS, jak potrzebujesz wirtualki. DigitalOcean, jak piszesz w Ruby właściwie i tworzysz szybko. I masz GCP, jak potrzebujesz Big Query, to śa takie mocniejsze. Tak to generalnie chmury już się od siebie nie tak dużo różnią. Dajesz.
Łukasz Kałużny: Czy wiesz co? Dobra, to jedna rzecz, jak mówisz o takim wybraniu chmury, to co powiedziałeś. Dlaczego Azure wygrywał w Polsce? Bo account’ci Microsoftu chodzili, chodzili i chodzili i byli na każde zawołanie klientów, którzy byli zainteresowani.
Szymon Warda: Tak, ale realnie chmury się od siebie wcale tak dużo nie różnią, więc ta opieka od swojego account managera jest istotna tak naprawdę, bo tam dużo możesz uzyskać. Więc to jest naprawdę dobry powód na wybór konkretnej chmury. Dobra, dalej lecimy. Używanie baz danych, bardzo mu się sprawdziło, o dziwo. To zasmuci wszystkich juniorów, ale seniorzy nie polecają premium supportu. I teraz pytanie, tak mnie zastanowiło, czy jeżeli nie masz wymagania, czy nie potrzebujesz premium supportu jako dupokrytki, bo to często kupujecie jako dupokrytki, czy realnie premium support ma sens dla organizacji? Bo on jest mniej więcej w cenie powiedzmy sobie developera.
Łukasz Kałużny: Wszystko zależy od skali i potrzeby dupokrytek, nic więcej.
Szymon Warda: Właśnie, jako dupokrytka, super, jako inne rzeczy, do przemyślenia. Dalej lecimy. Co mi się sprawdziło? Miesięczne spotkania kosztowe. To jest w ogóle dobry pomysł, faktycznie powinno być. Co mi się nie sprawdziło dalej? Współdzielenie baz przez wiele serwisów. I to jest coś chyba, co musi każdy się nauczyć the hard way i obić sobie dupę po prostu, bo…
Łukasz Kałużny: Minimum to schematy, ale to wiemy o tym.
Szymon Warda: Tak, ale to i tak się nie sprawdzi. Data Dog, super fajny, super drogi i kompletnie… Ale też co u mnie się nie sprawdziło? Nie sprawdziło mi się dlatego, że model opłat w klastrze Kubernetesowym mi się nie podoba, ponieważ oni skalują się node’ami. I w tym momencie jak z 10 przejdą na 20, to płacą za 20 przez cały okres. Więc to jest ciekawe wyzwanie dla tych wszystkich APM-ów tak naprawdę, jak będzie się rozwijało. Co mi się mega sprawdziło? Kupienie własnych adresów IP i to mnie zdziwiło bardzo mocno, ale w sumie tak, tak naprawdę, bo to im daje przenośność między chociażby wieloma providerami chmurowymi, to można sobie wykupić. To jest sensowne, bo daje im przenośność. Jednak jak łączy się z B2B, będą od Ciebie wymagali jakiegoś stałego adresu IP…
Łukasz Kałużny: Ciekawe, bo ja tak się zapytałem, co robił ten startup?
Szymon Warda: Wiesz, że nawet nie sprawdziłem tego tak naprawdę.
Łukasz Kałużny: Bo jak słyszę o adresach IP…
Szymon Warda: Kresta.
Łukasz Kałużny: Dobra.
Szymon Warda: Dla B2C to nie ma sensu. Dla B2B to ma sens, potrzebujesz stałych adresów IP.
Łukasz Kałużny: Tak, raczej czy wiesz, stałych, bardziej teraz już większość i tak już FQDN. Nie wchodzimy, trzeba by było zobaczyć co ten produkt robi i co dokładnie robią. Wiesz, też mówienie o przenoszeniu. Każda chmura ma bardzo dziwne ograniczenia z Bring Your own IP, więc to też jest takie… No dobra, uważam to za dziwne w całości. O tak, to jest już moje…
Szymon Warda: Bardzo specyficzne, powiedziałbym tak, ale mnie jakoś tam zaciekawiło. Nie zaczęcie z Open Telemetry, tego żałują tak naprawdę, bo faktycznie z Open Telemtry jest łatwiej zacząć, szczególnie w kontekście, jeżeli widać było, że się z Datadoga chcą wynieść. I co jeszcze? Ostatnia rzecz, automatyzacja post mortem z użyciem Slack bota. Tam w ogóle mają w Slack bot’cie przypominajki. Mnie zastanawia to, że tak naprawdę mieliśmy kiedyś wszystko w mailach, okazało się, że mamy za dużo, zrobiliśmy Giry i inne systemy. Okazuje się, że tam za dużo, to przerzuciliśmy się teraz do Slacka i tak uciekamy od kolejnych systemów, ponieważ sobie popsuliśmy, mówiąc to ładnie tak naprawdę, flow i komunikację w innych systemach przez nadmiar rzeczy bez obudowanie tego za bardzo.
Łukasz Kałużny: Zobacz ile tu jest produktów, jak popatrzysz na tej liście.
Szymon Warda: Zgadza się, ale chodzi mi o to, czy będzie procesowo, czy w ogóle pomysł na to, żeby mieć procesy w Slacku jest dobrym. To jest naprawdę słaby pomysł. Slack jest fajny do rzeczy, które mogą wyparować. To jest jakiś system wiadomościowy, ale to nie jest system do trzymania procesów i budowania procesów. Przynajmniej dla mnie. Nie używam go tak i nie widzę go. I ten cały taki pęd, że miejmy wszystko w Slacku, picie dużej ilości Slacka, że tak powiem, zachłyśnięcie się Slackiem. Trochę nie tędy droga.
Łukasz Kałużny: Mnie zdziwiło, że do buildów używali Bazela. To było dla mnie takie zdziwienie jak to sobie przelatywałem, całość. I reszta to nie było… O i narzekanie na Secret. To raczej nie dziwi mnie na koniec dnia z całości tych zabawek.
Szymon Warda: Co tam masz?
Łukasz Kałużny: Ostatni link w takim razie. I to jest już taka też ciekawostka LLM-owa. Blablabla, LLM-y znowu, ale jest automatyczny red teaming z wykorzystaniem agentu od Microsoftu, automatyczny red teaming chatbotów i ogólnie rzeczy, które wykorzystają Generative AI. Jest biblioteka Pythonowa, ale założenie jest takie, że targetujemy sobie promptem jakiś docelowy system i mamy agenta, który wspiera Cię w próbie jego jailbreakowania, przejścia i w ogóle.
Szymon Warda: Pomysł jest świetny, ciekawe jak to się spisuje w praktyce.
Łukasz Kałużny: Wiesz co, nawet sobie odpaliłem tego demko, tak żeby sprawdzić lokalnie i wygląda to obiecująco.
Szymon Warda: Pytanie moje jest dalsze, czy będzie to odpowiednio rozwijane? To, że jest obiecujące, to w to wierzę.
Łukasz Kałużny: No właśnie. I teraz sobie popatrzymy. Dlatego mówię, to jest świeżynka, ma 65 commitów, ostatni 17 godzin temu, jak to nagrywamy, więc jest to zupełnie nowe, jak wszystko w tej części, że tak powiem, ale dobrze, że już się pojawia.
Szymon Warda: Ma sens? AI do tego będzie sensowny? Dobre użycie, adresowanie realnego problemu? Super, żeby tylko tego nie zabili po drodze. Moje jedyne ale.
Łukasz Kałużny: Wiesz o tym, że tak się może zdarzyć, jak z każdą taką rzeczą, która jest super szybkim eksperymentem.
Szymon Warda: Bo nie jest to rzucenie na pożarcie klientom i sprawdzenie czy to w ogóle chwyci, czy jest potrzeba.
Łukasz Kałużny: Raczej jest potrzeba. Może inaczej jeżeli chodzi o zabawki takie, jest potrzeba.
Szymon Warda: Czy rynek za to zapłaci? Może tak to ujmę.
Łukasz Kałużny: Wiesz co, płacisz wykorzystaniem OpenAI-a.
Szymon Warda: Tak, o to chodzi. Ale czy klienci za to zapłacą? Czy kupią tą usługę dokładnie?
Łukasz Kałużny: Dobra, to kończymy.
Szymon Warda: Na razie, hej.
Łukasz Kałużny: Na razie.