Wdrażanie mikrousług w środowiskach produkcyjnych

Informatec Digital » Zasoby » Wdrażanie mikrousług w środowiskach produkcyjnych

Wdrożenie architektury mikrousług w środowisku rzeczywistym nie polega jedynie na rozbiciu monolitu na mniejsze części; wymaga to ponownego przemyślenia infrastruktury, zespołów, procesów, danych, bezpieczeństwa i operacji . Przejście systemu z fazy teoretycznej do klastra produkcyjnego wiąże się z problemami dotyczącymi wykrywania usług, umów między zespołami, CI/CD, obserwowalności, odporności i skalowalności. Jeśli te problemy nie zostaną odpowiednio rozwiązane, mogą one przekształcić mikrousługi w rozproszony chaos.

Dobrą wiadomością jest to, że dziś dysponujemy bogatym doświadczeniem zgromadzonym przez organizacje takie jak Netflix, Amazon, Google i inne duże korporacje, które wdrażają setki mikrousług w środowisku produkcyjnym . Opierając się na tych doświadczeniach, a także na najlepszych praktykach w środowiskach korporacyjnych wykorzystujących Kubernetes i OpenShift, możemy opracować bardzo solidne podejście do projektowania, wdrażania i obsługi mikrousług na dużą skalę bez utraty kontroli.

Dlaczego warto wdrażać mikrousługi w środowisku produkcyjnym (i kiedy nie warto)

Dobrze zaprojektowana architektura mikrousług pozwala na współpracę z małymi, autonomicznymi i wielofunkcyjnymi zespołami , które przejmują odpowiedzialność za kompleksową usługę. Każdy zespół działa w ściśle określonym kontekście, może często wdrażać rozwiązania i przejmuje pełną odpowiedzialność za swoją usługę, skracając czas cyklu rozwoju i przyspieszając dostarczanie nowych funkcji.

Kolejną kluczową korzyścią jest niezależne skalowanie dla każdej usługi . Nie musisz przewymiarowywać całej aplikacji, jeśli tylko katalog, system płatności lub publiczne API odnotowują wzrosty ruchu. Możesz dostosować każdą mikrousługę w poziomie lub w pionie, w zależności od jej obciążenia, dokładnie mierzyć koszt każdej funkcji i utrzymywać dostępność nawet w przypadku gwałtownego wzrostu zużycia w danym obszarze.

Sposób pakowania i wdrażania tych usług ułatwia ciągłą implementację o niskim ryzyku . Niezależne udostępnianie każdej mikrousługi znacznie ułatwia testowanie nowych pomysłów i przywracanie problematycznych wersji: wdrożenia kanarkowe, wycofywanie zmian w trybie blue/green oraz automatyczne wycofywanie zmian zmniejszają koszty awarii i zapewniają przestrzeń do eksperymentowania.

Z technologicznego punktu widzenia mikrousługi zapewniają swobodę wyboru języków, frameworków i baz danych dla każdej usługi. Nie wszystkie potrzeby mieszczą się w tym samym stosie technologicznym: możesz mieć usługi biznesowe w .NET lub Javie, przetwarzanie danych w Scali/Spark, usługi specjalistyczne w Pythonie lub F#, a mikrousługi AI w R. Ta kontrolowana różnorodność pozwala na użycie odpowiedniego narzędzia w każdym przypadku, bez konieczności przeprowadzania globalnej zmiany technologicznej w całej aplikacji.

Co więcej, podział systemu na małe, dobrze zdefiniowane fragmenty ułatwia ponowne wykorzystanie funkcjonalności jako elementów składowych . Mikrousługa początkowo utworzona jako część większej funkcjonalności może być później ponownie wykorzystana jako zależność od innych części systemu bez konieczności przepisywania logiki. Ponieważ usługi są izolowane, awaria jednej z nich zazwyczaj skutkuje częściową degradacją systemu, a nie jego całkowitą awarią, pod warunkiem, że odporność została zaprojektowana od samego początku.

