#23 Mądrość i chytrość w cloud native na przykładzie AWS

To budujesz własną cloud agnostyczną, jakiś middleware w środku, który można przenosić pomiędzy różnymi chmurami. Taka jest generalnie moja interpretacja tego. Jak ty byś to, Wojtek, zinterpretował? Jak byś do tego podszedł? Lepiej bym tego nie zinterpretował ze względu na to, że bardzo podoba mi się tłumaczenie cleverness na chytrość, bo to zdecydowanie oddaje duch tego obrazka. Ja powiedziałem na początku, że ja się nie do końca z nim zgadzam, ale nie zgadzam się z nim nie na płaszczyźnie merytorycznej opinii, bo to jest dla mnie opinia, tylko bardziej się nie zgadzam nad tym, że to jest taka konwencja żartobliwa przyjęta, Ja lubię porozmawiać o konkretnych, wspartych danymi wynikach.

I tutaj jest jakaś opinia przedstawiona z perspektywy tego, gdzie pracuję, jakie ja mam doświadczenia też w przeszłości, jeżeli chodzi o implementację systemów. Zdecydowanie się z tym zgadzam. Można się naprawdę przechytrzyć, budując własne rozwiązanie, które będzie sprowadzeniem do wspólnego mianownika tego, co oferuje wielu dostawców naraz. Skończy się to masą świetnie zrobionej, nikomu niepotrzebnej roboty bardzo często. Natomiast z drugiej strony ten brak wiedzy i mówienie, że możemy mieć własne data center, cały czas jesteśmy w tym on-premie, też mi pasuje do takiego początkowego stadium dojrzałości nazwijmy tego cloud native.

I wydaje mi się, że tutaj jest największy zawsze problem i nacisk warto położyć na tę motywację i na tę przyszłość tego konkretnego systemu. Natomiast wracając do tego, co powiedziałeś na samym początku, że Ciebie by głowa rozbolała przechodząc do serverlessu w tym momencie, jeżeli miałbyś się za to zabrać. To jest jeszcze jeden z takich argumentów bardzo często używanych za i przeciw jednocześnie, jeżeli chodzi o chmurę. To znaczy dostajemy masę możliwości i to jest jednocześnie zaleta i wada. I wydaje mi się, że to, co jest chyba największym wyzwaniem zawsze z perspektywy Rozwoju aplikacji w chmurze i przejścia tej ewolucji do tego cloud native, które mamy na obrazku wymienione, to tak naprawdę podejście do tego, w jaki sposób będzie cała organizacja przechodziła przez tą zmianę, jak będą kompetencje i jak będą przede wszystkim ludzie ewoluowali razem z tym tematem.

Natomiast to jest jedna z takich rzeczy, o których się często słyszy. Nie chciałbym tego zamienić w taką legendę miejską, bo to trochę wygląda jak straszenie yeti albo właśnie czymś, co nie istnieje. To znaczy nikt się nie chce przyznać do tego, że tak robią, a gdzieś te przykłady jednak mimo wszystko są. Wydaje mi się, że i dlatego jeszcze wracając do tego co powiedziałeś o tym rysunku, o tym czemu się może trochę z nim nie zgadzam. Podoba mi się Podobają mi się osie, podoba mi się kształt, natomiast mam wrażenie, że jest jeszcze jedna krzywa, której tutaj nie ma, bo to, że można przechytrzyć siebie implementując multi-cloud strategy na bazie wielu dostawców, to jest jedna z takich rzeczy, o których się mówi i się trąbi bardzo często i gęsto.

Zbudowaniu infrastructure as code, które nie istniało, ponieważ ten lift and shift został zrobiony. Odzyskanie backupu to było Infrastructure as a cloud. Wiesz co, jeszcze mam tutaj pytanie, bo dlaczego pytam o to, czy pomogło to, że ta aplikacja wraz z danymi znajdowała się w chmurze, bo przy środowiskach hybrydowych, z którymi najczęściej współpracuję, bo nasi klienci są akurat w tym stadium rozwoju, mamy ogromne data gravity po stronie on-prem. To znaczy te wszystkie data lake'i, wszystkie SQL, nazwij to jak chcesz, istnieje Tam. Dlatego, że tam zostało zbudowane i przez dziesiątki lat zbierane były tam dane. I teraz, jakkolwiek rozumiem ten news case, że to wszystko jesteś w stanie zapakować w wielką kulkę z kupy i położyć na C2 i tak czekać, aż się nie zawali, budując dookoła mikroserwisy, jest to drogą, którą wszyscy w zasadzie idą.

