Cloud – niejedno ma oblicze

Cloud First

Zacznijmy od Cloud First – czyli pojęcia, które swego rodzaju „pierwszeństwo” ma zawarte już w swojej nazwie. Założeniami przyświecającymi do wyboru właśnie tej strategii budowy rozwiązań powinny być okoliczności w obszarze bieżącego ekosystemu rozwiązań w organizacji, dla których migracja aktualnego portfela aplikacji jest trudna (technicznie, biznesowo), gdzie zależności pomiędzy systemami nie pozwalają na wydzielenie wysp do migracji, metoda lift&shift nie jest możliwa lub opłacalna, a re-architektura systemów zbyt trudna np. ze względu na dojrzałość techniczną i kompetencyjną zespołu. Nazywając rzeczy po imieniu – Cloud First rozważamy, gdy migracja bieżących systemów do chmury nie jest (na ten moment) uzasadniona lub możliwa.

Czym więc jest strategia Cloud First? Według niej, chmura będzie pierwszym wyborem dla każdego planowanego rozwiązania – nie tylko dla nowych systemów, ale przede wszystkim w obszarze rozbudowy nowych systemów o zupełnie nowe moduły. Czy to oznacza, że każdy nowy system na pewno powstanie w chmurze? Oczywiście nie, jednak to chmura będzie rozważana w pierwszej kolejności.

Na co zwrócić szczególną uwagę? Nowe rozwiązania powinny być dostosowywane do architektury chmurowej – nawet, jeśli od razu nie są uruchamiane w chmurze. Co więcej – Cloud First powinien zakładać moment przebudowy aktualnych systemów do nowej architektury. Czyli w tym samym czasie powinniśmy również przeprowadzać proces stopniowej przebudowy architektury korporacyjnej firmy, aby była gotowa na rozwiązania chmurowe. Czyli nie skupiamy się jedynie na nowych rozwiązaniach, które są lub będą gotowe na działanie w chmurze, lecz równolegle przygotowujemy siebie i organizację na głębszą adopcję chmury. Tylko przy takim założeniu strategia Cloud First przyniesie spodziewane korzyści.

Hybrid Cloud

Podejście hybrydowe jest na fali – nie tylko w IT, lecz także w motoryzacji. A jak sama nazwa wskazuje spodziewamy się po niej pewnego rodzaju połączenia i stworzenia tym samym efektu synergii – w tym przypadku jednoczesnego wykorzystywania zalet obu światów: on-premises i chmury. Nasza „hybryda” zakłada bowiem trwałe i długotrwałe połączenie dotychczasowego sposobu dostarczania zasobów oraz usług IT z zupełnie nowymi możliwościami, które w tym zakresie oferuje cloud computing. Warto nadmienić, że hybrid cloud to naturalny kierunek dla większości dużych i średnich przedsiębiorstw, dla których migracja do chmury to proces długofalowy, a dodatkowo utrudniony faktem, iż wybrane systemy mogą pozostać on-premises już na zawsze np. ze względu na regulacje czy też inne aspekty technologiczne.

Na co zwrócić szczególną uwagę? Hybryda to naturalny stan działania na wiele lat. Warto więc zadbać o dobre i praktyczne standardy. Naszym naturalnym kierunkiem powinno być dążenie do standaryzacji pomiędzy środowiskami np. w zakresie tożsamości, sieci, monitoringu, deploymentu czy też zarządzania bezpieczeństwem. Z biegiem czasu hybryda powinna również coraz bardziej zacierać granice pomiędzy środowiskami (on-prem i cloud), właśnie wtedy poczujemy największe korzyści z wdrożenia tej strategii. Naszym celem nie jest bowiem utrzymywanie niezależnych „dwóch królestw”, które wymagają dodatkowego nakładu pracy, aby je kontrolować i zarządzać nimi w odpowiedni sposób. Oczywiście – nie wszystko będziemy w stanie zunifikować. Jednak należy dobierać takie narzędzia i standardy, które umawiają uproszczenie i ujednolicenie wielu różnych procesów np. Azure ARC, Google Anthos, Flexera, SNOW.

Multi-Cloud