Projektowanie architektoniczne i usługowe

Aby mikrousługi dobrze funkcjonowały w środowisku produkcyjnym, konieczne jest rozpoczęcie od starannego zaprojektowania granic usług i odpowiedzialności . W praktyce zazwyczaj zaczyna się to od identyfikacji usług o dużej skali w ramach istniejącego monolitu: dużych obszarów funkcjonalnych lub domen biznesowych (np. zamówień, katalogu, użytkowników, rozliczeń), które są już logicznie rozdzielone.

Zaczynając od tych dużych bloków konstrukcyjnych, proces obejmuje udoskonalenie projektu w celu uzyskania drobnoziarnistych mikrousług, które działają na spójnym zbiorze danych , posiadają własny model i dokładnie wiedzą, co muszą odczytywać lub zapisywać w innych usługach. Proces ten zazwyczaj opiera się na koncepcjach projektowania zorientowanego na domenę (DDD) i ograniczonych kontekstach, zapobiegając przekształceniu się mikrousługi w „mini monolit”.

Interfejsy API udostępniające te usługi muszą mieć dobrze zdefiniowane i stabilne kontrakty . Oznacza to rygorystyczną dokumentację (REST z OpenAPI, gRPC z plikami .proto itp.), jawne wersjonowanie, zachowanie wstecznej kompatybilności w miarę możliwości oraz automatyzację walidacji kontraktów w celu wykrywania zmian powodujących awarie, zanim trafią one do środowiska produkcyjnego.

W środowiskach z dziesiątkami, a nawet setkami usług, kluczowe jest uwzględnienie wzorców odporności już na etapie projektowania, aby system był przygotowany na częściowe awarie . Wzorce takie jak wyłączniki, ponowne próby z odliczaniem czasu, ściśle zdefiniowane limity czasu, grodzie i mechanizmy presji zwrotnej pomagają zapobiegać awariom jednej usługi, które mogłyby spowodować awarię pozostałych. Narzędzia inżynierii chaosu, takie jak ChaosMonkey czy Gremlin, są przydatne do praktycznego testowania zachowania platformy w symulowanych awariach.

Wiele złożonych systemów łączy stosunkowo proste usługi CRUD z bardziej zaawansowanymi, które obsługują ewoluujące reguły biznesowe. Nie wszystkie mikrousługi wymagają złożonej architektury wewnętrznej : niektóre mogą być prostymi kontrolerami HTTP z podstawowym dostępem do danych, podczas gdy inne, takie jak usługi zamówień czy rozliczeń, mogą wykorzystywać bardziej zaawansowane wzorce (DDD, CQRS, zdarzenia domenowe itp.).

Infrastruktura produkcyjna: chmura, kontenery i Kubernetes/OpenShift

Doświadczenia praktyczne pokazują, że mikrousługi działają znacznie lepiej, gdy są wdrażane w infrastrukturze chmurowej z kontenerami i orkiestracją, niż na izolowanych maszynach wirtualnych. Platformy takie jak Kubernetes i OpenShift zapewniają niezbędne prymitywy do pakowania usług w kontenery, skalowania, aktualizacji, równoważenia obciążenia i zarządzania wysoką dostępnością.

Zazwyczaj każda mikrousługa jest pakowana w obraz kontenera oparty na korporacyjnym obrazie bazowym (na przykład OpenJDK 21 dla usług Java) zarządzanym przez zespół ds. infrastruktury. Ten obraz bazowy jest aktualizowany o poprawki zabezpieczeń, a po wydaniu nowej wersji zespoły programistyczne odpowiadają za przebudowę i ponowne wdrożenie swoich usług w odpowiednich środowiskach.

