Cała prawda o planecie… mikroserwisy

Data: 2021-05-20
Autor: Sebastian Konkol
Cała prawda o planecie… mikroserwisy

Rok 2021 co prawda należy do Stanisława Lema, ale Janusz Zajdel też daje radę, if You know, what I mean. Lektura dzieł obu Panów zawsze wywoływała we mnie refleksje o naturze człowieka oraz o powiązaniach filozofii i technologii. Ostatnimi czasy – po części z powodu wątków chmurowych – filozofia i technologia splatały mi się w obszarze architektury mikroserwisów. No właśnie, ale czy to na pewno mikroserwisy? A może bardziej mikreserwisy?

Oj, nazbierało się ostatnio trochę z różnych projektów, w których mikroserwisy, cóż, po prostu były. Nie mam ambicji napisać traktatu o poprawności stosowania mikroserwisów – raczej chcę podzielić się kilkoma myślami z tego właśnie obszaru moich doświadczeń.

Teoria architektury mikroserwisów jest znana. Mikroserwisy to architektura wewnętrzna aplikacji, takiej organizacji jej struktury, która pozwala na niezależne budowanie składowych tej aplikacji przez niezależne zespoły, w niezależnie wybranych technologiach, a nawet na własnych zasadach obowiązujących każdy z zespołów. Celem nie jest reużycie (to jest SOA), a standaryzacja i unifikacja są zaprzeczeniem mikroserwisów. Jeśli więc ktoś myśli, że „wejście w mikroserwisy” obniży koszty, to obawiam się, że bardzo mi przykro. Czy skróci time-to-market? Cóż, w naprawdę dojrzałych organizacjach udaje się to czasami osiągnąć.

W praktyce, prawie nigdy nie ma „definicyjnych” mikroserwisów – niezależnych od siebie, z własnymi bazami danych. W praktyce bowiem większość firm opiera się na takich czy innych systemach zintegrowanych (np. ERP, CRM, PIM, billing, core banking, MES). Najczęściej obserwowanym celem „robienia mikroserwisów” bardzo szybko staje się przejście do łatania słabości systemów zintegrowanych. Robi się taką „warstwę przykrywającą” systemy zintegrowane, próbującą rozwiązać po raz kolejny te same, znane problemy systemów zintegrowanych, z obietnicą, że będzie „po taniości”. To, co miało być mikroserwisem, staje się magicznym zaklęciem, że niby tym razem się uda. Najczęstszy schemat, jaki widziałem ostatnio, to odciążenie systemów zintegrowanych od wielu operacji odczytu danych poprzez powołanie tworu nazywanego mikroserwisem, stanowiącego cache dla jakiegoś ERP (że to niby taki CQRS na solidnych sterydach). I nie o nazwę tu chodzi, ale o fakt, że po drodze zmieniły się cele – z wewnętrznej organizacji aplikacji na reużycie i integrację – dla realizacji których filozofia i architektura mikroserwisów nie tylko nie pomaga, ale wręcz jest kosztowną przeszkodą.

Z perspektywy doświadczeń w pełnej skali, wypada pamiętać, że wszyscy, którzy wzięli się za mikroserwisy na poważnie nie zrobiliby tego po raz drugi. Już samo to stawia pod poważnym znakiem zapytania osigalną wartość biznesową dla mikroserwisów. Dlaczego tak jest, to trochę wiemy: liczba mikroserwisów w środowisku produkcyjnym rośnie bardzo szybko, koszty zarządzania taką złożonością rosną wykładniczo, każda próba zorganizowania jest przecież antyedżajlowa (czyt. z gruntu zła, nie-do-pomyślenia), dominuje praktyka robienia nowej mirousługi bez przechodzenia przez zmianę istniejącej, powstają wyspy mikrousług tworzonych w oderwaniu od innych, często wielokrotnie implementując te same funkcje. I nie znaczy to, że mikroserwisy są złem wcielonym – znaczy to, że są obszary, gdzie pomagają, ale są też obszary, gdzie mówienie o mikroserwisach powinno być traktowane jak puszczenie bąka w obecności królowej i dworu.

