Mikroserwisy - czy ktoś je robi dobrze w Polsce?

12

Sorry, za rantowanie, ale chciałbym znać odpowiedź na pytanie z tytułu. Czy ktoś tu pracuje w projekcie, gdzie czuje, że mikroserwisy są dobrze zrobione i mają sens?

Przewinąłem się już przez kilka projektów, w których były mikroserwisy i, uwzględniając to że każdy definiuje je inaczej, zauważam kompletne oderwanie wyników od obietnic, tak jakby ludzie robili te mikroserwisy zupełnie z innego powodu niż powinni, lub zupełnie na odwrót niż jest to opisywane w książkach.

Projekt 1.
Wiemy, co robimy. Klon istniejącego rozwiązania. Może być dużo użytkowników, ale bez przesady.
4 programistów - 10 mikroserwisów. Każdy commituje do każdego codziennie.
Podział na serwisy warstwowy(WTF) - większość zapytań z frontu powoduje, że każdy serwis dostaje jakiegoś rest-calla.
W rezultacie mamy spaghetti, ale zamiast na poziomie kodu, to na poziomie RESTa.

Projekt 2.
Zespół 4 osobowy - domena niejasna - będzie odkrywana wraz z wymaganiami - mocno w data science.
Nie wiemy, co robimy. Prawdopodobnie wszystko przepiszemy ze trzy razy, zanim będziemy wiedzieć, co chcemy. Najpierw trzeba sprzedać proof-of-concept nieznanemu klientowi.
Dzielimy to na kilka mikroserwisów, bo taka moda. Oczywiście już teraz wiemy, jaki jest najlepszy podział.
Organizacja ma problem z wdrożeniem Dockera (wszyscy pracują na Windowsach). Operations i procedury mają state-of-the-art ale z roku 2008.

Projekt 3.
Znana domena, zmieniana nieczęsto, zgodnie z wolą ustawodawcy. Liczba aktywnych użytkowników ograniczona przez liczbę powiatów w Polsce. SLA co do dostępności: ma działać 9-17 w dniach roboczych. System podzielony na kilka serwisów. Pod spodem wspólna baza danych - każdy serwis zapisuje i odczytuje z tego samego schematu.
Organizacja ma problem z załatwieniem admina na Windowsy dla programistów, a pcha się w mikroserwisy.
Tu mógłbym posądzić oryginalnego pomysłodawcę o CV - driven development. Oczywiście nikt już nie wie, kto to był. Nie zalecałbym innego wzorca architektury niż ładny monolit.

Projekt 4.
Duże korpo. Jakiś podział jest koniecznością, po prostu ze względu na skalę tego potwora.
Ale:

  • Wszystkie zespoły commitują do wszystkich serwisów. Jak jest problem, to ten kto ostatni dotykał, naprawia.
  • Synchronicznych wołań jest tyle, że każdy serwis staje się point-of-failure.
  • Seniorzy mają problemy ze zrozumieniem, że np Kafka wymaga innego podejścia niż @Transactional na twarz i pchasz.
  • Współdzielony kod-framework powoduje wymioty.
  • Nie ma testów automatycznych obejmujących coś więcej niż jeden serwis.
  • Wszystko i tak jest wdrażane big-bangiem.

Projekt 5.
Startup. Mamy ogólny zarys pomysłu. Zamiast zrobić jak najszybciej MVP, które będziemy mogli często zmieniać, albo nawet wyrzucić i przepisać, inwestujemy sporo czasu w architekturę mikroserwisową.
Podział początkowo wydaje się sensowny - klient naciskał, żeby od razu skalować się na miliony. Architektura teraz wydaje się kupą, bo projekt poszedł w inną stronę.