W Kubernetes/OpenShift podstawową jednostką wdrożeniową jest kontener (pod), który hermetyzuje jeden lub więcej kontenerów . Zazwyczaj mikrousługa odpowiada typowi kontenera i jest wdrażana przy użyciu zasobów takich jak Deployments (w przypadku usług bezstanowych) lub StatefulSets (gdy występuje powiązany stan). Od samego początku definiowana jest minimalna liczba replik na środowisko, aby środowiska testowe, przedprodukcyjne i produkcyjne miały poziomy dostępności odpowiednie do ich krytyczności.

Automatyczne skalowanie jest implementowane za pomocą HorizontalPodAutoscaler (HPA) , który dostosowuje liczbę replik na podstawie metryk, takich jak procesor, pamięć i inne niestandardowe metryki. Platforma musi również skonfigurować reguły antypowinowactwa kontenerów, aby rozmieścić repliki tej samej usługi na różnych węzłach, zapobiegając awarii pojedynczego węzła, która mogłaby spowodować wyłączenie wszystkich instancji.

W odniesieniu do rozmiaru pionowego, zasoby.requests i zasoby.limits służą do definiowania zakresu zasobów procesora i pamięci, jakie może wykorzystać kontener. Na przykład, rezerwując minimum 100 MB zasobów procesora i 256 MB pamięci, a zezwalając odpowiednio na 500 MB i 2 GB dla usługi Java, dostosowujemy maszynę wirtualną Java (Xms, Xmx, Xss) w celu optymalnego wykorzystania zasobów kontenera.

Zarządzanie stanem: mikrousługi bezstanowe i stanowe

Większość mikrousług biznesowych jest projektowana jako usługi bezstanowe . Oznacza to, że kontener nie przechowuje informacji niezbędnych do przetrwania po ponownym uruchomieniu; stan jest utrwalany w zewnętrznych bazach danych, kolejkach komunikatów lub innych pamięciach masowych. Takie podejście ułatwia dynamiczne skalowanie poziome i bezproblemowe wdrożenia, ponieważ każda replika może obsłużyć dowolne żądanie.

Istnieją jednak scenariusze, w których nie ma innej alternatywy niż obsługa mikrousług stanowych przez woluminy trwałe . Dotyczy to niektórych baz danych, rozproszonych systemów plików lub komponentów wymagających lokalnego przechowywania danych. Te kontenery są zazwyczaj wdrażane z użyciem obiektów StatefulSet, połączone z woluminami PersistentVolume za pomocą obiektów PersistentVolumeClaims i skalowane pionowo, a nie poziomo.

Gdy mikrousługa potrzebuje trwałej pamięci masowej, żądane jest PersistentVolumeClaim (PVC) z jego rozmiarem, trybem dostępu i przeznaczeniem , a zespół operacyjny dostarcza je zgodnie z politykami platformy. Ten PVC jest przywoływany w manifeście wdrożenia i montowany w podzie, aby usługa mogła trwale odczytywać i zapisywać dane.

Chociaż modele stanowe mogą być konieczne w określonych przypadkach, generalnie zaleca się, aby jak najwięcej usług pozostawało bezstanowych . Upraszcza to wdrażanie, skalowanie, odporność i odzyskiwanie po awarii oraz zmniejsza złożoność operacyjną w środowiskach z wieloma mikrousługami.

Decentralizacja danych i suwerenność usług

W tradycyjnych infrastrukturach powszechna jest centralizacja baz danych i pamięci masowej w celu maksymalizacji wydajności. W przypadku mikrousług takie podejście koliduje z autonomią zespołów i ich rozdzieleniem . Jeśli wiele usług korzysta z tego samego schematu relacyjnego, każda zmiana strukturalna może zablokować wiele zespołów i nieumyślnie zakłócić kompatybilność.

Dlatego zalecaną praktyką jest, aby każda mikrousługa posiadała własny model danych i bazę danych , chociaż w środowisku programistycznym baza danych działa jako kontener w klastrze, aby uprościć wdrożenie. W środowisku produkcyjnym zazwyczaj używa się instancji zarządzanych w chmurze lub innych serwerów baz danych o wysokiej dostępności, zawsze zachowując jasną granicę własności.