Czym jest podejście multi-cloud i kiedy warto je rozważyć? Aby uspójnić pojęcia przyjmiemy najprostszą definicję multi-cloud, czyli wykorzystania minimum 2 chmur publicznych jednocześnie, do budowy środowisk lub rozwiązań IT. Ale dlaczego mielibyśmy iść właśnie w tę „wielochmurową” stronę? Przecież wszystkie wiodące rozwiązania cloud computing są bogate w usługi i jednocześnie do siebie „podobne”. Poniżej kilka ważniejszych punktów, który przemawiają na korzyść podejścia multi-cloud:

• Chcemy dobierać rozwiązania i rozwiązywać problemy w najbardziej optymalny dla nas sposób, np. wydzielając workload’y do różnych chmur. Przykład? Tematy infrastrukturalne trafiają do obsługi w AWS, obszar Modern Workspace adresowany jest w Microsoft 365, a analityka danych realizowana w GCP.
• Chcemy dobierać usługę chmurową w najlepszy możliwy sposób. Tym samym wkraczamy na grząski grunt dostarczania jednego systemu z dwóch chmur. Ale znamy i takie wdrożenia, np. w obszarze infrastruktury opartej na AWS, która wspierana jest chmurą Microsoft Azure w obszarze bezpieczeństwa i zarządzania tożsamością. 
• Ucieczka od vendor-lock, czyli od możliwości uzależnienia się od jednego dostawcy. A tym samym ograniczenie ryzyk związanych ze wzrostem cen, czy też wywieranie swego rodzaju „presji” na dostawcach.
• Optymalizacja kosztów - pieniądze to zawsze ważny punkt na agendzie. Różnorodność technologiczna czy optymalny dobór usług są istotne, jednak optymalizacje budżetowe są mile widziane
• Więcej chmur to również większy wybór i elastyczność w budowie zespołów, których dostępność wciąż jest ograniczona. To bardzo praktyczne i pragmatyczne podejście wynikające ze skupienia się przede wszystkim na podniesieniu możliwości realizacji zadań, w oderwaniu od technologii, która ma temu służyć.

Na co zwrócić szczególną uwagę? Podejście multi-cloud wymaga dużo więcej przygotowań niż w przypadku jednego dostawcy chmurowego i może powodować dodatkowe komplikacje (złożoność) w architekturze rozwiązań. Podobnie jak w przypadku podejścia hybrydowego powinniśmy dążyć do precyzyjnego określenie technicznych, procesowych i biznesowych „reguł gry”, które będą pozwalały dostarczać bezpieczne usługi chmurowe i kontrolować wszystkie procesy związane z ich wykorzystaniem. Mówimy więc o stworzeniu wielochmurowego „Landing Zone”, która często rozwijana jest do kompleksowego Cloud Governance. Wykorzystywanie więcej niż jednej chmury wymaga także położenia dużego nacisku na odpowiednie przygotowanie kadry i zespołów IT – transfer odpowiednich kompetencji oraz pozyskanie cennych doświadczeń wymagają nie tylko czasu, ale również środków finansowych. Oczywiście rynek oferuje wiele rozwiązań i narzędzi, którymi możemy sobie pomagać przy wdrożeniach multi-cloud, jednak sukces w implementacji tej strategii nie tkwi jedynie w jej technicznej realizacji, lecz przede wszystkim w określeniu założeń i celów, które mają takiemu podejściu przyświecać.

Cloud Native

I w tym momencie dochodzimy do bardzo pojemnego pojęcia, które wiedzie ostatnio prym podczas konferencji czy grup dyskusyjnych o tematyce chmurowej. A ja bardzo często podkreślam, iż na 10 osób zapytanych o definicję podejścia Cloud Native, każda z nich udzieli odmiennej (czasem nawet znacząco) odpowiedzi, w tym „Cloud Native to Kubernetes”. A prawdziwe korzenie Cloud Native nie tkwią jednak w samej „przenaszalności” aplikacji pomiędzy chmurami (w tym tą prywatną), ale w potrzebie szybkości i elastyczności prowadzącej nas w stronę architektury mikro-usług.

W stronę Cloud Native skierujmy naszą uwagę przede wszystkim, gdy:

