10 Zasad Tworzenia Rozproszonych Aplikacji w Oparciu o Microsoft Azure

Przez ostatnich kilka lat przechodziłem wiele razy przez proces projektowania i tworzenia aplikacji chmurowych współpracując z różnymi klientami. W trakcie tej pracy, a także rozmów z wieloma architektami rozwiązań chmurowych utworzyłem zasadę, którą zawsze stosuję projektując nowe aplikacje:

Wybierz chmurę pod projekt i zrób projekt pod chmurę.

Mówi ona o tym, żeby w pierwszej kolejności przeanalizować wymagania biznesowe i dobrać odpowiednie narzędzia chmurowe je realizujące, a następnie podczas procesu tworzenia architektury i implementacji, tworzyć rozwiązania, które jak najlepiej zintegrują się z wybranymi technologiami cloudowymi.

W celach pełnego zastosowania tej dewizy, należy wziąć pod uwagę 10 prostych zasad, które sprawią, że nasz projekt odniesie sukces w chmurze.

Zasada 1: Zaprzyjaźnij się z chmurą!

Microsoft Azure rozwija się w olbrzymim tempie, z tygodnia na tydzień powstają nowe update’y istniejących usług jak i całkiem nowe serwisy. Skutkiem tego jest bardzo duża ilość możliwości rozwiązania danego problemu biznesowego.

Dodatkowo dochodzą jeszcze kwestie ogólnych ograniczeń chmury i sposoby bilingowania poszczególnych komponentów oraz transferu.

Sposobem ogarnięcia tych kwestii jest posiadanie ogólnej wiedzy na temat większości usług dostępnych w Azure. Pozwoli to na stworzenie koncepcyjnej warstwy architektury, dzięki czemu będziemy w stanie dobrać odpowiednie storage danych, zaprojektować dogodną komunikację między serwisami.

Zasada 2: Używaj PaaS, SaaS i FaaS zamiast IaaS

Jest to dość kontrowersyjna zasada, jednak przewaga chmury nad lokalnym data center leży właśnie w usługach PaaS-owych. Dzięki nim jesteśmy w stanie zmniejszyć koszta utrzymania naszej aplikacji, ulepszyć możliwość autoskalowania i georeplikacji.

W tej zasadzie pojawiają się dwie kwestie. Pierwsza z nich dotyczy baz danych. W modelach PaaS (lub jak to niektórzy określają DBaaS – DataBase as a Service) koszty użycia baz danych są nawet kilkanaście razy tańsze niż w przypadku posiadania jej w modelu IaaS. Różnice te opierają się między innymi na cenach licencji oprogramowania, gdzie w przypadku infrastruktury w skład wchodzą system operacyjny serwera, licencja na silnik bazodanowy.

W przypadku MS SQL różnica cen pomiędzy usługą PaaS i IaaS sięga nawet jednego poziomu rzędu jednostek.

Dodatkowo wykorzystanie DaaS prowadzi do posiadania wbudowanych mechanizmów backupów, disaster recovery oraz georeplikowalności, co przyśpiesza proces developmentu i ściąga z nas potrzebne administrowania i kontroli nad skomplikowanymi mechanizmami, które musielibyśmy zbudować w modelu IaaS.

Sytuacja wygląda podobnie w przypadku usług hostujących nasze serwisy lub kod. Gdy zamiast maszyn wirtualnych, wykorzystamy Azure Functions, Web Apps lub inne usługi dedykowane typu Stream Analytics, Event Hubs itd. to koszt developmentu aplikacji i jej utrzymania zostanie mocno obniżony. Wynika to z tego, że większość mechanizmów integracji, obsługi streamingu danych, skalowania wielowątkowego przetwarzania przejmuje na siebie bezpośrednio usługa z której korzystamy.

Zasada 3: Podziel funkcjonalność na jak najmniejsze serwisy.

W chmurze bardzo dobrze sprawdza się architektura mikroserwisów. Pozwala nam ona na podzielenie naszej aplikacji na małe niezależne elementy, realizujące odseparowaną logikę biznesową. Dzięki temu zabiegowi jesteśmy w stanie:

• Niezależnie skalować poszczególne elementy systemu, nie musząc płacić za pozostałe elementy.
• Zrealizować funkcjonalność niektórych serwisów/logiki biznesowej za pomocą dedykowanych do tego usług chmurowych np.: Stream Analytics, Event Hub, IoT Hub, Mobile App, Azure AD B2C, Media Services itp.
• Dzięki podziałowi, jesteśmy w stanie wybrać technologię (np. jeden serwis NodeJS a drugi .Net), które najlepiej adresują poszczególne wymagania biznesowe.
• W razie awarii jednej usługi PaaS pozostała część serwisów powinna działać dalej.
• W momencie wygaszania danej usługi lub pojawienia się serwisu chmurowego, który jest w stanie zrealizować nasz problem biznesowy wydajniej i taniej od aktualnego jesteśmy w stanie niskim nakładem pracy przenieść jeden element na nową technologię. Zakłada się że przepisanie pojedynczego serwisu nie powinno zabierać więcej niż 2 tygodnie pracy.

