Nie powinniśmy używać mikroserwisów

My, inżynierowie, posiadamy pewną przypadłość. Nazywa się ona “chęć korzystania z najnowszej technologii, bo wydaje się całkiem spoko, mimo że jest technicznie trudniejsza”. Takie coś spotkało mnie w gabinecie lekarskim. Naprawdę, nie zmyślam! Na recepcie od lekarza dostałem polecenie zajrzenia do podręcznika o architekturze monolitowej, która dostępna jest bez recepty od 2004 roku. A tak na poważnie, to przecież robimy tak cały czas. Za każdym razem, gdy dzieje się coś fajnego, lecimy do tego, jak ćmy do ognia. A jednak częściej się na tym parzymy.

Myślałem, że jestem na to odporny. Wydawało mi się, że wiem lepiej. Kiedy więc zainteresowałem się mikroserwisami, byłem pewien, że działam i myślę racjonalnie. Sprawny deployment. Redundantne, zduplikowane instancje każdej usługi. Kubernetes. Czego tu nie lubić? Na etapie planowania brzmi to świetnie. A potem przychodzi implementacja.

Budowanie mikroserwisów jest generalnie trudniejsze niż budowanie monolitu. Tyle i aż tyle. Dlatego jako zespół musicie zdecydować, jak sobie z tym poradzić. Jeśli nie przeanalizujecie wyboru, możecie napotkać szereg różnych problemów, jak na przykład pełzający zakres, ponieważ implementacja jest zbyt skomplikowana. Albo obniżenie się ducha walki zespołu, jeśli nie ma on doświadczenia w budowaniu architektury rozproszonej i napotyka zbyt wiele przeszkód. Wszystkie te czynniki, a nawet więcej, spadły na mój zespół jak grom z jasnego nieba.

To był nasz pierwszy projekt na średnią skalę. Zaczęło się dość dobrze, dopóki nie doszliśmy do transakcji między usługami. Jako osoba, która musiała sobie poradzić z tym wyzwaniem już kilka razy, mogę śmiało powiedzieć, że dużo łatwiejsze jest zostać obywatelem Stanów Zjednoczonych. Używaliśmy wzorca Saga, opisywanego przez ewangelistów mikroserwisów, takich jak Chris Richardson. Nie będę się w to zagłębiał, ale jest to przede wszystkim sposób reprezentowania zadania, które obejmuje kilka różnych usług. W teorii brzmi ładnie. Dopóki nie zaczniesz nad tym pracować.

Nie chodzi o to, że coś jest nie tak z kodem. Jest to po prostu coś innego niż budowanie monolitu. A mówiąc konkretniej, jest to o wiele trudniejsze do debugowania. Po pierwsze, musisz skonfigurować poprawny stan dla wielu różnych usług przed przetestowaniem czegokolwiek, co napisałeś. Już samo to zajmuje trochę czasu. Zazwyczaj po prostu uruchamiasz nową funkcję z konsoli, w co drugiej linijce. Ale nie w przypadku mikroserwisów. Z testowaniem czegokolwiek, nawet najmniejszej funkcji helpera, wiąże się cały proces konfiguracji. I nie chodzi tylko o to, że jest to trochę inne, ale o to, że realnie zajmuje trochę czasu, nawet gdy jesteś już zaznajomiony z użytkowaniem.

Nie zrozumcie mnie źle, bo jest też wiele plusów takiego rozwiązania. Wyjątkowo cenię sobie kwestię redundancji — uratowała nas już kilka razy. Dodatkowo rozdzielone usługi pomagają we wdrożeniach. W końcu budujemy boty tradingowe. Ciągle trzeba wprowadzać poprawki, udoskonalenia i modyfikacje, dlatego częste wdrożenia są o wiele łatwiejsze, gdy można wdrożyć jedną usługę bez zakłóceń w tych pozostałych. Szczerze mówiąc, widziałem kilka przykładów takiego działania również w krainie monolitów, jednak na tyle, na ile zrozumiałem, to nie jest to takie proste. Chodzi mi o to, że korzyści są oczywiste i warte kosztów, ale nadal uważam, że nie powinniśmy byli wtedy tego robić.

Po prostu nie potrzebowaliśmy tego aż tak bardzo. Bardziej potrzebny był nam czas, który straciliśmy na budowanie własnej implementacji brokera wiadomości z wykorzystaniem strumieni Redisa. Jaki jest morał tej historii: jeśli zadajesz sobie to pytanie, czy powinieneś używać mikroserwisów, to prawdopodobnie nie powinieneś. Aby zrobić to dobrze, potrzebujesz umiejętności, czasu i przemyślanego projektu. Upewnij się, że korzyści są warte tych poświęceń. Poza tym nie przejmuj się, jeśli używasz nudnej, starej technologii. Koniec końców, ważniejsze jest posiadanie działającego, nudnego kodu niż nieudanego i modnego.

Oryginał tekstu w języku angielskim przeczytasz tutaj.