Cloud Native – czym jest dla mnie?

Zaczynam trochę samolubnie. Dlaczego dla mnie? Jeżeli zapytasz 10 osób, czym jest dla nich Cloud Native, to dostaniesz pewnie 10 różnych odpowiedzi. Będą między nimi podobieństwa, ale oczywiście na ich podstawie nie będziesz mógł wyrobić sobie jednoznacznej opinii. Zakładając, że jeszcze jej nie masz. Czego możesz się spodziewać? Na pewno usłyszysz o kontenerach. Ktoś powie o mikroserwisach. Przewinie się zapewne także termin Serverless. Zresztą główny spór toczy się pomiędzy Kontenerami, a Serverless - o tym za chwilę.

Po co nam chmura publiczna?

Zacznijmy jednak od najważniejszego. Po co idziemy do chmury? Co ona może nam właściwie dać? Cztery podstawowe rzeczy to:

• Zmniejszenie kosztów;
• Elastyczność;
• Szybkość działania i zwinność;
• Możliwości, które są trudno dostępne poza chmurą publiczną.

Ale jak to? Chmura przecież jest droga! Chmura może być droga, ale może też być tańsza niż Twoje środowisko on-premises. Prosty przykład. Czy maszyna, na której prowadzone są prace developerskie musi pracować 24 godziny na dobę? No pewnie nie. A może niektóre serwery można zastąpić usługami. Pamiętaj też, że dostawca chmury odpowiada za wiele rzeczy, którymi normalnie musisz zajmować się Ty lub komuś za to zapłacić to zapłacić.

Pewnie każdy z nas korzystał z okazji, które pojawiają się w różnego rodzaju „czarne piątki”. W takich okresach ruch na serwerach potrafi wzrosnąć wielokrotnie. Jesteś w chmurze, nie ma problemu. Bierzesz na przysłowiową chwilę więcej serwerów i obsługujesz swoich klientów zarabiając jednocześnie więcej. Kończy się promocja, wyłączasz niepotrzebne zasoby. We własnej serwerowni coś takiego nie jest takie trywialne. Wszystko to, może zresztą odbywać się całkowicie automatycznie. Bez Twojego udziału. Tak, chmura potrafi sama zadbać o skalowanie Twoich zasobów. Oczywiście sam decydujesz, jak to się ma odbywać.

Potrzebujesz jakichś zasobów? Klikasz, piszesz skrypt lub template i po chwili pracujesz. Chcesz zamienić serwer z 4 vCPU na taki z szesnastoma? Nie ma problemu. Kolejna chwila i możesz realizować swoje projekty. Developer poprosił o klaster Kubernetes. Kilkanaście minut później może na nim pracować.

Chmura daje Ci także mnóstwo możliwości, które nie są łatwo dostępne poza nią. Potrzebujesz zamienić rozmowę na tekst? Jest do tego usługa. Potrzebujesz zrobić OCR na skomplikowanym formularzu? Tu także się coś znajdzie. Przetwarzanie video? Agregacja ogromnych ilości danych z urządzeń IoT? Nie stanowi to kompletnie żadnej bariery.