Jak bardzo często w domenie IT, znów winny jest marketing. Peany wyśpiewywane na cześć zwinności, DevOps i nowoczesnych architektur, nakręcane przez różnej maści coachy i mentorów, skutkują brakiem obiektywizmu oraz – w najlepszym wypadku – podejmowaniem decyzji w oparciu jedynie o legendy o korzyściach, a nie rzetelnej ocenie kosztów i aplikowalności takiego podejścia. Niestety, management firm więcej wiary pokłada w tym marketingu, niż w opiniach wypowiadanych przez własnych specjalistów. W ten sposób organizacja pozwala sobie na edżajlowo-dewopsowo-mikroserwisową mieszankę, aby już nikt nigdy nie być w stanie nad tym zapanować. Raz ukonstytuowaną anarchię jest niesamowicie trudno opanować, nie mówiąc już o przywróceniu choćby elementarnej kontroli. Zadanie dojrzałego CIO w obecnych czasach jest naprawdę trudne…

Mikroserwisy, jak każda inna myśl w IT, nie są lekarstwem na wszystko. W praktyce warto ich używać jako hybrydę – włączyć do zakresu używanych narzędzi ze zrozumieniem uwarunkowań, ograniczeń i koniecznych mechanizmów kontrolnych. Trzeba rozumieć, jaka skala to jest jeszcze architektura mikroserwisowa, bo po jej przekroczeniu jest już tylko chaos. Z mojego doświadczenia, akceptowalną jest skala pojedynczej aplikacji – jeśli stosowanie mikroserwisów zaczyna wykraczać poza granice tej aplikacji, zaczynamy mówić o integracji, a to zmienia wszystko. Koniecznie trzeba ustalić, jak organizacja będzie sobie radzić z dużą liczbą mikrousług. Z mojego doświadczenia nie można na mikroserwisy nałożyć ciężkich ram zarządzania, więc radzenie sobie polega na akceptacji stanu niewiedzy i kontrolowaniu obszaru oddziaływania mikroserwisów – trzeba pozwolić na anarchię w ściśle kontrolwoanych granicach. Warto także zrozumieć, jakie są konsekwencje mikroserwisów w rachunku ekonomicznym działań rozwojowych. Z mojego doświadczenia wynika, że raz uruchomiony mikroserwis będzie żył zawsze, więc koszty będą stale rosły – co pewien czas trzeba przeprowadzić najazd architektów korporacyjnych na edżajlowo-dewopsowo-mikroserwisową mieszankę i mieć nadzieję, że wytnie to część zbędną. Pamiętajmy także, że mikroserwisy – aby nie zabiły – to nie tylko inny sposób pocięcia aplikacji dla wygody developmentu. To także adekwatne metody analizy (np. Domain-Driven Design) zapewniające minimalizację siły powiązań, to odpowiednia infrastruktura (np. Kubernetes) dla zapewnienia kontroli i łatwości wprowadzania zmian (np. Canary Deployment). To zrozumienie, że procesy wytwórcze (DevOps) wymagają naprawdę dużej dojrzałości, bo proces można wdrożyć wszędzie, ale w niedojrzałym zespole efekty są zawsze złe, a czasami wręcz Epic Fails.

Jak wszędzie, umiar i rozsądek, dystans i uzasadnienie, szeroki horyzont i zrozumienie konsekwencji. W obecnych warunkach – szczególnie w świecie chmury, w której serverless i konteneryzacja ułatwiają „myślenie na skróty” – tym bardziej. Użycie każdego narzędzia wymaga zrozumienia wykraczającego poza marketing. Mikroserwisy to zaawansowane narzędzie i nie łatwo dostrzec na samym początku pułapki. Najważniejszą z nich jest postawienie granic, żeby dla każdego elementu problemu dobrać właściwe dla niego narzędzia. Na całe szczęście dobry architekt opiera się na doświadczeniu, umie prześwietlić marketing, zna prawdziwą wartość klas rozwiązań i wie, kiedy jakie stosować i jak nie zrobić sobie nim krzywdy. Dobry architekt jest najważniejszym systemem ostrzegawczym przed pułapkami. Warto słuchać architektów! 😊

komentarze 2 dla

  1. Michał Jopek pisze:

    true, true, true! :)

  2. Truth, the Whole Truth and Nothing But the Truth. :-)
    Dzięki Michał!

Pozostaw komentarz