Zasada 4: Twórz bezstanowe usługi

Usługi nieposiadające stanów dają nam duże możliwości skalowania i kontroli ich cyklu życia, co bezpośrednio przekłada się na niższe koszta eksploatacji chmury oraz większą szybkość i niezawodność systemu.

Główne zalety:

• Łatwe dynamiczne skalowanie usług.
• Proste disaster recovery – usługa od razu po uruchomieniu jest gotowa do pracy.
• Niższe koszta zasobów wykorzystywanych do hostowania zasobu.
• Możliwość użycia usług serverless w modelach consumption plan.
• Możliwość wykorzystania konteneryzacji do uruchamiania naszych aplikacji.

Zasada 5: Używaj usług wspierających do przechowywania danych i stanów.

Dane i stany muszą być przechowywane poza naszymi serwisami. W tym celu musimy użyć tzw usług wspierających. W przypadku MS Azure, narzędziami idealnie nadającymi się do tego są Azure SQL, CosmosDB czy Redis Cache. Są to rozwiązania PaaS pozwalające na przechowywanie i magazynowanie danych, które są przekazywane poprzez serwisy bezstanowe.

Kluczem do wykorzystania ich jest odpowiednie zaprojektowanie modelu danych, tak aby był on na tyle niezależny, aby dla każdego problemu biznesowego udało się wydzielić go do niezależnej bazy danych.

W przypadku korzystania z bazy Azure SQL, polecam zapoznanie się z Elastic Poolem, który pomoże znacząco obniżyć koszta hostowania wielu małych baz SQL dla naszych serwisów. Bazy uruchomione w tym modelu korzystają z tych samych zasobów, za które bezpośrednio płacimy. Asynchroniczne rozłożenie ruchu w aplikacjach pozwala rozsynchronizować momenty zapotrzebowania na zasoby przez bazy.

Zasada 6: Korzystaj z rozwiązań PaaS do komunikacji między serwisowej!

Większość serwisów pracuje asynchronicznie. Duża część systemów projektowanych przez nas zajmuje się przetwarzaniem dużej ilości danych. W obydwóch tych przypadkach klasyczna komunikacja http pomiędzy usługami jest utrudniona i ciężka do utrzymania, szczególnie w scenariuszach disaster recovery.

Chmura jednak wychodzi nam naprzeciw ze swoimi rozwiązaniami do streamingu danych lub obsługi komunikatów. Są nimi Event Hub i Service Bus.

Zalety:

• Pozwalają w razie awarii przechowywać komunikaty z retencją nawet do kliku dni.
• Możliwość asynchronicznej komunikacji pomiędzy serwisami.
• Rozładowywanie wysokiego natężenia komunikatów w krótkim momencie czasu.
• Łatwa integracja z rozwiązaniami z Stream Analytics i Azure Functions.

Zasada 7: Wszystko kiedyś PADA!

Każda usługa PaaS może kiedyś ulec awarii. Świadomość tego zdarzenia pozwala nam się zabezpieczyć przed takimi sytuacjami. Poniżej kilka wskazówek, które mogą okazać się pomocne w radzeniu sobie z awariami:

• Replikuj kluczowe serwisy w swoim systemie.
• Ustaw georeplikacje i failover w kluczowych bazach danych.
• Znaj zachowanie usług PaaS w przypadku awarii.
• Posiadaj plan disaster recovery dla wszystkich usług.

Zasada 8: Build, Deploy, Stage  i Run

Dla rozproszonych aplikacji chmurowych podstawą jest dobrze działający  mechanizm continuous delivery.  Musi posiadać on rozdzielone przynajmniej 4 fazy:

• Build – tworzenie z kodu artefaktów, które zostaną wdrożone na środowiska stage.
• Deploy – proces wdrażania artefaktów uzupełnionych o konfigurację dla konkretnego środowiska.
• Stage – środowisko identyczne z środowiskiem produkcyjnym, na którym zostaną wdrażane nowe funkcjonalności i fixy.
• Run – Środowisko produkcyjne uruchamiane na zasadzie swapa z środowiskiem stage. Nie trafia tutaj bezpośrednio deploy.

Większość usług PaaS posiada natywne wsparcie dla metody działania Stage -> Swap -> Prod.

Zasada 9: Logi, Logi, Logi

Śledzenie i monitorowanie działania systemu opartego o dużą ilość serwisów jest trudne. Wymaga ono gromadzenia naprawdę porządnych logów z wielu źródeł.

• Traktuj logi jako strumień danych.
• Przekazuj unikalny identyfikator “procesu logicznego” poprzez wszystkie aplikacje.
• Gromadź i analizuj logi w specjalnych narzędziach typu Application Insights.

Zasada 10: Automatyzuj, Monitoruj, Optymalizuj

• Automatycznie skaluj serwisy w celach zwiększenia oszczędności.
• Monitoruj i optymalizuj swoją aplikację.
• Health checki – stwórz mechanizmy, które pozwolą w szybki sposób określić stan usługi (działa/nie działa).
• Sprawdzaj aktualizacje chmury – mogą one mieć realny wpływ na stabilność Twoich aplikacji.