To znaczy organizacja musi się uczyć i wiadomo, że ona się uczy czasami skokowo, czasami regresywnie, czasami do przodu, czasami do tyłu, a gdzieś ona się uczy. Natomiast ten rysunek tego nie ma, natomiast on ładnie sumuje to wszystko, że najbardziej mądre i dość chytre, nie bardzo chytre, tylko dość chytre jest wybudowanie swojej aplikacji, oparcie swojej aplikacji o zaufane serwisy dostawcy, serwisy cloud native dostawcy. Ja myślę, że to jest klucz tej naszej dzisiejszej rozmowy, Wiem przez te 20 ostatnich lat, jak się projektuje systemy informatyczne, jak wiele energii i pieniądza trzeba poświęcić na przynajmniej dwie rzeczy.

Na jedną, czyli na zaprojektowanie i wykonanie, a na drugą na rozwój i utrzymanie infrastruktury. Jak przypomnę sobie te potworki kubernetesowe stawiane 3 czy 4 lata temu w on-premie, które musiały się zawalić. Wiadomo było, że jak powstaną, to będzie katastrofa. Bo się skończą ludzie albo pieniądze. No i tak się zazwyczaj działo. Parę mam przykładów, które ciągle jeszcze tam, wiesz, walczą chłopaki. Ale z drugiej strony mamy te Trusted Services, Trusted Cloud Native Services. I ty jesteś trochę orędownikiem tych serwisów, tak? Jakby rozumiem, bo to jest coś, co uważacie jakby w AWS, że jest może nie jedyną słuszną drogą, ale kontekstowo, w większości kontekstów się sprawdza. Tak, bo w większości kontekstów rdzeniem Twojego biznesu, tego jak funkcjonuje organizacja, na czym zarabia pieniądze, nie jest budowanie własnej infrastruktury i odsprzedawanie potem tej infrastruktury, chyba że mówimy tutaj o konkurencji, albo o kimś, kto faktycznie buduje tego typu rozwiązania i jest w segmencie technologicznym.

Natomiast to nam daje największą możliwość potem, jeżeli chodzi o optymalizację. Możliwość skorzystania z doświadczenia i z tego, co zostało zbudowane przez dostawców. To nam daje po prostu największą elastyczność na samym końcu i największe możliwości. Jeżeli nie jest naszym celem konkurowanie z takim dostawcą albo budowa właśnie jakiegoś rozwiązania technologicznego, które będzie w bardzo podobny sposób odsprzedawane, to wydaje mi się, że kontekstowo zaaplikowanie i skorzystanie z tych w pełni zarządzanych usług, rozumianych jako cloud native, jako fully managed services, jako serverless, jak zwał tak zwał, przyniesie największe korzyści. Ok, czyli jeżeli segmentujemy nasz problem,

Ja myślę, że właśnie siłą cloud native services, czyli rzeczy związanych z, już pomijam serverless, nawet z tym Kubernetesem nieszczęsnym, Jeżeli ktoś kiedykolwiek postawił siebie w infrastrukturze Kubernetesa, myślę, że będzie wiedział doskonale o czym ja mówię teraz, nie? I później będzie starał się go zaktualizować, utrzymać, dołączyć nowe funkcjonalności, wszystko co do istnieje. Versus to, że zapłaci za to więcej, oczywiście, że zapłaci więcej, ale wyautoryzuje od siebie ten Ten ciężar, może nie problem, to jest ciężar, bo on nie zawsze się objawia. Może 3 lata może działać infrastruktura świetnie i się nigdy ten ciężar nie objawi, ale jak się raz objawi, to się go do końca życia pamięta. I tutaj pytanie, czy to jest wystarczający poziom chytrości, mądrości?

Bardzo mi się podoba ten przykład firmy z gwoździami, bo to trochę by obrazowało taką sytuację, jeżeli firma, która produkuje gwoździe, Mam na myśli analogię między firmą, która próbuje budować własny cloud agnostic middleware albo tooling, to trochę odzwierciedla taką sytuację, jakby firma, która zajmuje się produkcją gwoździ, nagle zastanawiała się, jak przygotować własnej produkcji linię pod te gwoździe i będzie ją samemu implementowała, będzie samemu przygotowywała koła zębate, które tą linię zasilają itd. Ale to jest jeszcze pół biedy, wiesz, bo jeżeli jest jeszcze taki pomysł, to znaczy, że ktoś może chce to zmonetyzować na przykład robiąc firmę produkującą gwoździa za serwis.