Porównanie mikrousług z architekturą monolityczną

Dla organizacji korzystne może okazać się użycie architektury monolitycznej bądź mikrousług, w zależności od wielu różnych czynników. W przypadku architektury monolitycznej podstawową zaletą jest szybkość tworzenia aplikacji ze względu na prostotę wynikającą z posiadania aplikacji opartej na jednej bazie kodu.

Zalety architektury monolitycznej to między innymi:

Łatwe wdrażanie — jeden plik wykonywalny lub katalog ułatwia wdrażanie.

Programowanie — programowanie jest prostsze w przypadku aplikacji zbudowanej z wykorzystaniem pojedynczej bazy kodu.

Wydajność — w scentralizowanej bazie kodu i repozytorium pojedynczy interfejs API może często wykonywać tę samą funkcję, którą wykonuje wiele interfejsów API w przypadku mikrousług.

Uproszczone testowanie — ze względu na to, że aplikacja monolityczna jest pojedynczą, scentralizowaną jednostką, kompleksowe testowanie może być przeprowadzane szybciej niż w przypadku aplikacji rozproszonej.

Łatwe debugowanie — dzięki temu, że cały kod znajduje się w jednym miejscu, łatwiej jest śledzić żądanie i znaleźć problem.

Podobnie jak w przypadku firmy Netflix aplikacje monolityczne mogą być całkiem skuteczne, dopóki nie staną się zbyt duże i ich skalowanie nie stanie się problemem. Wprowadzenie niewielkiej zmiany w pojedynczej funkcji wymaga skompilowania i przetestowania całej platformy, co jest sprzeczne z podejściem Agile, które preferują współcześni programiści.

Wady architektury monolitycznej to między innymi:

Wolniejsze tempo prac programistycznych — duża, monolityczna aplikacja sprawia, że programowanie jest bardziej skomplikowane i wolniejsze.

Skalowalność — nie ma możliwości skalowania poszczególnych komponentów.

Niezawodność — wystąpienie błędu w dowolnym module może wpłynąć na dostępność całej aplikacji.

Utrudnione wdrażanie technologii — wszelkie zmiany we frameworku lub języku wpływają na całą aplikację, co powoduje, że są one często kosztowne i czasochłonne.

Brak elastyczności — architektura monolityczna jest ograniczona przez już stosowane w niej technologie.

Wdrażanie — niewielka zmiana w aplikacji monolitycznej wymaga ponownego wdrożenia całej architektury monolitycznej.

Architektura mikrousług, zwana również po prostu mikrousługami, jest metodą architektoniczną opartą na szeregu niezależnie wdrażanych usług. Te usługi mają własną logikę biznesową i bazę danych o określonym przeznaczeniu. Aktualizowanie, testowanie, wdrażanie i skalowanie odbywa się w ramach każdej usługi. Mikrousługi umożliwiają rozdzielenie głównych aspektów biznesowych, specyficznych dla danej dziedziny, na osobne, niezależne bazy kodu. Mikrousługi nie zmniejszają złożoności, ale czynią ją widoczną i łatwiejszą do zarządzania poprzez podział zadań na mniejsze procesy, które działają niezależnie od siebie i stanowią część całości.

Wdrożenie mikrousług często wiąże się z wykorzystaniem metodologii DevOps, ponieważ jest ona podstawą praktyk ciągłego dostarczania, które pozwalają zespołom szybko dostosowywać się do wymagań użytkowników.

Atlassian wkroczył na ścieżkę mikrousług w 2018 roku po tym, jak stanęliśmy przed wyzwaniami związanymi z rozwojem i skalowaniem Jira i Confluence. Doszliśmy do wniosku, że naszych działających lokalnie monolitycznych architektur z pojedynczą dzierżawą nie będzie można skalować w celu w dostosowania do przyszłych potrzeb.

