Budowanie Azure, które przetrwa w prawdziwym świecie — z Mike Martinem [MVP]

Architektura Azure wygląda łatwo, gdy wszystko działa. Prawdziwy test zaczyna się wtedy, gdy zawodzą zależności, regiony stają się niedostępne, ruch gwałtownie rośnie, założenia okazują się błędne, wymagania się zmieniają, a ktoś w końcu zada niewygodne pytanie: dlaczego zaprojektowaliśmy to w ten sposób?W tym odcinku M365.FM Mirko Peters rozmawia z Mikiem Martinem [MVP] o tym, jak wygląda architektura Azure, gdy musi przetrwać rzeczywiste warunki produkcyjne, a nie tylko dobrze prezentować się na diagramie.Mike ma za sobą dziesięciolecia doświadczenia w programowaniu, infrastrukturze, architekturze, zarządzaniu, coachingu, szkoleniach oraz Microsoft Azure. Jedna z jego najważniejszych obserwacji jest taka, że wiele problemów, z którymi mierzą się dziś architekci, wcale nie jest nowych. DNS nadal potrafi się zepsuć. Zależności od adresów IP nadal mają znaczenie. Koszty nadal stanowią problem. Integracje nadal zawodzą. Zależności nadal znikają w najgorszym możliwym momencie.Zmieniła się natomiast złożoność, którą wokół tych problemów budujemy.

OD VISUAL BASIC DO NOWOCZESNEJ ARCHITEKTURY AZURE
Mike wraca pamięcią do prawie trzech dekad pracy w IT, zaczynając jako programista Visual Basic w latach 90., a następnie przechodząc przez systemy rozproszone, sieci, oprogramowanie korporacyjne, infrastrukturę i wreszcie Azure.Jego kluczowa obserwacja jest prosta: branża wciąż rozwiązuje te same podstawowe problemy, ale architektury wokół nich stały się znacznie bardziej złożone.Nowoczesne systemy przeszły od aplikacji klient-serwer do architektur rozproszonych, platform chmurowych, kontenerów, mikrousług, Kubernetes, środowisk hybrydowych i teraz także do tworzenia oprogramowania wspomaganego przez AI.To tworzy ogromne możliwości, ale też nowe ryzyko: nadmierną inżynierię.Mike twierdzi, że wiele zespołów dziś komplikuje proste problemy bez potrzeby. Dobra architektura często polega nie na dodawaniu kolejnych technologii, lecz na wiedzy, czego nie dodawać.

CZYM FAKTYCZNIE ZAJMUJE SIĘ ARCHITEKT AZURE?
Dla Mike'a architektura nie polega na wybieraniu jak największej liczby usług Azure ani na tworzeniu imponującego diagramu.Chodzi o zrozumienie, które komponenty powinny współpracować, których należy unikać, które są konieczne i jak zbudować rozwiązanie, które pozostaje łatwe w utrzymaniu, skalowalne, bezpieczne i odporne na awarie.Architektura obejmuje znacznie więcej niż obliczenia.

• Tożsamość
• Sieć
• Przepływy danych
• Bezpieczeństwo
• Monitorowanie
• Integracja
• Zależności
• Skalowalność
• Operacje
• Odzyskiwanie po awarii
• Wdrażanie
• Koszt

Mike kwestionuje też przekonanie, że architektura cloud-native automatycznie oznacza Kubernetes lub kontenery. Azure oferuje wiele usług zarządzanych i natywnych, które potrafią rozwiązać problemy bez wprowadzania zbędnego obciążenia operacyjnego.Rola architekta polega na zrozumieniu całego rozwiązania i wybraniu najprostszej architektury, która nadal spełnia rzeczywiste wymagania.

ZACZNIJ OD WYMAGAŃ BIZNESOWYCH, NIE OD USŁUG AZURE
Jedna z najważniejszych lekcji z tego odcinka jest prosta: nie zaczynaj od technologii.Zanim zdecydujesz się między Azure Kubernetes Service, App Service, Azure Functions, kontenerami, Service Bus lub inną platformą, zespoły powinny najpierw zrozumieć, co rozwiązanie faktycznie ma robić.Pytania do zadania:

• Czy rozwiązanie jest wewnętrzne, czy skierowane do klientów?
• Ilu użytkowników będzie od niego zależnych?
• Czy musi skalować się globalnie?
• Jak długo może być niedostępne?
• Ile danych biznes może sobie pozwolić stracić?
• Jakie wymagania zgodności mają zastosowanie?
• Co się stanie, jeśli aplikacja zniknie na kilka godzin?
• Kogo to dotknie?
• Jaki poziom wsparcia operacyjnego jest wymagany?

Te pytania prowadzą bezpośrednio do pojęć takich jak SLA, SLO, RTO i RPO. Determinują również, czy architektura powinna być jednoregionowa, wieloregionowa, aktywno-aktywna, aktywno-pasywna czy po prostu znacznie prostsza.

