Ostatnie Patoszkolenie w tym roku👇
Reinvent AWS-owy – sprawdzamy, czego można się dowiedzieć na kolejnej konferencji w świecie IT.
Linki i ciekawe znaleziska:
Łukasz Kałużny [ŁK]: Cześć, słuchacie Patoarchitektów. Prowadzą: Łukasz Kałużny
Szymon Warda [SW]: i Szymon Warda. Wszystkie linki do tego odcinka znajdziecie oczywiście na patoarchitekci.io/56. Będzie jedno ważne ogłoszenie: robimy sobie mały prezent świąteczny, czyli przerwę. Wracamy dopiero 13 stycznia, tak że chwilę od nas odpoczniecie. Za to mamy dzisiaj dość treściwy odcinek podsumowujący – Reinvent AWS-owy.
ŁK: Tak. Postanowiliśmy się poznęcać nad tą konferencją. Po GitHube Universe była kolejnym dużym zbiegowiskiem announcementów u dużego dostawcy, więc poświęcimy dzisiaj specjalnie odcinek temu, co się tam pojawiło.
SW: I co ważne: zawsze osobno przygotowujemy linki, które nas interesują i w tej edycji zgodziliśmy się, co do jednego ważnego ogłoszenia (które wcale nie było jakoś mocno promowane w AWS-ie). Obydwu nas ucieszyło. Mianowicie: blue/green deployments dla baz relacyjnych – dla Aurory i dla AWS RDS. I to jest fajne, bo ktokolwiek robił wdrożenia, jeżeli chodzi o bazy, to wie, że blue/green zawsze jest megaproblemem.
ŁK: Raczej pojawiają się zawsze pytania: jak to przetestować, jak to sprawdzić, jak to zobaczyć. No i mamy wreszcie…
SW: Raczej bym powiedział z innego bardziej. No bo blue/green zakłada, że możesz potencjalnie na green nie pójść, czyli możesz po prostu wrócić de facto.
ŁK: Tak. To jest też jedna część. Tak. Czyli całe zabawy z tymi deploymentami. Oczywiście od razu tam podźgam to nożem, bo aktualnie jest to tylko dla MySQL-a.
SW: Tak, ale jednak mimo wszystko jest to ciekawe osiągnięcie. Jestem ciekawy, jak oni to zrobili pod spodem tak naprawdę.
ŁK: Wiesz co, to teraz moje zakłady, co tam jest pod spodem, bo nie oglądaliśmy szczegółowo każdego ogłoszenia – nie grzebaliśmy w bebechach. Obstawiam, że jest tam użyta synchronizacja… jakaś nakładka na synchronizację wbudowaną w MySQL. Dlatego jest to na Aurorze i na RDS-ie, czyli obu silnikach, a nie tylko na Aurorze. Zakładam, że wykorzystali tylko górę i zrobili dobrą nakładkę i orkiestrację tego.
SW: Raczej też bym zakładał właśnie, że trzymają kopię transaction loga i trzymają to w dwóch bazach potencjalnie. No, ale ogólnie jest to ciekawe. Bardzo się ucieszę, jeżeli to pójdzie w inne nurty. Powiem tak.
ŁK: Raczej bardzo miło by było, żeby Postgres był następny w kolejce.
SW: Będzie, bo z tego, co widziałem, faktycznie Postgres jest mocno rozwijany. Dorzucili Trasat language platform. Więc faktycznie Postgres, wydaje mi się, że będzie [niezrozumiałe]. Obstawiam tylko, że nie był teraz przez problemy techniczne, bo tego jeszcze nie ogarnęli do końca.
ŁK: No dobra, to co? Lecimy, czyli pierwsza rzecz: zgadzamy się. Raczej jest to ciekawostka, ale fajny kierunek w polerowaniu tego, jak działają nasze aplikacje.
SW: Znaczy… Ja to nazywam: taka trochę mała rzecz, która bardzo cieszy, bo to bardzo ułatwi życie. Tyle. Dobrze, Łukaszu, leć z kolejnym linkiem, który już się nie powtarza.
ŁK: Dobra, to lecimy. Nowości w ML-u, a dokładniej w governance, czyli całość, która się dzieje wokół ML-a. Pojawiają się ciągle pytania, jak robić ML OPS-a w Cloudzie i w ogóle. Jak do tego podejść: do całości, tym zarządzać. Druga rzecz, że gdzieś pojawiają się coraz bardziej, zbliżają się różne pomysły na regulacje prawne, na rozliczalność, odpowiedzialność tego wszystkiego. I dla SageMakera pojawiają się toole governancowe, ML-owe. Jedna rzecz: to jest dziwne, że tego nie było, bo to jest dla mnie w ten sposób, czyli roll manager, gdzie są wystosunkowane, predefiniowane sety uprawnień. I tak naprawdę na co ktoś może w danym modelu, przestrzeni sobie pozwolić. I to dziwne, że tego nie było. Na tej zasadzie. Bo jeżeli popatrzymy sobie na projekty w Google, na RBAC-a w Azurze, to w pewnym sensie te zestawy już tam były.
SW: Tak. W ogóle widać, że doszło dość sporo opcji, jeśli chodzi o security i governance, właśnie o dużo większy roll control. Odnośnie do tego, co Ty powiedziałeś, to moją uwagę zwróciło znowu Amazon Macie. Opcja serwisu, który odpalasz na backetach S3 i on wyszukuje dane wrażliwe, czyli nie musisz mieć… Generalnie masz masę tych backetów, masę danych i umożliwia przeszukiwanie co, gdzie masz wrażliwego, i na co musisz gdzie uważać. I to znowu: to nie jest stricte governancowe, ale to jest coś, tę wiedzę musimy mieć, żeby dobry governance na tym zrobić.
ŁK: Dobra. Ja jeszcze sobie pozwolę wrócić na chwilę do tego governancowego ML-a. Dodatkowo pojawiło się tam SageMaker model carts i to jest ciekawostka, czyli automatyczna dokumentacja tego, co działo się wokół modelu. Czyli zebranie na podstawie, że tak powiem, zebranych parametrów, że ma być takie pojedyncze źródło prawdy o trenowaniu, data setach, artefaktach, środowisku uruchomieniowym, jeżeli to wszystko robimy na tych pasowych komponetnach, czyli zebranie… Tak naprawdę coś, co było kawałkiem dokumentacji. Generowanie tego automatycznie, bez potrzeby robienia tego przez człowieka.
SW: A to zdaje się, czy to nie jest trochę przygotowanie pod wszelkie pomysły regulacji prawnych wokół tego, co tam się dzieje?
ŁK: Raczej dlatego… To o tym, co wspomniałem na początku, że to jest właśnie przygotowanie, bo trzeci pokazuje to idealnie. Czyli trzeci kawałek, który tam został zapowiedziany – model Dashboard.
SW: Mhm
ŁK: Czyli spięcie właśnie rolli, dokumentacji i pokazania tego. I co ciekawe, na Model Dashboard teraz się pokazuje, jak sobie zobaczymy, to, jaka jest tak naprawdę ocena tego modelu, jakie jest quality sprawdzone, data quality, czy jest zrobiona detekcja tego, czy to idzie w dobrą stronę, czy nie – używanie tego modelu. Czyli tak, jak wspomniałeś: raczej prawdziwe ML-OPS, żeby patrzeć, co się z tym dzieje i przygotować się na ten governance regulacyjny, który w tym obszarze prędzej czy później do nas trafi.
SW: Jeszcze kilka wpadek i trafi coraz mocniej. Odnośnie regulacji, co znowu ja mam wrażenie, że jest przygotowaniem do regulacji prawnych. Pamiętasz może, jakiś czas temu mówiliśmy sobie o kontekście wydajności energetycznej i całego carbon footprintu itd. i ogólnie instancje ARM-owe nie są niczym nowym w żadnej chmurze, one po prostu istnieją. Ale jak się…
ŁK: W zależności kto. AWS z dużych dostawców jest w tym względzie pionierem.
SW: Tak. Jest tego najwięcej. Ale co zwróciło bardzo mocno moją uwagę, to jest to, że jeżeli jak się czytało announcementy odnośnie rzeczy ARM-owych, bardzo mocno były promowane i bardzo był mocny nacisk, że to jest pod kątem bycia oszczędnym energetycznie i [niezrozumiałe]. Czyli ewidentnie jest przygotowanie i jest robiony marketing właśnie pod to, że tu jest lepiej i prądowo będzie dużo przyjemniej. Więc wydaje mi się, że tu też się dzieje, tak naprawdę. To jest takie trochę dmuchanie tematu.
ŁK: Jedno tak, tylko druga rzecz… Już tego akurat nie będę poruszał w tym odcinku, poznęcamy się o tym w przyszłości. Ale AWS-owi zależy bardzo, Amazonowi, dba bardzo o marżę. Pamiętaj, że pierwsze instancje były zrobione po to i zrobili od razu na własnym stosie, żeby zacząć pozbywać się dominacji Intela u siebie i nie dzielić się marżą.
SW: Ależ tak. To jest absolutnie na pewno. Ale jednak ta obudówka PR-owa wokół tych instancji bardzo mocno naciska właśnie na tą wydajność energetyczną.
ŁK: Tak, tylko że wiesz co… w pierwszych było tak naprawdę wydajność. I to jest ciekawa zmiana, bo na początku to była wydajność do centów, że tak powiem. Ile wydajności wyciskasz z danego centa względem na przykład Intela. Przy czym ten cent wynikał też m.in. z oszczędności na prądzie.
SW: Oczywiście, że tak.
ŁK: Tak. Wydajności. Teraz są kolejne tego, że tak powiem, iteracje. Patrząc się na to, akurat jestem fanem pod spodem tego, jak budują całą infrastrukturę na bazie ARM-ów. Bo są, daleko idąc, najbardziej rozwinięci pod tym względem i najciekawiej to budują ze wszystkich. Jedna rzecz: mało to opensourcują w porównaniu do innych dostawców.
SW: Tak, też to zauważyłem. To znaczy, ogólnie jeżeli chodzi o ogłoszenia, to też wrażenie jest takie… Jeżeli chodzi o Compute’a, dużo działo się w AWS-ie. Dużo było ogłoszeń w kontekście HPC, czyli bardzo masywnych ogłoszeń, obliczeń, dużo wokół ML-a i dużo wokół procesowania danych złożonych, tak powiem: masywnych zbiorów danych. To tak ciekawe, bo to się bardzo ładnie łączy z tym, co Ty mówiłeś odnośnie ML-a. No bo ML będzie wymagał dużych możliwości obliczeniowych. A ogólnie poza tymi właśnie obliczeniami złożonymi to w Compucie bardzo mało było ogłoszeń tak naprawdę. Nie zadziało się za wiele ciekawych rzeczy.
ŁK: Dobra. To ja sobie biorę następny link. Supply Chain Optimization. I AWS Supply Chain, co Amazon zrobił. To jest akurat ciekawostka bardziej biznesowa, czyli wygląda na to, że zabawki, które… i wiedza której nauczyli się u siebie przy zarządzaniu łańcuchem dostaw. Nie atakami Supply Chain, tylko właśnie zarządzaniem łańcuchem dostaw fizycznej logistyki, poszło tak naprawdę w gotową usługę ML-ową, która ma pomóc zarządzać stockiem w firmach, które tego potrzebują. AWS co jakiś czas pokazuje serwisy, które z założenia implementują też ich wiedzę.
SW: No bo tam w wiedzy jest wartość ich, tak naprawdę. Ale to jest ciekawe, bo rozmawialiśmy swojego czasu o tym właśnie, że obecnie będzie większy nacisk na cały Supply Chain, czyli łańcuch dostawy, ładnie mówiąc sobie. To ja wrócę do tematu, który poruszaliśmy z początku roku. Pamiętasz, jak mówiliśmy o Open Cybersecurity Schema Framework?
ŁK: Tak.
SW: Przy tym standardzie wokół zbierania danych, jeżeli chodzi właśnie o bezpieczeństwo. No to właśnie są Amazon Security Lake. I on korzystając z tego frameworka jest w stanie zbierać dane z on-prema, clouda i jeszcze dowolnych innych systemów. I to w jednym miejscu scentralizować. Czyli mieliśmy niezłego nosa, bo właśnie się usługi ładnie pokazały. Zresztą Amazon był jednym z kontrybutorów.
ŁK: Tak, dokładnie, więc nie dziwi mnie to. Ciekawi mnie jedno, jak poradzą sobie z… Jest jedna rzecz, bo…Oni są troszczeczkę zamknięci w swoim świecie w przeciwieństwie do producentów CM’ów czy Microsofcie, który z on-premem żyje od dawien dawna i mnogością rozwiązań i problemów, które tam żyje i sygnałów stamtąd. Więc jedno to jest fajne, że poużywają tego frameworka. Pytanie, które mam tak naprawdę, w jaki sposób…
SW: Szersza adopcja.
ŁK: Szersza adopcja będzie ściąganie tego, bo mają trochę rzeczy tak naprawdę. Mają tylko kilka produktów, tutaj widzę, przy czym znaczących na liście tych integracji sieciowych, więc ciekawe będzie, jak jedno to będzie z tą całą integracją docelowo wyglądało. Czy to będzie CM, czy nie.
SW: Nie [niezrozumiałe] generalnie. Jeżeli to będzie tylko w ramach ich produktów i paru rzeczy na on-premie to to nie chwyci. Żeby to działało poprawnie, musi faktycznie zbierać ze znaczącej większości narzędzi te metryki i dane. Pytanie teraz: komu na tym będzie zależało? Czy to nie będzie powtórka tego, co mamy obecnie w PEZ2, że w sumie każdy musi mieć, ale to mało w którym banku w ogóle działa.
ŁK: Wiesz co, tak, bo jak sobie jeszcze popatrzę w Azure’owym w Microsoftowym Sentinelu, to tych konektorów jest o wiele więcej.
SW: Tak, tak, tak.
ŁK: Więc jest pytanie. I druga sprawa: ile to na koniec dnia realnie, bo to jest też ciekawe z tymi zabawkami, ile na koniec dnia, jak to realnie będzie kosztowało przy wykorzystaniu. Nie mówię o cenniku i innych rzeczach, bo one na początku wyglądają zawsze przyjemnie. Pytanie: jak to będzie wyglądało na koniec dnia.
SW: Tak, ja bym się z tym zgodził. Jeszcze jedna rzecz. Jeden nurt, który bardzo mocno wyłapałem, nie wiem, czy to zauważyłeś. Bardzo dużo ogłoszeń było, że do którychś usług dochodzą opcje server lessowe. Albo w dodatkowych opcjach w usługach server lessowych. M.in. z rzeczy ciekawych jest właśnie Open Search Server less, czyli wyszukiwanie pełnotekstowe à la Elasticowe, czyli takie faktycznie niezłe. Wiadomo, że w starszej wersji Elastica, na Server lessie. I to jest o tyle ciekawe, że ciężko jest zrobić full-text searchowe wyszukiwanie Server lessowe. Ale to jest mała rzecz, która cieszy. Ale mam też wrażenie takie, że mocno idzie przygotowanie pod to, pod optymalizację kosztów, tak naprawdę. Mamy Server lessowe, mamy tam też sporo usług dostało Elastic Scale’a. Też żeby optymalizować koszty tak naprawdę. I jeszcze było ogłoszenie odnośnie właśnie cen i ogłoszenie właśnie wokół managementu i zarządzania cenami tak naprawdę i kosztami. Więc wydaje mi się, że AWS też się mocno przygotowuje na to, co się dzieje w ekonomii tak naprawdę. Żeby jak zacisnąć pasa, żeby to miało sens i żeby klienci nie uciekli.
ŁK: Wiesz co, właśnie, żeby klienci nie uciekli. Dobrze, że to powiedziałeś. Jedno to jest danie im tej możliwości. Druga rzecz, żeby ich mocno do siebie przywiązać.
SW: Tak, ale to robi każdy dostawca chmury.
ŁK: Tak, ja mówię, tak. Tylko to jest w dość ciekawej formie podawane. Jedna rzecz do tego Server less, bo tak jak były narzekania na nową wersję Aurory w wersji Server less, że ona Server lessem nie jest. To jestem ciekaw, jak tutaj cennik z tym Open Search Server lessem się na koniec dnia spina. Ja sobie… czekaj, jedną rzecz tylko zerknę.
SW: Cennik cennikiem. Jestem ciekawy tej pierwszej inicjalizacji, bo widać fajnie na przykład po AWS Lambda Snapstart Accelerate, czyli optymalizacja inicjalnego czasu startu rzeczy Server lessowych, głownie java’owych i takich języków kompilowanych, gdzie masz DAI-a i inicjalizację całą aplikacji. No nie? I to z reguły zajmuje dużo czasu. I to właśnie zoptymalizowali. Więc ewidentnie jest parcie wokół tego, co… na czym rozmawialiśmy przed startem, że Server less wyszedł z takiej fazy, że to są zabawki. To jest promowane, żeby było faktycznie realne narzędzie do użycia. Po czemu? To też optymalizuje dwie rzeczy. Optymalizuje koszty AWS-a i optymalizuje też koszty jeżeli chodzi o klientów. To jest narzędzie, które jest potrzebne, żeby była dobra utylizacja maszyn tak naprawdę. Więc…
ŁK: Dobra. To ja mam wpis od Macieja Radzikowskiego.
SW: mhm
ŁK: I on na Server less Polska też tam popełnił swoje tam 12 TOP-ów z całości. Jedną z rzeczy to właśnie, że ten Server less niestety w niektórych miejscach jest używany pod tytułem…
SW: Jako taki wabik.
ŁK: [niezrozumiałe] i tak… I dobrze przeczułem, że ten Server less może być w Open Search taki jak w Aurorze. No, okazuje się, że ten Server less przy minimalnym stanie to jest nadal 700 dolców miesięcznie. Więc raczej to jest dla ludzi, którzy potrzebują pick-ów i mają je niż jako stały word load.
SW: Znaczy, dla mnie to jest bardziej to, że to się pojawia w Preview, więc nie oczekujemy, że to będzie działało super. Ale to jest kierunek, którym się ewidentnie AWS zaczął bardzo mocno rozwijać. A pamiętajmy, że oni wychodzili z tego, że jeżeli coś chcesz, to sobie postaw VM-kę. Czyli jest takie przesunięcie kompletnie modelu myślowego, i to jest fajne bardzo.
ŁK: Tak, to pod tym względem tak. Dobra. To idąc sobie w kierunku Server lessu, to dwie rzeczy, które mi się tutaj rzuciły. Po pierwsze, tak naprawdę to, co jest, to Step Functions Distributed Map, czyli przetwarzanie na Step Functions dużych zbiorów danych z S3. I ogólnie procesowania tego, budowania pipeline’ów, więc to jest ciekawa tak naprawdę jeszcze limit współbieżności bodajże do 3000 uruchomień lambd, tam inne takie zabawki. Więc, mimo że są usługi ETL-owe, to ten model wykorzystania Server lessu i tych usług bardziej kodowych do budowy całych tych pipeline’ów widać, że na rynku chwycił, jeżeli chodzi o AWS-owy Cloud. I że jest to bardzo intensywnie wykorzystywane i wspomagają w tym klientów.
SW: Znaczy, w ogóle [niezrozumiałe] inicjalne wykorzystania właśnie lambd, tylko właśnie bardzo mocno wokół właśnie procesowania równoległego i niektórzy szaleńcy też tam puszczali ML-a na tym.
ŁK: Robiłem, ten… ETL-a nawet na tym w 2017 roku dla testów i wiem, że potem ludzie mocno z tego korzystali. A, przepraszam. Równolegle to do 10 000 wykonań równolegle w takim Step Functions Map. Więc to jest przy takim własnym Map Previous i innych tego typu elementach, jest to już naprawdę, naprawdę sporo.
SW: Znaczy to nie będzie limitem dla bardzo znaczącej grupy uruchomień.
ŁK: Dokładnie. Chyba że ktoś pójdzie w pickoserisowanie tego, zabawy i procesowanie. Dobra. I kolejną rzeczą, która jest przy tym, to Event Bridge Pipes. I w skrócie, bo Step Functions dostało w AWS-ie ciekawą funkcjonalność jakiś czas temu. Czyli że możemy bezpośrednio ze Stef Functions wywoływać sobie i przekazywać Payloady do…, natywnie do usług bez wołania lambdy, czyli nie trzeba odpalać lambdy, żeby wywołać jakąś prostą logikę z Api. I Event Bridge Pipes, i to jest ciekawe, bo z jednej strony upraszcza, a z drugiej utrudnia zarządzanie, tak na pierwszy rzut oka, jak na to patrzę, ale pozwala zastosować sobie wzorzec Pipe’u, czyli przesyłania danych punkt-punkt pomiędzy usługami z filtrowaniem i rozszerzaniem pól, jeżeli przerabianiem z wykorzystaniem Step Functions i lambd, jeżeli potrzebujemy je wzbogacić o coś. Więc to jest ciekawostka, że nie potrzebujemy lambdy powoli w AWS-ie jako kleju, jeżeli chodzi o dane. Że lambda zaczyna być, tak jak kiedyś była, tak jak powiedziałeś, budowane ETL-e i inne rzeczy, ML-e. Że przestaje być tylko już warstwą transportową, tylko tak naprawdę przetwarzającą dane. W całości. A usługi wokół załatwiają całą logikę i transport.
SW: No, dojrzewa. Lambda w AWS-ie ma już sporo latek, więc jak najbardziej to się będzie zmieniało. Zdecydowanie AWS, jeżeli chodzi o właśnie ten Server lessowy, tę lambdę, no to bardzo mocno zaczął ładnie i jest trochę do przodu względem reszty chmur.
ŁK: Tak, pod tym względem tak.
SW: Ze wszystkim. Ty jesteś dużym fanem Step Functions, ja uważam znowu że Durable Azurowe są dużo lepsze.
ŁK: Znaczy Durable.. to są różne modele. Zupełnie dwa, zupełnie inne… Inaczej: brakuje odpowiednika Step Functions w Azurze, takiego, żeby zrobić to bez kodu. Bo zobacz, że Step Functions teraz ten Event Bridge Pipes, jak sobie porównamy teraz Azure’a z AWS-em, Azur bez kodowania nie pozwala się tak ładnie spinać po API jak klocki Lego, jak AWS.
SW: Zgadza się. Jednak to właśnie, że to jest w kodzie, ma swoje plusy, że jest dużo bardziej dynamiczne. Ja to właśnie sobie bardzo mocno cenię. Że nie mamy tego właśnie klockowego, nie mamy tego. To może być zależne od kodu i nie jest to tak statyczne, jak w AWS-ie. W Azure możemy zrobić wszystko potencjalnie. To jest po prostu obudówka na…
ŁK: Tutaj też możesz to zrobić, ale patrząc się do wielu sheetupsów i wielu integracji jest to ciekawy, ciekawy kierunek. Podsumowując tego Server lessa, to Paweł Zubkiewicz z Serverless Polska fajnie też podkreślił, że AWS lambda is not a glue any more, use lambda to transform, not the transport data.
SW: No, dobre podsumowanie. Dobrze.
ŁK: Dobra, teraz ty
SW: Ja jeszcze mam jedną rzecz. Ja jeszcze wrócę do jednej rzeczy, która w sumie była najpierw takim smutkiem, że nie ogarnęliśmy tego. A drugie mocno, że w sumie nie wiem, czy jest do końca wartość do ogarniania tego. Mianowice: dla CloudWatcha usługa, która… Dla tego właśnie do CloudWatcha, która jest w stanie wyłapywać dane wrażliwe z logów i je maskować.
ŁK: Wiesz co… (śmiech)
SW: Ja mam o tym bardzo mieszane uczucia generalnie, bo to jest potrzebne.
ŁK: Raczej, inaczej: tak, jest to potrzebne, tylko, że RODO zostało już zgwałcone. (śmiech)
SW: Tak, dokładnie, i to mnie właśnie zasmuciło, że nie ogarnęliśmy tego kompletnie jako dziedzinę, jako w ogóle IT, więc mamy taką zaklejkę w postaci maskowania itd. To jest o tyle smutne, że za chwilę będzie opcja taka, że no super, fajnie, ale ktoś będzie musiał te dane zobaczyć w jakiejś sytuacji, bo to są logi de facto.
ŁK: Tak, i w ogóle zamiast ID-ków, uwielbiam, że zamiast ID-ków latają dane po prostu na bezczela, żeby było łatwiej.
SW: Bo Ty jeszcze mówisz o mailach, no maile to jest najmniejszy smutek.
ŁK: Wiesz, ja wiem, ale tak, tutaj jest mail w przykładzie, dlatego maile. Ale dane osobowe: lata sobie potem PESEL, dowód osobisty, kwoty czy inne bardziej, bardziej wrażliwe dane.
SW: Że one latają, to jeszcze latają, ale pamiętajmy, że te logi są czasem odkładane na wiele lat. Czasami 5, czasami 10 lat logi. I leżą na backetach.
ŁK: Słuchaj: znam pewną organizację, kiedy z pierwszej wersji serwisu z 2001 roku logi nadal gdzieś walają się na taśmach.
SW: Ależ oczywiście, że tak jest. I tak to będzie wyglądało, bo mało kto podejmie decyzję, że: a to usuńmy te logi, bo już się nie przydadzą, albo usuńmy cokolwiek. No z całym szacunkiem. Nie wydarzy się. Usługa fajna.
ŁK: Ciekawa, o!
SW: Potrzebna.
ŁK: Potrzebna. O! To jest lepsze. Znalazłem dane, omaskujmy je. Dobra. Ostania rzecz: Code Catalyst, czyli AWS dorabia się swojego internalowego Azure Devopsa dla klientów.
SW: mhm.
ŁK: Skierowanego… Tylko że skierowanego bezpośrednio na AWS-a. Nie oszukujmy się, to ma żyć tylko w tamtym świecie, patrząc się na całość, więc dostajemy na start, bo jest to preview, jedną rzecz, która jest fajna, dostajemy coś, co się nazywają blue printy, czyli już odpowiednik zeskafoldowanego projektu razem z CI/CD `i innymi zabawkami. I to jest ciekawa rzecz w całości, czyli to, co mamy w Azure Dev OPS-ie, tylko Start Project być może w wersji dostosowanej do AWS-a.
SW: Tak, faktycznie, AWS miał dziurę w porównaniu do Azure’a, jeżeli o to chodzi. I ciężej było zebrać klientów, żeby byli blisko.
ŁK: Tak. To jest to. Następną rzecz, którą jest, to mają ten swój edytor cloudowy, więc tutaj są też dev environmenty wbudowane w całą tą zabawkę, żeby sobie zdefiniować środowisko, w jaki sposób ma działać. Co jeszcze było ciekawego oprócz tego? Tak, to właśnie ich edytor, ten Cloud Nine do edycji, repozytoria no i buildy i release’y wbudowane do ECS-a, lambdy, EC2 i co jest w tym ciekawe, że buildy i release’y. Zostało to ładnie rozdzielone nawet w nazwie, że to jest faktycznie CI i CD, a nie CI przerobione na CI/CD. To jest przyjemne. No i ostatnie, oczywiście, że jest tam Project Collaboration, jako że jest to pełne narzędzie.
SW: No bo Azure Devops jest supernarzędziem dla organizacji do wejścia, tak naprawdę, w chmurę. Do zarządzania i do wszystkiego. Ma swoje plusy, ma swoje minusy chyba jak każde z tych tooli. Ale jako taki wytrych, żeby wejść do organizacji i żeby organizację przywiązać to jest superopcja tak naprawdę.
ŁK: I ma jedną rzecz: jest jednym z najtańszych rozwiązań na rynku, z całą ilością ficzerów.
SW: Tak. Bo ta ilość ficzerów i też ficzerów, które są mocno nastawione na korporacje i duże organizacje. Bo to można zrobić.
ŁK: Przy czym i mimo nazwy nie zamyka się tylko w Azurze, to jest też ważne.
SW: Tak, to jest dobre narzędzie w ogóle do managmentu. Dobrze, Łukaszu, podsumujmy jakieś takie wrażenia, które nam się przebiły. Ja mam trzy. Dużo się zadziało pod HPC i pod właśnie takie masywne obliczenia – pierwsze. Dużo reakcji, jeżeli chodzi o to, co się dzieje wokół nas w ekonomii, czyli w optymalizacji kosztów właśnie – Elastic Scale i Server less. I moje ostatnie trzecie wrażenie, bo to może nie wybrzmiało z tego, co mówiliśmy: a gdzie jest K8S? Bo nie było żadnego poważnego ogłoszenia, znaczy było jedno odnośnie deploymentów, odnośnie właśnie K8S-a.
ŁK: Wiesz co, ja ma swoje zdanie na ten temat. Pod względem K8S-a oni są z trójki dostawców na trzecim miejscu. Z trzech dostawców Hiperscale’u oni są na trzecim miejscu, więc mnie to trochę nie dziwi. I śmiejąc się, że zanim im się uda nadgonić release’owane wersje, to trochę czasu minie. Patrząc się, sesji było sporo na temat w ogóle EKS-a i innych rzeczy wokół, ale to nie jest technologia. Zobacz, że Microsoft skupił się u siebie na Ignite’ie, patrząc się, co było niedawno. To skupił się na zarządzaniu flotą, w on-premie, tym EKS-em i innymi rzeczami.
SW: Tak.
ŁK: AWS ma też podobne rzeczy, o tak. Ma też podobne. Ma te swoje Open Distro dla EKS-a, więc to różnie sobie na tej całości wygląda.
SW: Tak, zgadza się jak najbardziej. Tylko właśnie, nie oszukujmy się, że te wszystkie konferencje, to jest też opcja na robienie PR-u i szumu wokół pewnych rzeczy, żeby C level itd. ludzie usłyszeli o pewnych rzeczach. I to że nie było tego szumu, to mnie bardziej zadziwiło de facto.
ŁK: Nie. Wiesz co, bo to jest już tak, jak mówiliśmy, że chmura to jest new normal, to K8S jest new normal w firmach. Mimo że brakuje kompetencji etc.
SW: Dobrze, jakie Ty masz podsumowania?
ŁK: Ja, wiesz co, jedno: nie ma efektów WOW, jak popatrzymy poza pierdołkami i chmura tak samo w Azure Google wchodzą w fazę polerowania.
SW: To już jest coś, co istnieje, znamy już długo i tam już fajerwerków nie będzie.
ŁK: Raczej, pytanie, jak quantum computing zacznie działać, być dostarczany ASE Service. Zobaczymy, jak wtedy pociągnie.
SW: Bardzo wąska grupa zastosowań de facto, i to będzie…
ŁK: Nie, ja bardziej mówię, dla mnie quantum computing realnie to są lata 60. Teraz odpowiednika tego, co znamy z informatyki, dlatego jestem ciekaw, co będzie w tych szybszych cyklach, za kilka cykli, jak to się, w którą stronę to się pociągnie.
SW: Według mnie w ramach bardzo wąskiej specjalizacji i wąskich zastosowań.
ŁK: Dobra, to zobaczymy.
SW: No to, co? Słyszymy się kolejny raz 13 stycznia.
ŁK: Dokładnie.
SW: Trzymajcie się. Hej.
ŁK: Trzymajcie się. Na razie. Hej.