Zdecydowaliśmy się na zmianę architektury Jira i Confluence oraz migrację ze stanowego monolitycznego systemu z pojedynczą dzierżawą do wielodostępnych, bezstanowych aplikacji chmurowych hostowanych przez Amazon Web Services (AWS). Następnie z czasem podzieliliśmy je na mikrousługi. Projekt został nazwany Vertigo (z ang. zawrót głowy), po tym jak jeden ze starszych inżynierów powiedział: „Podoba mi się ten pomysł, ale przyprawia mnie o zawrót głowy”. Był to nasz największy dotychczasowy projekt w zakresie infrastruktury — przejście na AWS zajęło nam dwa lata, a migracja ponad 100 tys. klientów odbyła się w ciągu nieco ponad 10 miesięcy bez przerw w świadczeniu usług. Zaangażowaliśmy się również w podział usług na mikrousługi.

Mikrousługi nie są w żadnym wypadku magicznym panaceum, ale rozwiązują wiele problemów w przypadku rozrastającego się oprogramowania i firm. Ponieważ architektura mikrousług składa się z jednostek, które działają niezależnie, każdą usługę można rozwijać, aktualizować, wdrażać i skalować bez wpływu na inne usługi. Aktualizacje oprogramowania można przeprowadzać częściej, co zwiększa niezawodność, czas nieprzerwanej pracy i wydajność. Przeszliśmy od wprowadzania aktualizacji raz w tygodniu do dwóch, trzech razy dziennie.

W miarę rozwoju Atlassian mikrousługi umożliwiają nam bardziej niezawodne skalowanie zespołów i lokalizacji geograficznych dzięki podziałowi według granic własności usług. Zanim rozpoczęliśmy projekt Vertigo, Atlassian miał pięć różnych centrów programistycznych na całym świecie. Praca tych rozproszonych zespołów była ograniczana przez scentralizowaną strukturę monolityczną, a my musieliśmy wspierać je w sposób autonomiczny. Mikrousługi nam to umożliwiają.

Do zalet Vertigo należy większa szybkość wdrażania, odzyskiwanie awaryjne, niższe koszty i wyższa wydajność. Dzięki temu możemy szybciej osiągnąć cel, a po drodze dostarczać klientom większe korzyści w sposób przyrostowy.

Ponadto, w bardziej ogólnym wymiarze, mikrousługi ułatwiają zespołom aktualizowanie kodu i przyspieszają cykle wydawania dzięki ciągłej integracji i ciągłemu dostarczaniu (CI/CD). Zespoły mogą eksperymentować z kodem i wycofać go, jeśli coś pójdzie nie tak.

Krótko mówiąc, zalety mikrousług są następujące:

Zwinność — wspieranie sposobów pracy opartych na metodyce Agile, z małymi zespołami, które przeprowadzają częste wdrożenia.

Elastyczne skalowanie — jeśli obciążenie danej mikrousługi osiągnie maksymalny poziom, można szybko wdrożyć nowe instancje tej usługi do powiązanego klastra, aby ułatwić obsługę zwiększonego zapotrzebowania. Nasz system bazuje obecnie na wielodzierżawie i jest bezstanowy, a nasi klienci są rozproszeni w wielu instancjach. Jesteśmy w stanie obsługiwać instancje o znacznie większych rozmiarach.

Ciągłe wdrażanie — stosujemy obecnie częste i szybsze cykle wydawania. Wcześniej aktualizacje były wprowadzane raz w tygodniu, a teraz możemy to robić dwa lub trzy razy dziennie.

Duże możliwości utrzymania i testowania — zespoły mogą eksperymentować z nowymi funkcjami i wycofywać je, jeśli coś pójdzie nie tak. Ułatwia to aktualizację kodu i przyspiesza wprowadzanie nowych funkcji na rynek. Ponadto można w prosty sposób wyodrębniać i usuwać błędy i usterki w poszczególnych usługach.

Możliwość niezależnego wdrażania — ponieważ mikrousługi są indywidualnymi jednostkami, umożliwiają szybkie i łatwe niezależne wdrażanie poszczególnych funkcji.

Elastyczność pod względem technologii — architektura mikrousług zapewnia zespołom swobodę wyboru narzędzi, które preferują.

Wysoka niezawodność — można wdrażać zmiany w konkretnej usłudze bez ryzyka przerw w działaniu całej aplikacji.

Bardziej zadowolone zespoły — zespoły Atlassian, które pracują z mikrousługami, są o wiele bardziej zadowolone, ponieważ mają większą autonomię i mogą samodzielnie kompilować i wdrażać funkcje, nie czekając tygodniami na zatwierdzenie pull requestu.