Podsumowując, jeśli w projekcie masz "mikroserwisy" i występuje jeden z symptomów poniżej, to jest bardzo źle, bo kompletnie zapomniałeś, po co wdrażałeś mikroserwisy i jakie są zagrożenia. Najprawdopodobniej i tak nie myślałeś o tym na początku.

  • Masz więcej mikroserwisów niż programistów.
  • Twoi programiści nie rozumieją problemów rozproszonych.
  • Masz takie obciążenie, że możesz hostować na Raspberry Pi
  • Twoi architekci zbudowali 15 letnią karierę na gaszeniu pożarów w monolicie. To mądrzy ludzie. Na pewno dadzą sobie radę ze zmianą paradygmatu.
  • Modyfikacje wymagań często obejmują wiele serwisów.
  • Nie znasz wymagań, ale znasz już architekturę.
  • Programista musi znać i tak wszystkie moduły.
  • Biznes nie rozumie podziału.
  • Biznes nie ma korzyści z podziału.
  • Developerzy nie rozumieją, jak ich kod trafia na proda.
0

może allegro? na konfach ładnie opowiadają o tym czego oni nie robią :P

3

W UPC było dobrze

12

@ArchitektSpaghetti: to co opisujesz nie dotyczy mikroserwisów, a raczej nie tylko mikroserwisów. Ten temat powinen nazywać się: architektura oprogramowania - czy ktoś ją robi dobrze w Polsce?

Seniorzy mają problemy ze zrozumieniem, że np Kafka wymaga innego podejścia niż @Transactional na twarz i pchasz.

J/W. To też jest taki problem że ludzie nie uczą się programować, tylko uczą się frameworków.

Nie znasz wymagań, ale znasz już architekturę.

Co masz na myśli? To że ktoś zaczyna od razu wprowadzać mikrosewisy do nowego projektu, albo używać Kafki?

7

Masz więcej mikroserwisów niż programistów.

I jakie to niby ma znaczenie? o_O Podział na serwisy jest związany funkcjami systemu, cyklem życia i skalowaniem, a nie z tym ilu masz programistów. Jeśli pewne funkcje systemu wymagają dużo większej skalowalności, to wygodnie jest oddzielić je od reszty i odpalać na większej liczbie nodów. Jeśli pewne funkcje mają inny cykl życia (np. zmieniaja się częściej) to znów wygodnie jest je oddzielić. Liczba programistów nie ma tu w zasadzie nic do rzeczy.

Twoi programiści nie rozumieją problemów rozproszonych.

To jest problem programistów a nie mikroserwisów. Rozproszenie to tylko rozszerzenie problemów ze współbieżnością i jeśli ktoś nie ogarnia jak pracować z asynchronicznymi wywołaniami, czy eventual consistency, to nawet w monolicie będzie miał problem jak tylko pojawi się więcej niż 1 wątek.

Masz takie obciążenie, że możesz hostować na Raspberry Pi

Taka malina to może uciągnąć całkiem sporo ;) Zresztą bardzo często to latency jest ważne, a nie czy masz jakieś operacje CPU-intensive albo czy potrzebujesz dużo RAMu. Potrafię sobie wyobrazić że hostowanie czegoś na dużej liczbie malinek byłoby lepsze pod tym względem niż hostowanie na jakichś mocnych maszynach.

Modyfikacje wymagań często obejmują wiele serwisów.

To brzmi jak problem przy podziale na serwisy, a nie problem z serwisami jako takimi. Tak jak napisałeś, jak ktoś robi jakiś cudaczny podział "warstwowy" a nie względem operacji domenowych, to faktycznie może mieć takie kwiatki. Wtedy trzeba sobie zadać pytanie które funkcje powinny być upakowane razem?.

Nie znasz wymagań, ale znasz już architekturę.

To znów nie jest problem z mikroserwisami, tylko ogólnie z cargo-cult i hype-driven-development. Są ludzie którzy ładują zależność do springa i hibernate i już kręcą jakąś SQLową bazę, jeszcze zanim usłyszą pierwsze wymagania... Jednocześnie warto pamiętać że jakies 80% wymagań nie jest znane przed rozpoczęciem developmentu.

Programista musi znać i tak wszystkie moduły.

Nie wiem co to ma do rzeczy. Może macie w zespole shared-ownership i dbacie o to żeby był dobry bus factor i każdy w zespole był w stanie wprowadzać zmiany w dowolnym serwisie?

Biznes nie rozumie podziału.