RTO I RPO BEZ ŻARGONU
RTO i RPO są często omawiane jako techniczne skróty, ale ich rzeczywiste znaczenie ma charakter biznesowy.

• RTO — Recovery Time Objective: jak szybko system musi wrócić po awarii?
• RPO — Recovery Point Objective: jaka utrata danych jest dopuszczalna?

System używany do niekrytycznego monitorowania może tolerować kilka godzin przestoju lub utraty danych. System wspierający służby ratunkowe, operacje finansowe, handel lub infrastrukturę krytyczną może wymagać odzyskania w ciągu minut.Ważne jest to, że tych wartości architekt nie powinien wymyślać samodzielnie. Powinny wynikać z rzeczywistego wpływu awarii na biznes.Gdy wymagania są już zrozumiane, można je przełożyć na decyzje projektowe.

ODPORNOŚĆ NIE JEST TYM SAMYM CO WYSOKA DOSTĘPNOŚĆ
Mike posługuje się prostą analogią, aby wyjaśnić różnicę między dostępnością a odpornością.System wysoko dostępny może mieć gotowy inny komponent, który przejmie pracę, gdy podstawowy ulegnie awarii.System odporny jest zaprojektowany tak, by wchłaniać problemy, nadal działać, łagodnie się odzyskiwać i wracać do normy bez całkowitego załamania.Ta różnica ma znaczenie.Aplikacja może technicznie być dostępna, a mimo to zapewniać słabe doświadczenie. Może być:

• Wolna
• Ograniczana (throttling)
• Częściowo niedostępna
• Zależna od awaryjnego backendu
• Dotknięta problemem integracji
• Pod presją regionalną

Prawdziwa odporność wymaga zatem czegoś więcej niż czasu sprawności.Wymaga architektury, która poradzi sobie z obciążeniem, błędami aplikacji, częściowymi awariami, problemami regionalnymi, zepsutymi zależnościami, incydentami operacyjnymi i odzyskiwaniem po zakończeniu incydentu.

AZURE NIE SPRAWIA, ŻE APLIKACJA STAJE SIĘ ODPORNA AUTOMATYCZNIE
Jednym z niebezpiecznych założeń jest przekonanie, że skoro sam Azure jest wysoko dostępny, każda aplikacja działająca w Azure automatycznie dziedziczy tę odporność.Tak nie jest.Microsoft dostarcza usługi i możliwości, które umożliwiają tworzenie odpornych architektur.Klienci nadal muszą projektować odporność.Tu znaczenie mają wzorce architektoniczne:

• Wyłączniki obwodu (circuit breakers)
• Luźne powiązanie komponentów
• Przetwarzanie asynchroniczne
• Niezależne skalowanie
• Wiele stref dostępności
• Wiele regionów
• Mechanizmy przełączania awaryjnego (failover)
• Monitorowanie
• Infrastruktura jako kod
• Testowane procedury odzyskiwania

Microsoft dostarcza elementy budulcowe. To architektura decyduje, czy z tych elementów powstanie rzeczywiście odporny system.

DLACZEGO PROJEKTOWANIE ASYNCHRONICZNE MA ZNACZENIE
Jeden z najmocniejszych przykładów w rozmowie pochodzi z systemów, które doświadczają przewidywalnych skoków ruchu, takich jak portale podatkowe administracji państwowej.Typowy problem projektowy pojawia się wtedy, gdy każda akcja zależy od synchronicznej operacji backendu.Użytkownik klika przycisk.Frontend czeka na backend.Backend czeka na inną usługę.Inna zależność zwalnia. W końcu na doświadczenie użytkownika wpływa cały system.Mike wyjaśnia, dlaczego systemy luźno powiązane często są bardziej odporne. Zamiast zmuszać frontend do czekania na każdą operację backendu, aplikacje mogą umieszczać zadania w kolejkach lub systemach sterowanych zdarzeniami i pozwolić komponentom przetwarzać zadania niezależnie.Daje to kilka korzyści:

• Różne komponenty mogą skalować się niezależnie
• Jedna usługa może ulec awarii bez zatrzymania całej platformy
• Backendy mogą przetwarzać pracę asynchronicznie
• Skoki ruchu łatwiej wchłonąć
• Komponenty działające po stronie użytkownika stają się mniej zależne od czasu odpowiedzi backendu
• Awarie łatwiej izolować

MIT 100-PROCENTOWEJ DOSTĘPNOŚCI
Innym głównym tematem dyskusji jest obsesja na punkcie 100-procentowej dostępności.Mike jest bardzo jasny: 100-procentowy czas sprawności nie jest realistycznym celem architektonicznym.Rozwiązanie zwykle składa się z wielu usług.Każda usługa ma własne SLA.Gdy połączy się kilka zależności, łączna dostępność...