Nie oznacza to braku integracji danych; oznacza to, że spójność między usługami jest zarządzana za pomocą zdarzeń i asynchronicznych komunikatów , akceptując ostateczną spójność w uzasadnionych przypadkach. Powszechne jest korzystanie z magistrali zdarzeń (RabbitMQ, Azure Service Bus, Kafka itp.) do propagowania zmian stanu między mikrousługami, co zmniejsza silne zależności od pojedynczej bazy danych.

Platforma chmurowa ułatwia zespołom wybór optymalnego typu bazy danych dla każdej usługi (relacyjnej, dokumentowej, klucz-wartość, szeregów czasowych itp.), bez narzucania jednej technologii. Kluczem jest to, aby projekt uwzględniał możliwość migracji schematów i struktur bez naruszania umów z innymi usługami, a decyzje dotyczące danych były podejmowane w zgodzie z granicami domeny każdej mikrousługi.

Rozproszone zarządzanie, zespoły i organizacja

Przejście na mikrousługi bez zmiany organizacji to proszenie się o kłopoty. Zamiast klasycznych silosów funkcjonalnych obejmujących sieci, systemy, bazy danych, dział rozwoju i operacje , zaleca się strukturę opartą na zespołach produktowych, łączącą profile specjalistów z działów rozwoju, kontroli jakości, DevOps oraz, w stosownych przypadkach, analityków biznesowych lub danych.

Każdy zespół odpowiada za jedną lub więcej mikrousług w ramach tej samej domeny funkcjonalnej, zajmując się zarówno rozwojem, jak i eksploatacją (tworzysz i uruchamiasz) . Oznacza to, że zespół zarządza procesami CI/CD, współpracuje z infrastrukturą w zakresie konkretnych potrzeb oraz uczestniczy w monitorowaniu i reagowaniu na incydenty. Infrastruktura i platforma chmurowa koncentrują się na świadczeniu wspólnych i ustandaryzowanych usług.

Aby zapobiec przekształceniu się tego rozproszonego zarządzania w anarchię, kluczowe jest zdefiniowanie prostych standardów i współdzielonych katalogów : zatwierdzonych obrazów bazowych, wzorców wdrażania, konwencji nazewnictwa dla przestrzeni nazw i usług, wytycznych dotyczących interfejsu API, szablonów Dockerfile i Kustomize itp. Wytyczne te pełnią funkcję „barier ochronnych”, które orientują zespoły, nie blokując jednocześnie możliwości podejmowania decyzji.

W wielu środowiskach korporacyjnych dla każdego projektu lub domeny używane są oddzielne przestrzenie nazw , z co najmniej jedną na każde środowisko (programistyczne, przedprodukcyjne, produkcyjne). Duży projekt może rozłożyć swoje mikrousługi na kilka przestrzeni nazw, pod warunkiem prawidłowej konfiguracji komunikacji wewnętrznej i przestrzegania zasad bezpieczeństwa.

CI/CD, automatyzacja i model GitOps

Gdy architektura składa się z dziesiątek lub setek mikrousług, jedynym sposobem na utrzymanie ich sprawności jest intensywna inwestycja w kompleksową automatyzację . Obejmuje to spójne potoki CI/CD, deklaratywne definicje wdrożeń, automatyczne testowanie i mechanizmy automatycznego wycofywania zmian.

Typowy proces ciągłej integracji i dostarczania zajmuje się kompilacją kodu, uruchamianiem testów, analizą jakości za pomocą narzędzi takich jak SonarQube , budowaniem obrazu kontenera z korporacyjnego pliku Dockerfile i aktualizacją manifestów wdrożeniowych. Następnie system taki jak ArgoCD lub podobny wdraża zmiany w klastrze, korzystając z podejścia GitOps.