Po przejściu od niewielkiej liczby monolitycznych baz kodu do znacznie większej liczby rozproszonych systemów i usług wspierających nasze produkty powstała niepożądana złożoność. Początkowo mieliśmy trudności z dodawaniem nowych funkcji w takim tempie i z taką samą pewnością jak wcześniej. Mikrousługi mogą zwiększać złożoność, co prowadzi do szybkiego i niekontrolowanego rozwoju systemu. Trudno jest określić, jak poszczególne komponenty są ze sobą powiązane, kto jest właścicielem danego komponentu oprogramowania lub jak uniknąć zakłócenia działania zależnych komponentów.

Dzięki Vertigo opracowaliśmy wspólną funkcję, wspierającą nasze istniejące i przyszłe produkty, które pozyskujemy i tworzymy. Jeśli Twoja firma oferuje jeden produkt, stosowanie mikrousług może nie być konieczne.

Wady mikrousług to między innymi:

Niekontrolowany rozwój — mikrousługi oznaczają większą złożoność w porównaniu z architekturą monolityczną, ponieważ istnieje więcej usług w większej liczbie miejsc, tworzonych przez wiele zespołów. Brak odpowiedniego zarządzania niekontrolowanym rozwojem skutkuje wolniejszym tempem prac programistycznych i gorszą wydajnością operacyjną.

Wykładniczy wzrost kosztów infrastruktury — każda nowa mikrousługa może generować swój własny koszt związany z zestawem testów, podręcznikami wdrażania, infrastrukturą hostingową, narzędziami do monitorowania i nie tylko.

Zwiększone obciążenie organizacyjne — aby koordynować aktualizacje i interfejsy, zespoły muszą wprowadzić kolejny poziom komunikacji i współpracy.

Wyzwania związane z debugowaniem — każda mikrousługa ma swój własny zestaw dzienników, co utrudnia debugowanie. Ponadto jeden proces biznesowy może działać na wielu komputerach, co rodzi dodatkowe komplikacje.

Brak standaryzacji — brak wspólnej platformy może spowodować mnożenie się języków, standardów rejestrowania i funkcji monitorowania.

Brak jasno określonej własności — wprowadzanie kolejnych usług sprawia, że rośnie liczba zespołów obsługujących te usługi. Z czasem trudno jest zorientować się, które usługi zespół może wykorzystać i do kogo należy zwrócić się o pomoc.

Wiele projektów jest rozpoczynanych jako architektura monolityczna, aby z czasem przekształcić się w architekturę mikrousług. W miarę dodawania nowych funkcji do systemu monolitycznego może się okazać, że praca wielu programistów nad pojedynczą bazą kodu staje się uciążliwa. Konflikty kodu stają się coraz częstsze i rośnie ryzyko, że aktualizacje jednej funkcji spowodują pojawienie się błędów w innej, niepowiązanej funkcji. Gdy pojawiają się te niepożądane zjawiska, może to być czas, aby rozważyć migrację do mikrousług.

Oto niektóre z najlepszych praktyk, których nauczyliśmy się podczas naszej migracji:

W styczniu 2016 roku mieliśmy łącznie około 15 mikrousług. Teraz mamy ich ponad 1300. Przenieśliśmy 100 tys. klientów do chmury, zbudowaliśmy przy okazji nową platformę, przekształciliśmy naszą kulturę organizacyjną i zyskaliśmy nowe narzędzia. Mamy bardziej zadowolone, autonomiczne zespoły i lepszą kulturę DevOps.

Mikrousługi nie są rozwiązaniem dla każdego. Istniejąca architektura monolityczna może działać znakomicie, a jej przebudowa może nie być warta zachodu. Jednak wraz z rozwojem organizacji i wzrostem wymagań stawianych aplikacjom architektura mikrousług może okazać się warta rozważenia.

Ponieważ w wielu organizacjach coraz częściej pojawiają się mikrousługi z architekturą rozproszoną, Atlassian opracował Compass, aby pomóc firmom w zarządzaniu złożonością architektur rozproszonych w miarę ich skalowania. Jest to rozszerzalna platforma środowiska programistycznego, która w centralnej lokalizacji z możliwością wyszukiwania łączy wszystkie niepowiązane informacje o wynikach prac inżynierskich i współpracy zespołowej.