Czy monolity to architektura przyszłości?
Teslę spotkała spora krytyka za funkcję autopilota (sam go używam i uważam, że powinni zmienić nazwę tej funkcji). Zdarzyło się sporo wypadków spowodowanych zaśnięciem kierowcy. Czy to wina autopilota? Każdy kierowca powinien wiedzieć, że nie drzemie się na autostradzie. Czy zatem usuwamy z samochodów funkcję autopilota? Czy może uczymy się go właściwie używać?
Podobną sytuację mamy przy architekturze oprogramowania. Ludzie łapią się buzzwordów i nowych “świetnych” pomysłów, które mają naprawić wszystko. Ostatnio modne było wykorzystanie mikroserwisów i rozbijanie monolitów. Słuchałem świetnego podcastu na ten temat, polecam się z nim zapoznać.
Mój współpracownik podzielił się ze mną tym podcastem. Myślę, że poruszonych jest tam kilka bardzo interesujących i ważnych problemów. Przeanalizuję je tutaj.
Dlaczego monolity są przyszłością?
Dlaczego niektórzy rzeczywiście myślą, że wrócimy do aplikacji monolitycznych?
Monolity to przyszłość, ponieważ problem, który ludzie próbują rozwiązać mikroserwisami, ma się nijak do rzeczywistości.
— KELSEY HIGHTOWER
W stu procentach się z tym zgadzam. Słowo „mikroserwis” traktowane jest dziś jak magiczna pigułka, która naprawia wszystko - od dysfunkcyjnej organizacji po źle zaprojektowany system. Nie sądzę jednak, aby alternatywą dla mikroserwisów był powrót do monolitu.
Mamy do czynienia z paradygmatem “oczekiwania kontra rzeczywistość”. Można by to streścić w kilku punktach:
- Brak planowania, jeśli chodzi o layout serwisu
- Brak doświadczenia z architekturami rozproszonymi
- Brak czasu na testy i implementację
Rozproszony monolit
Pewnie nie znajdziesz tego w książce “Head First Design Patterns”.
Masz naprawdę słaby kod i mówisz „Wiesz, co powinniśmy zrobić? Powinniśmy zaorać ten temat. Pozbądźmy się tego problemu i zatrudnijmy takich programistów, jakich jeszcze u nas nie było”. I to, co finalnie zrobią, to 50 rzeczy, które trzeba zdeployować, ale tak naprawdę to rozproszony monolit
— KELSEY HIGHTOWER
Takie zachowanie jest niestety bardzo powszechne. Tak jak w tym przypadku, gdy ludzie zaczynają wierzyć w to, że tworzenie małych elementów jest szybsze, a przez to lepsze. Mikroserwisy nie naprawią problemów złego monolitu. Jeśli zrobisz złą lasagne, nie ma znaczenia, na ile kawałków ją pokroisz - nadal nie będzie dobra.
Czy masz u siebie rozproszony monolit?
rubyn00bie w swoim tekście na Hacker News opisał, jak to “zdiagnozować”:
1) Duplikujesz tabele (informacje) bez przekształcania danych w coś nowego (dodawanie informacji), w innej bazie danych…
2) Usługa X nie działa bez Y lub Z i/lub nie masz strategii radzenia sobie, gdy jedna z nich przestanie działać.
2.5) Bonusowy podpunkt - prawdopodobnie nie masz możliwości znaczącego oddzielenia od siebie różnych usług. Usługa X może „tolerować” awarię usługi Y, ale nie może nigdy funkcjonować bez niej.
3) Przesyłasz wszystkie swoje dane przez szynę zdarzeń, aby Twoje usługi były „zsynchronizowane”…
rubyn00bie trafia w sedno. Wszystkie te punkty należy wziąć pod uwagę na etapie projektowania. Usługi współzależne muszą:
1) być połączone w mikrousługę
2) używać wzorca kolejki, aby zapewnić to, że usługa będzie mogła przetwarzać element (jeśli takowy jest dostępny)
3) oba systemy mogą znajdować się za mikro-orkiestratorem w celu obsługi błędów.
Szyny zdarzeń są ważną częścią infrastruktury mikroserwisów. Uważam jednak, że należy je ograniczyć do samych powiadomień, bez opcji synchronizacji danych.
Jeśli przejdziesz z monolitu do mikroserwisów, musisz to wykorzystać jako okazję do reewaluacji oraz aktualizacji. Jeśli jesteś na tym etapie swoich wyborów, to jest szansa, że mówisz o systemie, który istnieje już od jakiegoś czasu. Nie możesz traktować tego jako ćwiczenia z kodowania typu „wytnij i wklej” - musisz wrócić do kroku pierwszego.
Prawidłowe rozdzielenie monolitu
Jak przetrwać ten etap bez załamania psychicznego lub poddania się?
Zaplanuj to idealnie
Musisz mieć dużą wiedzę o monolicie. Być może czeka Cię zrobienie dokładnego researchu i zrozumienia aspektów, których jeszcze nie znasz. Musisz myśleć o monolicie jak o grupie niezależnych podsystemów, a nie jak o jednym dużym systemie składającym się z mniejszych części.
Może wydawać się to mało ważne, ale sposób, w jaki na to patrzysz, ma ogromny wpływ. Twój punkt widzenia będzie determinował wszystkie Twoje decyzje.
Implementuj z właściwym punktem widzenia
Załóżmy, że mamy monolityczną aplikację, która jest platformą e-commerce. Zdecydowałeś się rozdzielić monolit. Masz takie opcje:
- Mniejsze = lepsze - znajdź logiczne punkty podziału aplikacji i użyj ich do tworzenia mniejszych aplikacji, które są wewnątrz silnie powiązane. Robisz deploy i jesteś mistrzem mikroserwisów!
- Mniejsze = sprawniejsze - poświęć trochę czasu na odkrycie podstawowych możliwości monolitu. O każdej z tych możliwości pomyśl jak o oddzielnej aplikacji obsługującej coś od początku do końca, która może żyć samodzielnie, bez wpięcia w cały ekosystem. Spróbuj rozszerzyć zdolności tej aplikacji do obsługi większej liczby przypadków użycia, najlepiej w formie bezstanowej.
W naszym przykładzie aplikacji e-commerce możemy podzielić całość na wiele mniejszych części: koszyk, produkt, zamówienie itp. Przy obydwu wyżej wymienionych opcjach możemy wybrać te same punkty podziału, ale to, co zbudujemy, będzie się od siebie różniło w każdym z przypadków. Przy pierwszej opcji rozdzielilibyśmy usługi, ale istniałoby między nimi ścisłe powiązanie. Przy drugim scenariuszu staralibyśmy się stworzyć pełny zestaw funkcji dla każdej z usług.
Zadaj sobie to pytanie za każdym razem, gdy będziesz tworzył mikroserwisy:
Czy mogę umieścić te mikroserwisy w innej architekturze bez wprowadzania w niej zmian i w pełni wykorzystywać wszystkie jej możliwości?
Jeśli Twoja odpowiedź brzmi tak, to zaczynasz z właściwym punktem widzenia. Jeśli nie, to znaczy, że coś tu nie styka i musisz zacząć od nowa.
Doprowadź do rozproszenia bez rozwalenia
Czy uważam, że powinniśmy wrócić do monolitów? Nie.
Wiele rzeczy można porównać do mikroserwisów, np. Twój samochód. Składa się on z wielu mniejszych części. Niektóre z jego komponentów, jak np. felgi, będą pasować również do samochodów innych niż Twój (jako w pełni niezależny mikroserwis). Inne komponenty, takie jak przednia szyba, są specyficzne dla Twojej marki i modelu (jak komponenty mikrousług, które są współzależne).
Istnieje cienka granica, która wymaga dobrego planu, aby wszystko odpowiednio zaimplementować. Każda dobra architektura, nigdy nie jest “zamrożona” i będzie ewoluować z czasem.
W momencie klikania “Zapisz” na diagramie architektury, jest ona już nieaktualna - dobry architekt systemów
Właściwe zastosowanie mikroserwisów zaczyna się od zdania sobie sprawy, że wprowadzasz zmianę, ponieważ chcesz lub musisz. Zastanów się, czemu pojawiła się potrzeba zmiany, jaki jest jej powód i zadbaj by nie powtórzyć tego samego błędu w nowej architekturze.
Podsumowanie
- Mikroserwisy to nie tylko zmniejszanie rozmiaru architektury.
- Sukces implementacji będzie zależał od tego, jak dobrze wszystko zaplanujesz.
- Możesz znaleźć masę dobrych wzorców projektowych i informacji na ich temat online.
- Wykorzystaj przejście na inną architekturę jako okazję do ponownego zdefiniowania usług i ich zaktualizowania.
- Zastanów się jeszcze raz nad technologią, zarówno przechowywania danych, jak i samej aplikacji.
Oryginał tekstu w języku angielskim przeczytasz tutaj.