Każde repozytorium mikrousług zazwyczaj zawiera standardowy plik Dockerfile, plik konfiguracji potoku (np. ci.json) , właściwości do analizy jakości oraz katalog wdrożenia z definicjami Kubernetes (Kustomize lub Helm) w podziale na środowiska. Webhooki repozytorium uruchamiają potok w przypadku wystąpienia zdarzeń takich jak wypchnięcie tagów lub żądanie scalenia.

Wzorzec GitOps ustanawia repozytorium Git jako źródło informacji dla infrastruktury i wdrożeń . Manifesty wdrożeń, usług, map konfiguracji, PVC, SealedSecrets i innych zasobów są tam wersjonowane, a określone narzędzia obsługują synchronizację stanu klastra z danymi zdefiniowanymi w Git. Zapewnia to możliwość śledzenia, weryfikację żądań ściągnięcia i łatwe wycofywanie zmian.

Ustawienia, sekrety i bezpieczeństwo

Na dojrzałej platformie mikrousług zarządzanie konfiguracją opiera się na mapach ConfigMap dla parametrów niewrażliwych oraz na mapach Secrets dla informacji poufnych . Każda mikrousługa zazwyczaj ma własną, specyficzną dla środowiska mapę ConfigMap, która przechowuje właściwości takie jak adresy URL usług zależnych, flagi funkcjonalności i parametry dostrajania.

Sekrety (dane uwierzytelniające, klucze, tokeny, certyfikaty) są obsługiwane zgodnie ze ścisłymi zasadami bezpieczeństwa . W środowiskach o mniejszym znaczeniu dopuszczalne może być przechowywanie ich w postaci zwykłego tekstu, zarządzanego przez zespół programistów, ale w środowiskach przedprodukcyjnych i produkcyjnych zaleca się ich szyfrowanie za pomocą narzędzi takich jak Sealed Secrets lub specjalnych zewnętrznych menedżerów w chmurze.

Gdy sekret musi być współdzielony między wieloma usługami (na przykład dane uwierzytelniające OTEL Collector lub wspólny magazyn kluczy ), można go scentralizować w repozytorium konfiguracji dla każdej przestrzeni nazw. Projekty współdzielące tę przestrzeń nazw koordynują jej aktualizację w razie potrzeby, zachowując kontrolę nad tym, kto może odczytywać lub modyfikować te zasoby.

Pod względem bezpieczeństwa komunikacji dominującym wzorcem jest Zero Trust : nic nie jest brane za pewnik tylko dlatego, że ruch jest „wewnętrzny”. Wszystkie połączenia między usługami, zarówno wewnętrznymi, jak i zewnętrznymi, muszą być uwierzytelniane i autoryzowane, najlepiej za pomocą mTLS, tokenów JWT lub innych równoważnych mechanizmów. Mikrousługi nie delegują bezkrytycznie zabezpieczeń do menedżera API ani sieci; przeprowadzają również własne kontrole.

Komunikacja między mikrousługami, interfejsami API i komunikatami

W dojrzałej architekturze mikrousług warstwa komunikacyjna jest podzielona na kilka przypadków. Do obsługi ruchu od klientów (przeglądarek, aplikacji mobilnych, stron trzecich) do zaplecza wykorzystywane są opublikowane interfejsy API zarządzane przez menedżera API . Interfejsy te są zazwyczaj zgodne z interfejsem REST (często z wykorzystaniem OpenAPI) lub, w niektórych przypadkach, udostępniane przez bramę gRPC.

Wywołania między mikrousługami znajdującymi się w tej samej przestrzeni nazw, a nawet w wielu przestrzeniach nazw w ramach tego samego projektu, są zazwyczaj obsługiwane przez wewnętrzne usługi Kubernetes z wewnętrznym serwerem DNS . Wywołania te omijają publicznego menedżera API, ale są zgodne z zasadami bezpieczeństwa, uwierzytelniania i autoryzacji. W takich scenariuszach można użyć siatki usług lub wewnętrznych bram wymuszających wspólne zasady.