Nie rozumiem czemu miały w ogóle o nim wiedzieć. Dla biznesu masz po prostu system. To jak on jest wewnętrznie podzielony to jest szczegół techniczny. Biznes to najwyzej może interesować ile to kosztuje.

Biznes nie ma korzyści z podziału.

W jaki sensie korzyści? Podział na mikroserwisy nie sprawia że system dostanie super moce albo nowe ficzery.

Developerzy nie rozumieją, jak ich kod trafia na proda.

Nie do końca rozumiem co masz na myśli. Trafienie na proda może być dość złożonym devopsowym procesem (w stylu jakis terraform + puppet + jakaś magia z AWS EC2 API) i w normalnej firmie jest to ukryte pod jakimś CI i szeregowi programiści wcale nie muszą wiedzieć jak to się dzieje dokładnie. Dla nich to guzik w CI deploy on PROD albo deploy on TEST. Nie da się być specjalistą we wszystkim.

13

Powiedzmy że nie miałem do czynienia z mikroserwisami jakoś ekstremalnie długo, ani w nie wiadomo ilu zespołach/firmach ale pewne problemy biją po oczach, patrzysz raz i widzisz, że nie ma siły bo to musi w końcu j**nąć - i tak, często da się to sprowadzić do kwestii komunikacja jest słaba

  • Zespoły programistów po jednej stronie oceanu, zespoły "devopsów" po drugiej stronie oceanu. Jedni bez drugich nie mogą niczego zrobić.
  • Jest sobie jakiś system, niby mikroserwisy cloud itd ale wszystko dawało rady na jednym DC. Biznes stawia wymagania, że musi stać na wielu DC. OK, to do zrobienia, problem w tym że zanim osoby odpowiedzialne za dopilnowanie tego się o tym dowiadują, to już praktycznie wybija ustalony przez biznes deadline. A potem frustracja, zgadywanie czy jesteśmy w stanie ot, tak puścić produkcję na iluś DC i zmigrować dane w locie, czy będzie downtime, no kompletnie nic, a wszyscy założyli że my to po prostu zrobimy bez przetestowania, ot dodamy nowe guziki deploy to... i będzie śmigać.
  • Każdy tworzy swój mikroserwis i jego CI/CD po swojemu, więc w każdym projekcie jest inaczej, nikt nie wie co się dzieje, jak trzeba dołożyć mikroserwis to się po prostu kopiuje pipeline, kopiuje terraformy, kopiuje konfiguracje k8s z nadzieją, że nigdy nie będzie trzeba tego ruszać
  • Mimo totalnie wolnej amerykanki pojawiają się odgórne zarządzenia, co musi być w takim CI/CD i jak ma działać, co skutkuje gigantycznym marnotrawstwem energii na to, by te wszystkie ręcznie kulane procesy ukulać z grubsza do pożądanego kształtu :)
  • Ktoś odkrywa, że jest bajzel, że ten system pracy się nie skaluje, że nie da się ogarnąć co się dzieje, że dużo roboty jest powtarzalnej.... i jako remedium wprowadza jeszcze więcej copy-pasty, tyle że generowanej przez jakieś skrypty i inny tooling działający na słowo honoru i przy założeniu, że użytkownik-programista nie będzie musiał wprowadzać żadnych zmian. Ale oczywiście, że będzie musiał, skoro każdy serwis ma inne API, inne zależności, inne integracje i generalnie robi co innego. Po pół roku magiczne toole mają nową wersję pod nowe wymagania jak ma to wyglądać, i każdy zespół musi się zastanawiać jak podbić wersję czegoś, co zawaliło im VCS wygenerowanym bajzlem który oni miesiącami poprawiali....
  • Często jest tak, że N zespołów (słusznie) identyfikuje problem, próbuje go rozwiązać po swojemu, zespoły wokół podchwytują i... Dalej jest bajzel, bo jest N konkurujących firmowych standardów które dopiero po czasie odkrywają swe wzajemne istnienie
  • Architekci budujący mikroserwisy w architekturze warstwowej z synchronicznymi callami: Controller Service, Service Service, Database Service... kiedyś nawet próbowałem ostrzegać, że to j**nie. No ale kto by słuchał głupiego juniorka jak sam jest wielkim architektem. Potem słuchałem w kuchni narzekania że jeden call do API skutkował turbo-kaskadą calli między serwisami, oczywiście wszystko synchronicznie :)
  • Bajzel w CI/CD i mikroserwisach, brak kontroli nad zależnościami, porządnych testów itd. skutkuje bajzlem przy deploymentach, zwałkami, pożarami itd. Rozwiązaniem oczywiście orkiestracja deploymentów wszystkich mikroserwisów raz na X czasu, zatrudnianie managerów którzy dyrygują deploymentami i programistami poprzez wypełnianie tabelek w Excelu o tym co, kiedy, w jakiej kolejności, w jakiej wersji...

