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

Ja myślę, że tu jest ogromny strach, bo ludzie pamiętają czasy czerwonego producenta baz danych, w którym polegli licencyjnie przez to, że się zalokowali i to tak dość fundamentalnie było w kodzie. Mają opcję, albo przeniosą swoją VM-kę, gdzie mają napisany kod, czyli tak jak tutaj na tym rysunku mamy naryzowane, ani to mądre, ani to chytre, czyli lifted shift do chmury i robienie tego po staremu. No i podaj mi, jakbyś mógł, podaj mi przykłady takiego case'u, w którym się spotkałeś, czy to poszło dobrze, czy to poszło niedobrze, kiedy po prostu robisz, bierzesz starą aplikację, którą masz od setek lat,

Bo dzięki temu dostaniemy elastyczność, dostaniemy więcej rzeczy, z których będziemy mogli korzystać. Ale jeżeli to jest aplikacja, która latami działa na on-premie, tym przysłowiowym, I nagle okazuje się, że będzie działało następne naście lat bez perspektywy na jakikolwiek rozwój, to być może ten lift and shift wcale nie jest jedynym rozwiązaniem, bo jak większość ludzi, którzy zajmują się tematem migracji czy wdrożeń chmurowych, zdają sobie sprawę z istnienia takiego frameworku, który się nazywa 6R. Jednym z tych literek R, która się tam znajduje, jest retire, czyli Zostawienie tego systemu albo retain w zależności od tego, którą wersję weźmiemy.

Retain kojarzy się z utrzymaniem, retire kojarzy się ze śmiercią w pewnym momencie jednak, nie? Zgadza się. To zostawmy przy tym retain, zgadza się. Co nie zmienia faktu, że nie jest to rozwiązanie związane z przeniesieniem tego konkretnego workloadu. Ja jestem tutaj zwolennikiem tego pragmatycznego podejścia, bo widziałem wiele sytuacji, gdzie można było przenieść coś do chmury tylko dla faktu samego przeniesienia do chmury i zaskoczenie i ból związany z tym, że potem jest drożej, bo tak na dobrą sprawę Lift&Shift zrobiony W takim naprawdę klasycznym przeniesieniu 1 do 1. Będzie wychodził drożej, jeżeli przyjmiemy dokładnie te same kryteria, jakie przyjmujemy na on-premie, ale jeżeli myślimy o rozwoju, optymalizacji, późniejszej ewolucji tego systemu, to dostajemy dużo większe możliwości i dużo większą elastyczność, której po prostu nie mamy na on-premie.

Oczywiście znowu, to jest mega kontekstowe. Pomogło to, że była ta aplikacja już przeniesiona w AWS? Na pewno. Aczkolwiek wydaje mi się, że największy wysiłek, jaki był związany z tym konkretnym tematem, pomogło w tym kontekście, że nie trzeba było myśleć o migracji samej aplikacji monolitycznej 1 do 1, lift and shift do chmury. Bo to już poniekąd zostało zrobione, to już działało. To zdecydowanie ułatwiało sprawę, dlatego że można było się teraz skupić na powolnym wybieraniu tego, co najbardziej boli z tego monolitu, wyciąganiu tego na zewnątrz i wspólnie tak projektowaniu tej ewolucji architektury, Żeby pozbyć się tych najbardziej palących problemów związanych ze stabilnością, ze skalowalnością tego systemu, z wdrożeniem poprawnych i takich powtarzalnych potoków CICD, żeby to wszystko miało ręce i nogi, żeby mogło być utrzymywane w odpowiedni sposób.

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ą.