Gdy mikrousługi należą do różnych domen funkcjonalnych lub projektów , komunikacja jest uznawana za „publiczną” na poziomie organizacji. W takich przypadkach powszechną praktyką jest korzystanie z Menedżera API lub szyny interoperacyjnej, gdzie zarządzane są kontrakty, limity, zabezpieczenia, wersjonowanie i audyt, co zapobiega bezpośredniemu sprzężeniu między niezależnymi klastrami lub przestrzeniami nazw.

W przypadku integracji ze starszymi lub zewnętrznymi systemami, które nie zawsze udostępniają nowoczesne interfejsy API, często polega się na konkretnych konektorach na magistrali interoperacyjności . W ten sposób mikrousługi posługują się wspólnym językiem (na przykład zdarzeniami lub wewnętrznymi interfejsami API REST), a konektor obsługuje translację między starszymi systemami i do nich, zawsze z zachowaniem zwiększonego bezpieczeństwa.

Oprócz komunikacji synchronicznej, kluczową rolę odgrywa komunikacja asynchroniczna . Służy ona do rozdzielania procesów, absorbowania skoków obciążenia, propagowania zdarzeń biznesowych między usługami i poprawy odporności. Każde zdarzenie ma zazwyczaj dobrze zdefiniowany i wersjonowany schemat, z mechanizmami śledzenia, które zapobiegają awariom między producentami a konsumentami w miarę ich rozwoju.

Obserwowalność, kolektor OTEL i działanie

W systemie składającym się z wielu mikrousług, diagnozowanie problemu bez dobrej obserwowalności jest praktycznie niemożliwe. Dlatego metryki, scentralizowane rejestrowanie i rozproszone ślady są zintegrowane już na etapie projektowania , umożliwiając zrozumienie tego, co dzieje się zarówno na poziomie usługi, jak i platformy.

Centralnym komponentem tego systemu jest OpenTelemetry Collector (OTEL Collector) , który jest wdrażany w przestrzeni nazw lub centralnie w celu gromadzenia metryk, logów i śladów ze wszystkich komponentów. Mikrousługi muszą jedynie wiedzieć, że powinny wysłać swoją telemetrię do Collectora; Collector następnie przekazuje ją do systemów obserwacyjnych (Prometheus, Grafana, Jaeger, Elastic itp.), bez konieczności znajomości szczegółów przez usługę.

W warstwie infrastruktury kolektory i eksportery na poziomie węzłów służą do zbierania metryk procesora, pamięci, dysku, sieci i logów z kontenerów, a następnie wysyłania ich odpowiednio do Prometheusa i Elasticsearch. Narzędzia takie jak Grafana i Kibana służą do wizualizacji tych informacji, tworzenia pulpitów nawigacyjnych i definiowania alertów z inteligentnymi progami i powiązanymi runbookami.

Gdy projekt wymaga bardzo szczegółowego przetwarzania metryk lub śladów, może wdrożyć własną instancję OTEL Collector w swojej przestrzeni nazw, pod warunkiem, że ma ona zatwierdzenie operacyjne, a model utrzymania produkcji jest jasny.

Testowanie strategii, kontraktów i lokalnego doświadczenia rozwojowego

Testowanie rozproszonej architektury mikrousług wymaga bardziej zaawansowanej strategii testowania niż testowanie monolitu. Testy jednostkowe pozostają niezbędne, ale testy kontraktowe (dla interfejsów API i zdarzeń), testy integracyjne między usługami oraz testy kompleksowe obejmujące całe przepływy stają się coraz ważniejsze.

Aby zapobiec problemom ze zgodnością, stosuje się techniki takie jak testowanie kontraktów zorientowane na klienta , gdzie klienci definiują oczekiwania dotyczące API, a dostawcy usług je spełniają. Każda zmiana kontraktu jest automatycznie testowana w ramach procesów CI, co zapobiega wdrożeniom, które zakłócają działanie znanych klientów.