Tyle że to niekoniecznie dotyczy nieumiejętności robienia tego w Polsce, co nieumiejętności robienia mikroserwisów w ogóle. Niemały wkład w powstający bajzel miały zagramaniczne zespoły i architekci :)

20

co prawda nie w polsce, ale moze komus sie przyda historia jak dzialaja mikroserwisy w mojej obecnej firmie zajmujacej sie (w duzym uproszczeniu) dystrybucja danych rynkowych.
pare faktow:

  • ~20 userow wewnetrznych, 5k+ userow zewnetrznych, 700+ klientow podlaczonych do streamingu realtime 5.5 dnia w tygodniu
  • 5 programistow zajmujacych sie glownie mikroserwisami, 7 zajmujacych sie bardziej data science, devops lub frontendem
  • 300+ mikroserwisow, wiekszosc ponizej 1k LoC, pare powyzej 10k, pare ponizej 100
  • pisane glownie pod jvm (java, scala) ale tez c, python, ruby i inne dziwactwa
  • glownie kubernetes/docker/azure ale tez bare-metal, pare hadoop'owych serwisow, kafka i chronicle jako middleware

postaram sie wymienic pare czynnikow dzieki ktorym jest to mozliwe:

  • bardzo silny nacisk na separacje odpowiedzialnosci miedzy serwisami, przykladowe serwisy (juz nazwy dosc dobrze wyjasniaja po co serwis istnieje): BloombergConsumer, KafkaMonitor, ClientAPIGateway, ClientStatsPublisher, WhatsappBot, SubscriptionQueryOptimizer etc
  • bardzo silny nacisk na backward compatibility/fault tolerance (revert w srodku dnia - zero problemu)
  • release przy wywolaniu 2-3 komend. release build zajmuje pare minut. kilkanascie releasow na produkcje tygodniowo, wiekszosc to bardzo male zmiany.
  • kazdy z serwisow ma swojego maintainera ktory zazwyczaj pisze w nim 100% kodu albo przynajmniej robi gatekeeping dla innych. zmiany we wspoldzielonym frameworku wymagaja approvala od przyjamniej polowy zespolu
  • kazda nowa zmiana musi miec automatyczny test jako dowod ze dziala
  • czyste API miedzy serwisami, brak redundacji
  • pedantyczni programisci ktorzy nie sa "seniorami" (w rozumieniu korporacyjnym)
  • brak architektow, biznes analitykow, qa, dokumentacji i scruma
  • najwyzej 1h obowiazkowego spotkania calego zespolu w tygodniu, reszta to po prostu ad hoc czaty zazwyczaj wylacznie tekstowe
7

Mnie zawsze zastanawia dlaczego natychmiast projekt startuje jako masa mikroserwisow zamiast zacząć od monolita "modułowego". Czyli zachowujemy zasady mikroserwisow(podział na domeny, rozdzielność bazy danych itp) ale wewnątrz monolita. Ułatwia to pracę i wdrożenie a w razie potrzeby nie trzeba wiele żeby to rozbić na mikroserwisy.

0

Dzięki za odpowiedzi. Tylko Allegro?

@Shalom:

Shalom napisał(a):

Masz więcej mikroserwisów niż programistów.