Cloud Native ma nawet swoją fundację. Cloud Native Computing Foundation opiekuje się różnego rodzaju rozwiązaniami, które pomagają tworzyć rozwiązania Cloud Native. Tak zwany CNCF Landscape (https://landscape.cncf.io) to, w tej chwili ponad 1400 różnych narzędzi i platform. Nie tylko open source, ale także znajdziesz tam zarówno Kubernetesa, jak i np. Amazon Elastic Container Service for Kubernetes. Czy musisz znać te wszystkie meshe, bazy danych, api gatewaye czy rozwiązania do monitoringu i orkiestracji? Oczywiście, że nie.

Wróćmy jednak do definicji. Całość możesz przeczytać tu (https://github.com/cncf/toc/blob/master/DEFINITION.md#polski). CNCF wymienia tam kontenery, mikroserwisy, meshe, deklaratywne API, niezmienną infrastrukturę. Ja bym dodał do tego jeszcze idempotentność rozwiązań.

Po tym wszystkim rodzi się pytanie: Czego użyć? Czy maszyn wirtualnych i instalować na nich oprogramowanie? A może jednak kontenery? No i może wreszcie Serverless? A czy tu tak naprawdę chodzi o wybór technologii? Wybór rozwiązań informatycznych? Czy jedni muszą się upierać przy kontenerach, a inni przy Serverless? Odpowiedź brzmi nie. Generalnie chodzi o to jak zaprojektujemy nasze rozwiązania czy nasze aplikacje – to jest punkt wyjścia i jednocześnie nasz przyszły sukces.

Spośród różnych modeli wdrożeń w chmurze, Cloud Native możemy chyba nazwać tym najbardziej dojrzałym, ale też najbardziej wymagającym. Nie zawsze musimy go stosować. Jeżeli jednak chcemy w pełni wykorzystać potencjał, który daje nam chmura to dobrze jest mieć na uwadze następujące pryncypia:

• Automatyzacja związana zarówno z infrastrukturą, jak i wdrożeniami aplikacji;
• Wydajność, szybkość odpowiedzi, współbieżność;
• Elastyczność poprzez automatyczne skalowanie;
• Odporność na błędy, tzw. self-healing;
• Diagnozowalność poprzez dostęp do logów, metryk…;
• Automatyczne deployment’y, skrócenie czasu potrzebnego na wydanie nowych wersji
• Idempotentność.

Idempotentność rozwiązań jest ważna gdy projektujemy z myślą o naprawie, a nie o błędach. Pamiętaj o tym, że usługi mogą być restartowane wiele razy. Skalowanie horyzontalne spowoduje, że ilość dostawców usługi będzie się zmieniała. Zapytania mogą być ponawiane, a ich obsługa może być wykonywana przez różne instancje.

Pisząc o architekturze Cloud Native nie sposób nie wspomnieć o 12 Factor App (https://12factor.net/pl/), czyli o pryncypiach, którymi powinieneś kierować się przy projektowaniu i tworzeniu środowisk Cloud Native.

Do tej pory skupiłem się na architekturze aplikacji. Ale jest ona tylko środkiem, a potrzebny jest przecież także cel. Naszym celem są zadowoleni klienci, a więc niezawodność. Z tym związana jest tak zwana Inżynieria niezawodności, czyli Site Reliability Enginieering (SRE). Musisz odpowiedzieć sobie na trzy pytania:

1. Jak rozumiesz dostępność swoich usług?
2. Na jakim poziomie chcesz, aby Twoje usługi były dostępne?
3. Co zrobisz, gdy wystąpi awaria?

Zauważ, że nie ma tu nic o tym co obiecujesz klientowi. SLA to działka sprzedaży, nie inżynierów.

Jak więc to sobie wszystko zdefiniować? Mamy trzy wskaźniki:

1. SLI (Service Level Indicator) – to co akceptujemy wewnętrznie. Mierzymy np. czy w ciągu ostatniej godziny 99,5% odpowiedzi trwało krócej niż 150ms;
2. SLO (Service Level Objective) – czy i w jakim okresie utrzymujemy cel zdefiniowany w SLI;
3. SLA (Service Level Agreement) – to co obiecujemy I sprzedajemy klientowi. Określa % dostępności usługi dla klienta końcowego w jednostce czasu - miesiąc, rok.

I teraz najważniejsze pytanie. Czy potrzebujemy 100%? Prawie 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%.

Którędy zatem?

Wydaje mi się, że główny spór w obszarze Cloud Native jest taki: konteneryzować czy nie konteneryzować? Może Serverless i usługi natywne dostawców chmurowych? Nie ma jednej słusznej drogi. To zależy od wielu czynników, które mają na to bezpośredni i pośredni wpływ. Ja zazwyczaj stawiam sobie takie pytania:

1. Czy zależy mi na dużej przenaszalności rozwiązania pomiędzy dostawcami chmury i/lub środowiskiem on-premises? Mamy gotową aplikację?
2. Czy chcę jak najlepiej wykorzystać usługi i możliwości udostępniane przez konkretnego dostawcę?

Kontenery

Jeżeli większość plusów jest postawiona w kolumnie 1, myślę, że warto zastanowić się nad kontenerami. One pozwolą na w miarę bezbolesne migracje. Nie obędzie się na pewno bez zmian w aplikacjach, ale będą one mniejsze.

Jeżeli wybrałeś już kontenery, to kolejnym pytaniem będzie, czy koniecznie Kubernetes? Wiele osób utożsamia kontenery w chmurze z Kubernetesem, ale nie zawsze jest on najlepszym i najtańszym rozwiązaniem. Ja w tym momencie ponownie zadaję sobie kilka pytań:

1. Czy mam dużo serwisów?
2. Jak często wdrażam nowe wersje?
3. Czy naprawdę potrzebuję przenaszalności?

To ostatnie pytanie wydaje się nawet kluczowe. Jeżeli odpowiedź brzmi nie, to może lepszym rozwiązaniem będzie na przykład Amazon Elastic Container Service, który dostajemy za darmo, a który pozwala na naprawdę wiele. A może potrzebujemy uruchomić nasz kontener raz na jakiś czas. Ja bym popatrzył w stronę Fargate w AWS lub CloudRun w GCP.

A może jednak inaczej?

No właśnie. Może można lepiej, inaczej. Może ten Serverless ma jednak sens? Badania pokazują, że ponad 50% użytkowników AWS pracuje z funkcjami Lambda. Co więcej, ponad 75% korporacji ich używa. Nie jest to więc rozwiązanie tylko dla startupów. To już naprawdę dojrzałe technologie. Ale o czym mowa?

Przede wszystkim nie należy utożsamiać Serverless z FaaS, czyli np. funkcjami Lambda. Tak, one są serverless, ale takich usług jest o wiele więcej. Serverless to usługi, które pozostają cały czas w gotowości na obsłużenie żądań, a Ty płacisz tylko za wykorzystane zasoby. Nie masz włączonych cały czas serwerów, więc nie płacisz za czas, w którym są nieaktywne.

W modelu Serverless nie zarządzasz infrastrukturą. Praktycznie za darmo dostajesz wysoko dostępne i skalowalne rozwiązanie. Myślę, że warto spojrzeć także w tę stronę.

Podsumowując podstawowe zalety usług Serverless:

• nie zarządzasz infrastrukturą;
• dostajesz wysoko dostępne i skalowalne rozwiązanie;
• płacisz tylko za rzeczywiście zużyte zasoby -dostępne są one jednak non stop.

Co wybrać?

Zacznijmy od zalet obu podejść:

Podsumowanie

Wiem, ten zestaw zalet i wad można rozumieć na wiele sposobów. Oczywiście, każdy z wyżej wymienionych elementów to tylko zarys co się za nim kryje i jaka jest moja własna jego interpretacja.

Niech to zestawienie będzie przysłowiowym włożeniem kija w mrowisko, zaczątkiem merytorycznej i owocnej dyskusji. Na ten moment upraszczając decyzję co wybrać, ja proponuję następujące rozwiązanie:

Jeżeli:

• Migrujesz aplikację legacy;
• Zależy Ci na bardzo dużej elastyczności i możliwościach;
• Chcesz mieć możliwość migracji pomiędzy chmurą i on-premises;
• Potrzebujesz długo działających procesów.

Wybierz kontenery.

Jeżeli natomiast:

• Zależy Ci na szybkim development’cie;
• Chcesz mieć łatwo i automatycznie skalowane rozwiązania;
• Nie chcesz dużo płacić;
• Potrzebne Ci HA.

Idź w stronę Serverless.