• Skalowanie niezależnych modułów aplikacji jest istotne;
• Wydania modułów muszą odbywać się często, np. co kilka dni, niezależnie od innych elementów systemu;
• Rozwój aplikacji w architekturze monolitycznej nie jest dalej możliwy, zespoły potrzebują większej elastyczności;
• Duża przenaszalność rozwiązania pomiędzy dostawcami chmury oraz rozwiązaniami on-premises jest kluczowa.

Wzorcowe podejście Cloud Native opiera się na wykorzystywaniu 12 pryncypiów architektury zwanych „Twelve-Factor App” (lub „12 factor app”). Pryncypia te odnoszą się do wielu aspektów budowy rozwiązań i ukierunkowują nasze podejście na odmienną niż do tej pory metodologię tworzenia aplikacji – niezależnie od tego, czy od początku będzie już działać w chmurze publicznej. Zainteresowane osoby odsyłam do bogatej bazy informacji na temat „12 factor app” dostępnej w Internecie. Ten jedyny akapit o podejściu Cloud Natvie nie jest w stanie odnieść się do każdego z tych pryncypiów nawet w formie skróconej.

Na co zwrócić szczególną uwagę przy podejściu Cloud Native?

• Dostosowanie aplikacji do modelu Cloud Native jest trudne i kosztowne, wymaga bowiem wykorzystania innych paradygmatów, które dogłębnie ingerują w nasze rozwiązania.
• Nie wszystkie aplikacje powinny być tworzone w ten sposób – zanim podejmiemy ten wysiłek oceńmy jego zasadność i osiągane korzyści.
• W znakomitej większości modele prostsze niż Cloud Native są wystarczające dobre, aby osiągnąć zamierzony cel techniczny lub biznesowy.
• Cloud Native wykorzystany w niewłaściwy sposób potrafi generować więcej szkód, kosztów oraz ryzyk, niż system monolityczny.

Reasumując - Cloud Native nie kończy się na konteneryzacji aplikacji i uruchomieniu jej na klastrze Kubernetes. Przygotowując plan migracji lub też decydując o strategiach chmurowych warto zbudować model dojrzałości naszych aplikacji w kontekście Cloud Native, który może opierać się na poniższych kategoriach:

1. Cloud Tolerant – aplikacje dostosowane do działania w środowisku chmury;
2. Cloud Ready – aplikacje spełniające chmurowe pryncypia projektowania systemów;
3. Cloud Optimized – aplikacja w modelu usługowym, monolityczna baza danych;
4. Cloud Native – architekura aplikacji w pełni oparta o mikro-usługi.

Z naszego doświadczenia – dla znakomitej większości aplikacji dostosowanie ich do poziomu Cloud Ready i Cloud Tolerant będzie zupełnie wystarczające, ale również i tańsze. Zwykle niewielka ilość systemów zalecana jest do przebudowy do dojrzałego modelu Cloud Native, ale nie jest to zła wiadomość – ten proces jest złożony i kosztowny, więc ta decyzja powinna zostać przeanalizowana bardzo dokładnie.

No właśnie czy istnieje jedno podejście, aby wdrożyć chmurę publiczną?

Na postawione pytanie czy istnieje wyłącznie jedna strategia bądź podejście, które wręcz modelowo (a nawet „na wyłączność”) wpisze się w potrzeby organizacji wdrażającej chmurę publiczną? Odpowiedź brzmi zdecydowanie „nie” – wszystkie wymienione strategie powinny być poddane analizie i szczegółowej dyskusji w organizacjach decydujących o modelu adopcji cloud computing lub będące w jej trakcie. Co więcej, niektóre podejścia należy wręcz łączyć i czerpać korzyści z najlepiej dopasowanego, własnego wzorca działań np. Hybrid-Cloud z uwzględnieniem Multi-Cloud z elementami Cloud-Native dla wybranych systemów. W jaki sposób powinniśmy o tym zdecydować? Pomagają w tym sprawdzone praktyki oraz procesy doradcze, które w znaczący sposób uproszczają wypracowanie najlepszego planu działań dotykającego całego spektrum zagadnień takich jak aspekty techniczne, organizacyjne, procesowe, biznesowe czy też ludzkie. Ale ten aspekt to temat na całkiem oddzielny artykuł, a nawet serię publikacji.