I jakie to niby ma znaczenie? o_O Podział na serwisy jest związany funkcjami systemu, cyklem życia i skalowaniem, a nie z tym ilu masz programistów. Jeśli pewne funkcje systemu wymagają dużo większej skalowalności, to wygodnie jest oddzielić je od reszty i odpalać na większej liczbie nodów. Jeśli pewne funkcje mają inny cykl życia (np. zmieniaja się częściej) to znów wygodnie jest je oddzielić. Liczba programistów nie ma tu w zasadzie nic do rzeczy.

Oczywiście, można iść w mikroserwisy, które są faktycznie mikro i to może działać i mieć podstawy w wymaganiach niefunkcjonalnych(@katelx podała przykład). Jednak najczęstszym powodem wyboru mikroserwisów powinny być: autonomia organizacyjna i niezależny rozwój (korzyść dla biznesu). Jeśli masz 5 developerów i system typu CRUD, to trzeba się silnie zastanowić, w czym tak naprawdę przeszkadzałby rozproszony monolit.

Co do innych uwag, ja nie krytykuję mikroserwisów jako takich, ale narzekam na to, jak one wychodzą w praktyce (trochę jak z Agile).

2

Po prostu nie każda firma ma produkt, który obsługuje miliardy ludzi. Więc monolity są popularniejsze. Dużo firm zamiast rozbijać się na mikroserwisy to po prostu może się najpierw rozbić na produkty. Każdy produkt może być osobnym serwisem, ale to jeszcze nie jest architektura mikroserwisów. Jeżeli masz bardzo duży produkt to będziesz rozważał nawet stworzenie serwisu do generowania unikalnych identyfikatorów jeżeli taka funkcja zabiera zbyt dużo zasobów. Przy czym taki serwis też stanie się bottleneckiem więc to nie jest takie proste. W realnym świecie, każdy oddzielny mikroserwis musi mieć uzasadnienie biznesowe, musi na siebie zarabiać i musi być weryfikowalny. Chyba, że przyszliśmy do firmy się "pobawić" za pieniądze inwestorów i po roku zmieniamy pracę na kolejną zanim biznes zweryfikuje nasz kod. Albo mamy architektów astronautów, którzy robią wszystko na czuja i prokrastynują skalując rzeczy, które nie wymagają skalowania bo na tym się znają, a ignorują rzeczy ważne bo na nich się nie znają.

Bardzo ciężko jest dostać taki cały produkt do zrobienia. Nawet idąc do firm tworzących wielkie produkty dostaniesz do zrobienia mały mikroserwis i możesz nie widzieć całości jako architektura mikroserwisowa.

@Shalom Przyczepię się jeszcze na koniec, żeby coś się działo w wątku.

To jest problem programistów a nie mikroserwisów. Rozproszenie to tylko rozszerzenie problemów ze współbieżnością i jeśli ktoś nie ogarnia jak pracować z asynchronicznymi wywołaniami, czy eventual consistency, to nawet w monolicie będzie miał problem jak tylko pojawi się więcej niż 1 wątek.

I tak, i nie. Współbieżność dzieli pamięć, a systemy rozproszone niekoniecznie i jest to dodatkowa rzeczy, którą trzeba rozważać pod względem bottlenecków.

Podział na mikroserwisy nie sprawia że system dostanie super moce albo nowe ficzery.

Mikroserwisy nie sprawią, że produkt dostanie nowe ficzery, ale sprawi, że więcej osób będzie mogło korzystać z tego produktu w tym samym czasie. To jest realna korzyść dla biznesu. Kiedy tworzysz nowy produkt to jednym z wymagań powinno być ustalenie ilu użytkowników może korzystać z serwisu w tym samym czasie. Jeżeli tego nie ustalisz z klientem to nie wiesz jaką architekturę wybrać.

I jeszcze przyczepię się @ArchitektSpaghetti

Masz więcej mikroserwisów niż programistów.

Moim zdaniem na odwrót. Jeżeli masz więcej programistów niż mikroserwisów to znaczy, że coś tu jest nie tak z Twoją architekturą mikroserwisową. Czy pojedyncze mikroserwisy są zbyt trudne do zrozumienia albo zdeployowania? Może kod jest zbyt słabej jakości albo use case jest niejasny.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0