Gdy liczba usług przekroczy sto, lokalna replikacja całego systemu staje się niepraktyczna. Dlatego rozwój opiera się na symulacjach usług zależnych lub tunelowaniu do środowisk zdalnych . Programiści zazwyczaj uruchamiają tylko podzbiór mikrousług, a resztę zastępują mockami, imitacjami lub symulatorami, albo przekierowują niektóre wywołania do współdzielonego środowiska integracyjnego.

Testowanie kompleksowe coraz częściej opiera się na efemerycznych środowiskach lub „wersjach zapoznawczych” tworzonych z gałęzi funkcjonalności , które tworzą odizolowane środowisko z usługami istotnymi dla danej funkcjonalności. Minimalizuje to tarcia między zespołami, zmniejsza efekt „działa na moim komputerze” i wykrywa problemy z integracją, zanim dotrą one do droższych środowisk, takich jak środowisko przedprodukcyjne.

Wzorce wdrażania mikrousług w środowisku produkcyjnym

Oprócz Kubernetesa, istnieje kilka wzorców wdrażania mikrousług w środowisku produkcyjnym, które warto poznać, ponieważ odnoszą się one do różnych scenariuszy izolacji, kosztów i dojrzałości . Jednym z najstarszych wzorców jest wiele instancji usług na hosta, gdzie jeden host fizyczny lub wirtualny uruchamia kilka instancji różnych usług, zazwyczaj na współdzielonym serwerze aplikacji.

W modelu instancji usługi per-VM każda usługa jest pakowana jako obraz maszyny wirtualnej (na przykład EC2 AMI) i działa na własnej instancji. Zapewnia to silną izolację kosztem większego zużycia zasobów i wolniejszego czasu uruchamiania. Narzędzia takie jak Packer lub rozwiązania specyficzne dla dostawców usług chmurowych ułatwiają generowanie gotowych do produkcji obrazów maszyn wirtualnych.

Obecnie najbardziej rozpowszechnionym wzorcem jest instancja usługi na kontener , gdzie każda mikrousługa jest budowana jako obraz kontenera i wdrażana na orkiestratorze (Kubernetes, OpenShift itp.). Kontenery są lżejsze niż maszyny wirtualne, uruchamiają się bardzo szybko i pozwalają spakować wszystko, co jest potrzebne dla usługi, upraszczając wdrożenia i umożliwiając automatyczne skalowanie.

Wreszcie, podejścia bezserwerowe, takie jak AWS Lambda , zyskały na popularności. Funkcje tych pakietów odpowiadają na żądania HTTP lub zdarzenia z innych usług (S3, DynamoDB, kolejki itp.), a użytkownicy płacą tylko za to, z czego korzystają. Ten wzorzec jest szczególnie przydatny w przypadku bardzo małych mikrousług lub zadań sterowanych zdarzeniami o krótkim czasie życia, choć wprowadza dodatkowe zagadnienia dotyczące obserwowalności, zimnych startów i limitów wykonania.

W praktyce wiele organizacji decyduje się na hybrydowy ekosystem: podstawowa część systemu działa w kontenerach i orkiestratorach, natomiast niektóre komponenty pomocnicze są implementowane jako funkcje bezserwerowe lub wyspecjalizowane maszyny wirtualne, zawsze z przejrzystymi interfejsami i dobrze zdefiniowanymi protokołami, aby zintegrować je w całość.

Jeśli chodzi o wdrożenie tego wszystkiego w środowisku produkcyjnym, to nie tylko wybrana technologia robi różnicę, ale zbudowanie architektury odpornej na błędy, skalowalnej w razie potrzeby, wdrażającej się automatycznie i obserwowalnej . Dzięki zespołom zorientowanym na produkty, dobrze zarządzanym kontraktom, zdecentralizowanym danym i solidnej platformie chmurowej, mikrousługi przechodzą od obietnicy do efektywnego i zrównoważonego sposobu na rozwój złożonych aplikacji przez lata.