Wygląda na to, że szczyt popularności mikrousług minął. Już nie czytamy kilka razy w tygodniu postów „Jak przeniosłem mój monolit na 150 usług”. Teraz częściej słyszę rozsądne myśli: „Nie nienawidzę monolitu, po prostu dbam o efektywność”. Nawet zaobserwowaliśmy kilka migracji . Przechodząc z jednej dużej aplikacji na kilka mniejszych usług, będziesz musiał stawić czoła kilku nowym problemom. Wypunktujmy je jak najkrócej.
Ustawienie: od chemii podstawowej do mechaniki kwantowej
Konfiguracja podstawowej bazy danych i aplikacji z procesem w tle była dość klarownym procesem. Publikuję readme na Githubie — i często po godzinie, najwyżej dwóch, wszystko działa, a ja zaczynam nowy projekt. Dodawanie i uruchamianie kodu, przynajmniej w początkowym środowisku, odbywa się w pierwszym dniu. Ale jeśli odważymy się na mikrousługi, czas początkowego uruchamiania wzrasta w nieskończoność. Tak, mamy teraz Dockera z orkiestracją i klastry maszyn K8, ale dla początkującego programisty to wszystko jest znacznie bardziej skomplikowane. Dla wielu juniorów to brzemię, które w rzeczywistości jest niepotrzebnym skomplikowaniem.
System jest trudny do zrozumienia
Na chwilę zatrzymajmy się na naszym juniorze. W przypadku aplikacji monolitycznych, gdy występuje błąd, łatwo było go zlokalizować i natychmiast przystąpić do debugowania. Teraz mamy usługę, która rozmawia z inną usługą, która umieszcza coś w kolejce na szynie komunikatów, która przetwarza inną usługę — i tu pojawia się błąd. Musimy zebrać wszystkie te elementy, aby ostatecznie odkryć, że usługa A działa w wersji 11, a usługa E już oczekuje wersji 12. To bardzo różni się od mojego standardowego skonsolidowanego dziennika: muszę użyć interaktywnego terminala/debuggera, aby przejść przez proces krok po kroku. Debugowanie i zrozumienie stało się zasadniczo trudniejsze.
Jeśli nie można zdebugować, być może przetestujemy je
Ciągła integracja i ciągłe dostarczanie stają się obecnie powszechne. Większość nowych aplikacji, które widzę, automatycznie wykonuje kompilację i uruchamia testy z każdym nowym wydaniem, wymagając, aby testy przechodziły i były przeglądane przed rejestracją. To świetne procesy, z których nie można rezygnować, stanowią one dużą zmianę dla wielu firm. Ale teraz, aby naprawdę przetestować usługę, muszę uruchomić pełną wersję roboczą mojej aplikacji. Pamiętacie tego nowego inżyniera z klastrem K8 z 150 usługami? Cóż, teraz nauczymy nasz system CI, jak uruchomić wszystkie te systemy, aby sprawdzić, czy wszystko rzeczywiście działa. Prawdopodobnie to zbyt wiele wysiłku, więc po prostu przetestujemy każdą część w izolacji: jestem pewien, że nasze specyfikacje są wystarczająco dobre, API są czyste, a awaria usługi jest izolowana i nie wpłynie na inne.
Każdy kompromis ma uzasadnioną przyczynę. Prawda?
Jest wiele powodów do przejścia na mikroserwisy. Widziałem, że robią to w celu większej elastyczności, do skalowania zespołów, dla wydajności, aby zapewnić lepszą odporność na awarie. Ale w rzeczywistości zainwestowaliśmy dziesięciolecia w narzędzia i praktyki tworzenia monolitów, które wciąż się rozwijają. Pracuję z profesjonalistami w różnych technologiach. Zwykle rozmawiamy o skalowaniu, ponieważ napotykają ograniczenia jednego węzła bazy danych Postgres. Większość rozmów dotyczy .
Ale zawsze jestem ciekawy ich architektury. Na jakim etapie przejścia na mikroserwisy się znajdują? Ciekawie jest obserwować, jak coraz więcej inżynierów mówi, że są zadowoleni ze swojej monolitycznej aplikacji. Wiele osób odniesie korzyści z mikroserwisów, a zyski przeważą nad przeszkodami na drodze migracji. Ale osobiście, dajcie mi proszę moją monolityczną aplikację, miejsce na plaży - i jestem całkowicie szczęśliwy.
Źródło: habr.com
