Czym są aplikacje wie chyba każdy. A jak jest z pojęciem Cloud Native? Być może każdy, no prawie każdy, coś słyszał i będzie miał swoje zdanie. Dobrze, to czym jest tak naprawdę Cloud Native Applications ( aplikacje natywne w chmurze / natywne aplikacje chmurowe) i samo podejście Cloud Native? Czy warto tworzyć nowe lub modernizować istniejące aplikacje do modelu Cloud Native, by usprawnić systemy i/lub przezwyciężyć dług technologiczny? W tym artykule postaram się odpowiedzieć na powyższe pytania oraz pokazać dlaczego podejście Cloud Native może być kluczowym elementem sukcesu transformacji cyfrowej każdej organizacji.
Zacznijmy od podstaw, czyli od rodzajów aplikacji
Zanim przejdę do Cloud Native i wdrażania aplikacji natywnych, zastanówmy się jakie mamy rodzaje aplikacji lub typy wdrożeń w chmurze. Na nasze potrzeby podzielmy je sobie na dwie kategorie:
1. Brownfield (modernizacja istniejącego systemu)
Brownfield to tworzenie, modyfikacja i wdrażanie oprogramowania w momencie, gdy istnieją starsze systemy, a my chcemy, bądź musimy, je rozwinąć lub ulepszyć.
Integracja nowej funkcji z istniejącym oprogramowaniem, czy dodanie nowego modułu do obecnego systemu lub aktualizacja kodu w celu zwiększenia funkcjonalności aplikacji, to procesy, które możemy wrzucić do worka z napisem brownfield.
Wyzwania przy tego typu modernizacjach:
- potrzebna jest duża wiedza na temat istniejących systemów, usług i danych, na których należy zbudować nowe rozwiązanie,
- przyda się dogłębna znajomość możliwości usług chmury publicznej,
- być może będziemy musieli przeprojektować dużą część istniejącego złożonego systemu, tak aby spełniało nowe wymagania biznesowe,
- powinniśmy precyzyjnie rozumieć ograniczenia IT oraz biznesu,
Dodatkowo, praca z istniejącym kodem może spowolnić proces programowania, więc także zwiększyć ogólne koszty rozwoju.
2. Greenfield (budowa aplikacji chmurowych od podstaw)
Tym razem tworzymy oprogramowanie od podstaw. Nie mamy ograniczeń istniejących systemów. Nie musimy korzystać z tego co już jest lub zmieniać przestarzałego kodu, czy też dopasowywać się do używanej dotychczas platformy chmurowej. Budowanie nowej strony internetowej lub aplikacji webowych od podstaw, konfigurowanie nowego środowiska do CI/CD (ang. continuous integration/continuous delivery), wdrażanie nowego silnika reguł, tworzenie nowego rozwiązania SaaS (ang. Software as a Service) to właśnie greenfield.
Czy będzie łatwiej? Może, ale nie musi. Także tu stoimy przed wyzwaniami, takimi jak:
- brak jasnego celu, co powoduje wzrost ryzyka,
- potrzeba zdefiniowania wszystkich potrzeb i aspektów, co może być czasochłonne,
- brak lub utrudnione uzyskanie decyzji w odpowiednim czasie u zainteresowanych i odpowiedzialnych osób,
- zbyt wiele opcji rozwoju oprogramowania i tworzenia skalowalnych aplikacji, nie zawsze wiadomo jakie podejście przyjąć.
Oba podejścia a aplikacje chmurowe
W pracy z chmurą publiczną i rozwojem oraz modernizacją aplikacji chmurowych mamy do czynienia z każdym z typów wdrożeń (brownfield, greenfield). W obu przypadkach możemy wykorzystać rozwiązania Cloud Native.
W przypadku, gdy tworzymy jakieś rozwiązania od zera (procesy tworzenia aplikacji od podstaw) możemy swobodnie wybrać model wdrożenia, zapewnić odpowiednią elastyczność aplikacji, skorzystać z dowolnych usług czy wybrać dowolne technologie chmurowe. W systemach, które modernizujemy, przy wdrożeniach w chmurze publicznej będziemy mieli do czynienia najczęściej z migracją do chmury lub z integracją rozwiązań chmurowych z on-premises.
Migracja może i najprawdopodobniej powinna być poprzedzona modernizacją aplikacji chmurowych.
Często da się zmigrować do chmury aplikację jeden do jednego, w tak zwanym modelu Lift and Shift. Będzie działała. Ale warto przyjrzeć się możliwościom modernizacji. Czasem drobne i niewiele kosztujące zmiany spowodują, że będzie ona pracowała w chmurze lepiej lub znacznie taniej. Pośród zrealizowanych przez nas projektów, mamy kilka, których celem była modernizacja aplikacji. W jednym przypadku praca trwała ok. 2 dni, a koszty chmury spadły o 94%.
Mam dla Was jedną radę. Przy obu typach systemów, przed wdrożeniem w chmurze, poproście o konsultacje kogoś, kto ma doświadczenie z chmurą publiczną, zna środowisko chmurowe. Jestem przekonany, że takie konsultacje zwrócą się z nawiązką nawet, jeżeli podejmiecie decyzję o rezygnacji z usług w chmurze.
Czym jest Cloud Native, architektura natywna oraz natywne technologie chmurowe?
Migrując się do chmury publicznej lub tworząc na wybranej platformie chmurowej rozwiązania od zera możemy po prostu skorzystać z maszyn wirtualnych lub klastrów. Możemy nawet udostępnić je bezpośrednio całemu światu. Zdecydowanie nie polecam takiego rozwiązania, ale jest to możliwe. Nie zostaną wtedy jednak wykorzystane zalety chmury publicznej (o których opowiadam szerzej na końcu artykułu) i środowiska chmurowego, oraz tego co możesz uzyskać dzięki skalowalności chmury.
Dochodzimy do sedna. Wykorzystajmy podejście Cloud Native.
Cloud Native
Jeśli chodzi o Cloud Native, istnieje nawet fundacja, która zajmuje się tym podejściem. Prowadzi m.in. inicjatywę CNCF Landscape, która w składa się już prawie z 200 różnych projektów. Znajdziemy tam chyba wszystko co potrzebne do szczęścia. Lub nieszczęścia. Czy jednak, jako osoba odpowiedzialna za projekt rozwiązania, musisz znać te wszystkie bazy danych, api, gatewaye, meshe lub rozwiązania do monitoringu i orkiestracji? Nie.
Definicja Cloud Native dostępna jest tu [link]. Są tam wymienione kontenery, mikroserwisy (mikrousługi), meshe, deklaratywne API, niezmienna infrastruktura. Dla mnie osobiście jest jeszcze ważna idempotentność rozwiązań.
Pewnie teraz zadajesz sobie pytanie: jakich usług mam użyć, aby otrzymać rozwiązania Cloud Native? Maszyn wirtualnych? Może kontenerów (eng. Containers)? A może Serverless? Tu tak naprawdę nie chodzi o wybór rozwiązań. Zarówno upór przy kontenerach jak i rozwiązaniach Serverless nie do końca ma sens.
Najważniejszy jest sposób, w jaki utworzymy systemy i aplikacje oraz to, jak będziemy nimi zarządzali, utrzymywali i rozwijali je.
Tworzenie skalowalnych aplikacji natywnych w chmurze
Są różne modele wdrożeń w chmurze publicznej. Natywne technologie chmurowe i podejście Cloud Native należą do tych najbardziej dojrzałych. I być może najbardziej wymagających. Nie zawsze architektura natywna w chmurze będzie najlepsza, jeżeli jednak chcemy w pełni wykorzystać potencjał, który dają nam chmury publiczne oraz aplikacje natywne dla chmury to dobrze jest mieć na uwadze następujące kwestie:
- automatyzacja infrastruktury, procesy tworzenia aplikacji jak i ich wdrożenie,
- wydajność,współbieżność, szybkość odpowiedzi,
- automatyczne skalowanie, czyli elastyczność aplikacji,
- odporność na błędy,
- diagnozowalność, czyli dostęp do metryk, logów, tracing,
- automatyczne deploymenty, czyli skrócenie czasu potrzebnego na wdrożenie nowych wersji,
- idempotentność.
Idempotentność rozwiązań jest bardzo ważna. Pamiętajcie, że projektujemy aplikacje natywne dla chmury z myślą o naprawie, a nie o błędach. Pamiętajcie o tym, że dana usługa może być restartowana wiele razy. Skalowanie horyzontalne powoduje, że ilość dostawców usługi będzie się zmniejszała i zwiększała. Zapytania mogą być ponawiane, a ich obsługa może być wykonywana przez różne instancje.
Powyższe cele możemy osiągnąć poprzez wykorzystanie zalet aplikacji natywnych.
Aplikacje chmurowe natywne – cel rozwoju
Najczęściej najważniejsza jest niezawodność, gdyż niezawodne usługi to zadowoleni klienci. I tutaj dochodzimy do Inżynierii niezawodności, czyli SRE (ang. Site Reliability Enginieering). Dobrze jest zadać sobie trzy pytania i na nie odpowiedzieć:
- Co to znaczy, że Twoja usługa jest dostępna?
- Na jakim poziomie mają być dostępne moje usługi?
- Co się stanie i co zrobię w przypadku awarii?
Na razie nic nie obiecujemy klientowi. SLA (ang. Service Level Agreement) to domena sprzedawców, nie inżynierów.
Jak do tego podejść? Jak to zdefiniować? Umożliwią nam to trzy wskaźniki:
- SLI (ang. Service Level Indicator) – to co akceptowalne jest dla nas. Mierzymy np. czy w ciągu ostatniej godziny 97,5% odpowiedzi trwało krócej niż 50ms.
- SLO (ang. Service Level Objective) – czy i w jakim okresie utrzymujemy cel zdefiniowany w SLI.
- SLA (ang. Service Level Agreement) – to jest to co obiecujemy i sprzedajemy naszemu klientowi. Określa procent dostępności usług dla klienta w konkretnej jednostce czasu.
I teraz coś ważnego. Zapytamy klienta czy potrzebuje 100% SLA? Odpowie prawie zawsze, że tak. A praktycznie zawsze odpowiedź brzmi: nie. Osiągnięcie 100% będzie bardzo trudne i bardzo drogie. Pamiętaj też, że swoje usługi w chmurze udostępniasz za pomocą sieci, a ta rzadko kiedy ma SLA wynoszące 100%.
Programowanie natywne, czyli w jaki sposób osiągnąć cel?
To konteneryzujemy czy nie? A może Serverless i konkretne usługi dostawców chmurowych? Na to pytanie nie ma jednej odpowiedzi. To zależy od kilku czynników, które mają na to wpływ. Zadaj sobie pytania:
- Czy mam gotową aplikację?
- Czy chcę, aby moją aplikację można było łatwo przenosić pomiędzy różnymi dostawcami chmury i on-premises?
- Czy chcę wykorzystać usługi i możliwości udostępniane przez dostawcę chmury publicznej w możliwie najlepszy sposób (np. dynamiczne skalowanie aplikacji)?
Odpowiadając na te pytania, ułatwimy sobie dobór odpowiednich komponentów aplikacji natywnych i zaprojektowanie architektury chmurowej.
Kontenery, czyli pierwszy krok na drodze do modernizacji i rozwoju aplikacji natywnych
1. Mam gotową aplikację w chmurze
Jeżeli na pierwsze pytanie z poprzedniego paragrafu odpowiedziałeś sobie tak, to zapewne warto pomyśleć o konteneryzacji. Nie obędzie się bez zmian w aplikacji, ale migracja będzie na pewno łatwiejsza niż w przypadku Serverless.
2. Chcę, żeby moją aplikację można było łatwo przenosić pomiędzy różnymi dostawcami chmury i on-premises
Odpowiedziałeś twierdząco na drugie pytanie? To zadaj sobie to pytanie ponownie, przemyśl to jeszcze raz. Nadal odpowiedź jest twierdząca? To jeszcze pomyśl czy naprawdę „przenoszalność” pomiędzy dostawcami jest warta poświęcenia na przykład szybkości dostarczenia rozwiązania na rynek. Twój konkurent może myśleć inaczej. Jeżeli nadal jesteś pewien swojego wyboru, ok, konteneryzuj aplikację.
Zdecydowałeś się na kontenery, masz już zmodernizowaną aplikację, pewne nie jesteś jedną z trzech osób na świecie, która nie słyszała o Kubernetesie. Kontenery, chmura – wiele osób od razu kojarzy te technologie właśnie z Kubernetesem. Jednak rzadko jest on najlepszym rozwiązaniem do wdrażania kontenerów w chmurze. Dla mnie Kubernetes jest przedostatnią opcją dla wdrożeń w chmurze. Zaraz przed maszynami wirtualnymi.
Zanim utworzysz klaster, zastanów się, ile serwisów będziesz wdrażał. Jak często będziesz robił deploymenty. Jeżeli nie pracujesz w naprawdę dużej skali, odradzam Kubernetesa. Próg wejścia jak i wiedza potrzebna do poprawnego zarządzania klastrami są naprawdę wysokie.
Wróćmy jednak do pytania o chęć przenoszenia pomiędzy dostawcami chmury publicznej. Jeżeli nie jest konieczna, według mnie lepszym rozwiązaniem będzie skorzystanie z natywnych usług zarządzanych np. przez AWS jak Elastic Container Services. Potrafią praktycznie to samo, a są tańsze.
Gdy potrzebujesz uruchomić mniejszą ilość serwisów, są one prostsze, popatrz w stronę usług takich jak AppRunner w AWS lub CloudRun w GCP.
Zanim przejdziemy dalej podsumuję zalety i wady kontenerów.
Zalety:
- łatwiejsza migracja („przenaszalność”) pomiędzy różnymi środowiskami,
- prostsza migracja do kontenerów,
- praktycznie pełna kontrola nad aplikacją,
- pełna skalowalność aplikacji,
- możliwość wykorzystania dowolnego języka programowania,
- łatwiejszy monitoring.
Wady:
- płacimy nawet jeżeli nie używamy,
- wolniejsze skalowanie,
- często konieczność opieki nad infrastrukturą sprzętową,
- trudno zacząć dobrze,
- czasochłonne prace administracyjne przy samych kontenerach.
Usługi Serverless do tworzenia skalowalnych aplikacji lub modernizacji istniejących
W tej chwili naprawdę bardzo wiele firm, od najmniejszych do wielkich korporacji używa technologii Serverless. Zarówno do tworzenia nowej architektury aplikacji, jak i modernizacji istniejących rozwiązań. To naprawdę bardzo dojrzała technologia. O czym mowa?
Serverless to technologie i usługi, które pozostają cały czas w gotowości na obsłużenie żądań, a Ty płacisz tylko za te zasoby, które są realnie wykorzystywane. Serwery nie są włączone w trybie 24/7. Nie płacisz za czas, w którym są nieaktywne. Nie tworzysz kont użytkowników, Twoja aplikacja praktycznie nic Cię nie kosztuje – i co najważniejsze, nadal jest w stanie na bieżąco i w trybie ciągłym obsługiwać przychodzące żądania od Twoich użytkowników.
Tutaj jedna dygresja. Jeden z dostawców chmurowych zaczął jakiś czas temu dodawać do nazw usług słowo Serverless mimo, że tak naprawdę nie pracują one w ten sposób. Nawiązując do początku artykułu – przed rozpoczęciem pracy nad aplikacjami w chmurze koniecznie poproś o konsultacje kogoś, kto wie co robi.
Ponadto, w modelu Serverless nie zarządzasz infrastrukturą. Nie musisz nic aktualizować. Praktycznie za darmo dostajesz skalowalne i wysoko dostępne środowisko chmurowe. Często usługi mają też wbudowane mechanizmy do backupu (kopii zapasowej).
Myślę, że naprawdę warto spojrzeć także w tę stronę.
Zalety Serverless:
- płacimy tylko za rzeczywiste wykorzystanie, nie za gotowość do użycia,
- bardzo duża elastyczność, ( mikrousługi )
- automatyczne skalowanie,
- szybsze wejście na rynek z rozwiązaniem,
- brak konieczności zarządzania infrastrukturą,
- dobra separacja odpowiedzialności,
- wysoka dostępność.
Natomiast wady to:
- vendor lock-in,
- limity czasowe,
- brak lub utrudniona kontrola nad środowiskiem uruchomieniowym,
- budowa skomplikowanych aplikacji może być utrudniona.
Co więc wybrać: kontenery czy Serverless?
Na temat wymienionych wyżej zalet i wad na pewno można dyskutować. Nie zawsze doprowadzą one do celu, którym jest wybór odpowiedniej technologii, z której skorzystamy przy wdrożeniu aplikacji w chmurze.
Osobiście zawsze, przy każdej nowej aplikacji, zaczynam od próby wykorzystania usług Serverless. I prawie zawsze jest to dobra decyzja.
Kilka wskazówek na koniec
Jeżeli:
- migrujesz aplikację,
- potrzebujesz mieć możliwość migracji pomiędzy różnymi dostawcami chmury publicznej i on-premises,
- potrzebujesz procesów, które długo działają.
Wybierz Kontenery (eng. Containers).
Jeżeli natomiast:
- zależy Ci na szybkim uruchomieniu aplikacji,
- chcesz mieć, bez nakładu wielu sił, automatycznie skalowane rozwiązania,
- nie chcesz dużo płacić,
- potrzebna jest Ci wysoka dostępność.
Wybierz Serverless.
Po co modernizować systemy z wykorzystaniem chmury publicznej?
No właśnie. To pytanie powinno zostać zadane każdemu, kto wybiera się do Amazon Web Services(AWS), Gooogle Cloud Platform(GCP) lub Microsoft Azure.
Czego oczekujesz? Co chcesz osiągnąć? To są najważniejsze pytania.
Jakich szukam plusów związanych z wykorzystaniem usług chmurowych?
Oto one:
Obniżenie kosztów
Obniżenie kosztów to kluczowy element strategii migracji do chmury. Migracja do chmury wymaga starannego doboru usług i dostosowania zasobów do rzeczywistych potrzeb aplikacji. Niezrozumienie tego może prowadzić do nadmiernego wykorzystania zasobów chmurowych i wzrostu kosztów.
Nowe możliwości
Chmura publiczna oferuje szeroki zakres usług, które mogą zaspokoić różnorodne potrzeby biznesowe. Nie masz ich pewnie w swojej serwerowni. W zależności od wymagań klienta i konkretnego projektu, można wybrać odpowiednie usługi chmurowe, które najlepiej pasują do określonych potrzeb. Gwarantuję, że po pewnym czasie spędzonym z chmurą ,odkryjesz wiele możliwości, które usprawnią Twoją pracę lub biznes.
Elastyczność
To jedna z największych zalet chmur publicznych. Potrzebujesz zasobów? W chmurze publicznej uzyskasz je za pomocą kilku kliknięć lub poleceń w konsoli. Dodatkowo, w chmurze możemy automatycznie skalować zasoby w zależności od potrzeb, co pozwala zoptymalizować wykorzystanie zasobów i zapewnić ciągłą dostępność aplikacji. Bez problemów pozbędziesz się także niepotrzebnych już zasobów.
Szybkość, zwinność
Bez względu na to, czy potrzebujesz jedynie prostego PoC (ang. Proof of Concept), czy też pełnoprawnego projektu produkcyjnego, uzyskasz potrzebną infrastrukturę natychmiastowo, bez konieczności przeprowadzania skomplikowanych przetargów. Usługi chmurowe oferują elastyczność zasobów w zależności od aktualnych potrzeb, co sprawia, że są idealnym wyborem dla wszystkich projektów.
Ograniczenie nakładu pracy
Nie lubisz spędzać czasu na przeciąganiu kabli sieciowych pomiędzy dzielnicami wielkiego miasta czy kontynentami? Kto lubi aktualizować urządzenia wirtualne albo serwery baz danych? Ile czasu spędziłbyś na uruchomieniu infrastruktury na dwóch kontynentach? W chmurze możemy się tych wszystkich wyzwań pozbyć. Tego, a nawet więcej.
Wszystkiego na raz oczywiście nie osiągniemy. Przynajmniej nie zawsze. Rozpocznijmy od drobnych kroków w wybranym kierunku.
Podsumowanie
Czy modernizacja aplikacji poprzez jej migrację do chmury publicznej ma sens? Bardzo często tak. Wiele zależy od sposobu i podejścia do wykonania migracji.
Proste przeniesienie aplikacji do chmury da nam mniej zysków niż jej migracja przeprowadzona wraz z modernizacją.
Czy zawsze powinniśmy modernizować aplikację przed jej wdrożeniem w chmurze publicznej? Oczywiście nie. Nie zawsze będzie to miało sens. Jeżeli nakład pracy będzie niewspółmiernie wysoki do uzyskanych rezultatów, nie powinniśmy takiej modernizacji robić.
Jeżeli zdecydujemy się na migrację połączoną z modernizacją lub tworzeniem aplikacji od zera, zastanówmy się nad wyborem odpowiedniego modelu wdrożenia. A jeżeli Cloud Native to kontenery czy Serverless? Niestety nie ma na to pytanie jednej i słusznej odpowiedzi. Poza sławnym “to zależy”.
Ja dążę zawsze do Serverless, ale nie zawsze będzie to najlepszy wybór.
Projektowanie aplikacji natywnych nie jest proste. Jednak odpowiednia architektura aplikacji pozwoli wykorzystać zalety aplikacji natywnych w chmurze.
Przy modernizacji aplikacji ważną rolę odgrywa proces analizy przed podjęciem jakichkolwiek działań. To właśnie on pomaga odpowiedzieć na wiele pytań związanych z modernizacją i wdrożeniem w chmurze publicznej.
