Dlaczego architektura mikroserwisów zyskała na popularności w ostatnich latach?
Są różne opinie. Jedni są zdania, że trzeba było o czymś opowiadać na konferencjach :).
Drudzy z kolei twierdzą, że to konteneryzacja oraz w dużej mierze Docker pozwoliły na ekspansję mikroserwisów.
Intro
Zaczynasz projekt i masz do skonfigurowania standardowo 3 środowiska. Dev, Staging, Prod. Czy wyobrażasz sobie deployment aplikacji złożonej z 10 mikroserwisów bez kontenerów? Owszem – teraz mamy chmurę i jej usługi pozwalające wdrożyć aplikację, bez martwienia się o infrastrukturę.
Niestety, ale z doświadczenia wiem, że chmura nie nadaje się do wszystkiego. W niektórych firmach, istnieją pewne regulacje o przechowywaniu danych. Dane mają być przechowywane na serwerach firmy. Koniec kropka. A jeśli jest to korporacja – nie ponegocjujesz.
Ktoś powie – trzymaj dane on-premise, a hostuj mikroserwisy w chmurze. Owszem, czasami takie rozwiązania się sprawdzają. Osobiście jestem fanem dobierania narzędzi do problemu, a nie odwrotnie. W związku z tym nie neguję żadnego podejścia.
Czym są mikroserwisy?
Tworzenie aplikacji mikroserwisowych jest sztuką. Tak – sztuką. To sztuka budowania „dużych” systemów oraz łamania zasad towarzyszących nam przez ostatnie dekady – zasad monolitu.
Architektura mikroserwisowa wprowadza inne podejście do tworzenia modułów systemu. Polega to na wydzielaniu logicznych grup, które mają odzwierciedlenie w procesach biznesowych. Idealnym określeniem, które ciężko mi przetłumaczyć na język polski, jest business capability.
Przekładając to na język techniczny, mikroserwisy powinny byc projektowane tak, że jeżeli zmieni się logika biznesowa dla danego business capability to zmiana w pojedynczym mikroserwisie nie wymusza zmiany w drugim. Jest to mocno związane z pojęciem bounded context, pochodzącym z książki Erica Evansa – Domain Driven Design.
Wdrożenia nowych wersji stają się mniej bolesne, ponieważ wdrażamy tylko tę mikrousługę, w której nastąpiła zmiana w kodzie.
Przykład Netflixa
Na pewno wiesz co to Netflix. A czy zastanawiałeś się kiedykolwiek, jak to działa, że Netflixa oglądają miliony ludzi na całym świecie, a mimo to nie ma problemów z oglądnięciem ulubionego serialu wieczorem w godzinach szczytu?
Netflix chętnie dzieli się wiedza w temacie swojej architektury. W sieci można znaleźć wiele ciekawych artykułów na ten temat. Na przełomie roku 2008/2009, Netflix jako jeden z pierwszych na świecie zaczął korzystać z mikroserwisów. Było to spowodowane rosnącą liczbą klientów oraz problemami z wydajnością dotychczasowej aplikacji monolitycznej.
W 2009 roku mało kto słyszał o mikroserwisach a rozwiązania chmurowe nie były jeszcze tak popularne jak teraz. Netflix był pierwszym, który złamał bariery zamieniając architekturę monolitu na architekturę mikroserwisową, równocześnie porzucąjąc własne serwery i przenosząc się do chmury AWS.
Oczywiście w tym czasie, nie było jeszcze Dockera i takiego bumu na kontenery. Dopiero z czasem Netflix zaczął korzystać z benefitów wynikających z konteneryzacji.
Obecnie całość aplikacji składa się z 500+ (brzmi zabawnie? :D) skonteneryzowanych mikroserwisów. Warto jednak podkreślić, że przez lata Netflix pracował nad swoim „idealnym” środowiskiem. Stworzył nawet narzędzie Chaos Monkey, które losowo ubija mikroserwisy na produkcji (!), po to by mieć pewność, że są przygotowani na awarię i posiadają dobry recovery plan.
Wyzwania w budowaniu aplikacji mikroserwisowych
Monitoring
Monitorowanie mikroserwisów rozproszonych na wielu hostach może być trudne. Zamiast śledzenia jednej aplikacji, musimy monitorować ich kilka (naście, dziesiąt), jednocześnie skupiając się na poprawnym działaniu całego systemu.
Wydajność infrastruktury
Każdy mikroserwis zużywa znacznie mniej zasobów niż aplikacje monolityczne, ale pamiętaj, że liczba mikroserwisów może rosnąć wraz z rozwojem systemu. Bez odpowiedniego zarządzania, wiele pojedynczych hostów może zużywać tyle mocy obliczeniowej i pamięci, albo i więcej, niż architektura monolityczna.
Nieefektywne zużywanie zasobów
Weźmy jako przykład Amazon Web Services, w którym istnieje dolny limit zasobów, które możesz przypisać do danego zadania. Mikroserwisy mogą być tak małe, że wystarczy im zdecydowanie mniej mocy obliczeniowej niż minimalna opcja EC2 (Amazon Elastic Compute Cloud). Może to powodować marnowanie zasobów i generowanie niepotrzebnych kosztów.
Bardziej skomplikowany deployment
Podstawową zaletą mikroserwisów jest niezależność co do technologii, w których są tworzone. Każdy język programowania jest jednak zależny od własnych bibliotek i frameworków. Powstaje zatem problem utrzymywania wersji bibliotek dla różnych technologii. Zwiększa to zdecydowanie nakłady pracy (i koszty) oraz sprawia, że wdrożenia są skomplikowane.
I właśnie tutaj, z pomocą przychodzą kontenery oraz Docker.
Docker na pomoc
W przeciwieństwie do maszyn wirtualnych, dzięki Dockerowi nie musimy stale konfigurować systemu w nadziei na uniknięcie konfliktów wersji bibliotek czy frameworków. Docker rozwiązuje ten problem, jednocześnie gwarantując nam, że wszystkie mikroserwisy będą działać niezależnie od siebie a zarazem będą niezależne od systemu operacyjnego.
Izolacja
Tworząc pojedynczy kontener dla każdego z mikroserwisów, możesz uruchomić wiele z nich jednocześnie na pojedynczym hoście.
Sprawniejszy i wspólny model wdrażania
Chcąc uruchomić projekt oparty o architekturę mikroserwisową lokalnie na twoim laptopie, nie musisz konfigurować całego środowiska, instalować bibliotek czy zależności. Możesz skorzystać z Docker image, dokładnie tego samego, który działa na produkcji.
Wspieranie różnych technologii programowania
SoftwareHouse’y często posiadają zespoły pracujące w różnych technologiach. Dzięki konteneryzacji, są w stanie pracować nad pojedynczym komponentem aplikacji niezależnie od technologii czy języków programowania
Optymalizacja zużycia mocy obliczeniowej
Zamiast sztywnego przypisywania zasobów sprzętowych per mikroserwis, wiele pojedynczych mikroserwisów zapakowanych w kontenery, może być uruchomiona na pojedynczym hoście współdzieląc moc obliczeniową (CPU, pamięć).
Skalowalność
Może nie tworzymy systemów na miarę Netflixa (chciałbym :D), ale obecne wymagania biznesowe sprawiają, że możemy potrzebować skalowania. Z pomocą przychodzą narzędzia do orchestracji, zaczynając od najprostszego orchestratora – Docker Compose poprzez Docker Swarm i Kubernetes.
Skąd czerpać wiedzę o mikroserwisach?
Dla osób chcących zgłębić swoją wiedzę w temacie mikroserwisów w oparciu o technologię .NET jest znakomita okazja!
UWAGA: Z kodem rabatowym SZKOLADOCKERA, otrzymasz 10% zniżki na zakup!
Więcej informacji o kursie znajdziesz TUTAJ
Mikroserwisy.NET to kompleksowy kurs online wprowadzający w świat nowoczesnej architektury mikroserwisów z wykorzystaniem metodyki Event Storming oraz najpopularniejszych technologii takich jak: .NET Core, Docker, Kubernetes, Istio Service Mesh i wiele innych!
Podsumowanie
Chyba nikt nie odważy się zaprzeczyć, że Docker mocno przyczynił się do rozwoju i popularności mikroserwisów. Pomimo, że wcześniej istniały narzędzia do konteneryzacji – mało kto o nich wiedział, a jeszcze mniej osób z tego korzystała.
Należy jednak podkreślić fakt, że pojęcie mikroserwisy nie równa się kontenerom. Oczywiście mikroserwisy i kontenery bardzo dobrze ze sobą się łączą. Warto pamiętać, że mikroserwisy są zdecydowanie czymś więcej. Decydując się na taka architekurę, musisz mieć świadomość trudności jakie cię czekają i przygotować się na najgorsze. Mam tutaj na myśli dobry recovery plan, dla każdego klocka twojej architektury.
