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

13

@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?

8

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.

2

@twoj_stary_pijany

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.

Współdzielenie pamięci to tylko techniczny szczegół realizacji bardziej ogólnej koncepcji jaką jest współdzielenie stanu/utrzymanie spójności danych/synchronizacja. To czy chcemy żeby dwa wątki w pewnej aplikacji widziały "spójny stan" czy chcemy żeby dwa serwisy pracowały ze spójnym stanem to na dobrą sprawę niewielka różnica. Koncepcyjnie problem jest dokładnie taki sam. W praktyce rozwiązuje się go inaczej z czysto praktycznych powodów, bo dla wątków dużo prościej zrobić jakąś synchronizacje w pamięci, podczas gdy pomiędzy serwisami prościej słać eventy, ale można też synchronizować się na dostępnie do bazy danych i "działa" to zarówno dla serwisów jak i dla wątków (inna sprawa czy to dobry pomysł ;) )

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.

Skad pomysł ze monolitu nie da się skalować? Oczywiście że się da, ale będzie to potencjalnie bardziej kosztowne, bo skalujemy wszystko, nawet jeśli tylko mały fragment wymaga przeskalowania.

@ArchitektSpaghetti ze swojej strony, jeśli chodzi o PL, to polecam: Software Engineer Expert

0

Generalnie jeżeli są jakieś problemy ze zbyt wielką ilością requestów, to o wiele prościej postawić loadbalancer i w ten sposób skalować monolit, niż bawić się w mikroserwisy. Natomiast warstwa danych to już sharding / replikacja.

Mikroserwisy tam gdzie chcemy wydzielić jakąś część aplikacji albo do publicznego używania, albo do używania przez partnerów (przykład: allegro), albo przez jakieś inne odziały firmy etc.

Robienie mikro tylko po to, żeby było mikro to "sztuka dla sztuki".

Natomiast zaletą mikro jest lepsza możliwość podziału pracy, łatwiejsza niż w przypadku tworzenia w ten sposób modułów działających w ramach jednej aplikacji, taki podział generuje też mniej błędów w całym procesie produkcji.

Natomiast jak powinien "wyglądać" dobry mikroserwis?

Przede wszystkim to powinien mieć dobrą dokumentację, współpracowałem z 3-ma dużymi firmami w Polsce które udostępniają REST API, tylko Allegro ma dobrą dokumentację, pozostałe dwie to jest %$^^%$^%$!!! koszmar, i mówię o naprawdę dużych/znanych firmach (jak na polskie warunki) - dlatego nie wymienię nazwy.

0

@Shalom:

Skad pomysł ze monolitu nie da się skalować?

Nie powiedziałem, że monolitu nie da się skalować. Wręcz dokładnie napisałem, że da się to robić, a mikroserwisy służą temu, żeby wyskalować je jeszcze bardziej.

Współdzielenie pamięci to tylko techniczny szczegół realizacji bardziej ogólnej koncepcji jaką jest współdzielenie stanu/utrzymanie spójności danych/synchronizacja.

Tak, wszystko jest implementacyjnym szczegółem i wszystkie wzorce są powielane na różnym poziomie. Tylko jakoś nie wszyscy piszą w modelu aktorowym i DDD w monolicie, żeby później tylko wydzielić tych aktorów jako z zewnętrzne serwisy.

2

Jak dla mnie to pytanie źle skonstruowane, powinno być

Mikroserwisy - czy kogoś w Polsce stać, żeby je zrobić dobrze?

Z tego co widzę, to zazwyczaj jest problem już na etapie planowania.
Zaznaczam, że bazuję na przykładzie próby przepisania dużego monolitu na mikroserwisy.

Podejście z buta wjeżdżam, bez jakiejkolwiek analizy i przemyślenia, robienie z doskoku, przez osoby nie mające jakiegokolwiek doświadczenia w pracy przy rozproszonych aplikacjach i mamy gotowy przepis na rozproszony monolit.

Raczej trzeba szukać projektów z dużym budżetem, bo tam jest jakieś większe prawdopodobieństwo, że przy projekcie nie zabierali się od d**y strony, bo na wczoraj ma być skończone, a gadać o czymkolwiek nie ma z kim.
Jednak to żadna gwarancja, a raczej światełko w tunelu.

2

Wydaje mi się, że jest jeszcze jeden dość istotny aspekt, czyli cykl wydawniczy komponentów.
W mojej obecnej pracy mamy kilka modularnych monolitów gadających ze sobą, które można wydawać niezależnie. Jak jakiś komponent w nich zaczyna mieć potrzebę częstszego wydawania, a wydawka całości byłaby zbyt kosztowna/czasochłonna wtedy wydzielamy bo do osobnego jara.

Tak na prawdę podział na mikrosewisy jest logicznie tym samym co podział na komponenty. Dlatego jeśli komuś fizycznie starcza modularny monolit to trochę nie ma po co się pchać w nie.

3

W ogólności zgoda, ale... :) dotyczy to w ogóle inżynierii i architektury oprogramowania, a nie tylko mikroserwisów. I pewnie nie tylko w Polsce (jak @superdurszlak pisał).

Poza tym:

ArchitektSpaghetti napisał(a):
  • Masz więcej mikroserwisów niż programistów.

A dlaczego miałoby być odwrotnie? Albo tyle samo? Jak mam 5 programistów i 10 mikroserwisow, to każdemu daje po dwa (tak, żeby było równo :)) i niech programują. Jak są w miarę ogarnięci, to nie będą mieszać między nimi, wiedzą przecież, że ma być zachowana niezależność na odpowiednim poziomie... :)

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

Większość nie rozumie, niestety...

  • Biznes nie rozumie podziału.
  • Biznes nie ma korzyści z podziału.

Biznes nie ma rozumieć podziału, ma płacić za produkt. A korzyści z podziału ma mieć development team, nie biznes, bo biznes do podziału nosa nie powinien wściubiać.

13

Co do w ogóle za jednostka miary?
Ilość programistów na mikroserwis :-) Brzmi bardziej jak jakiś żart niż argument za czymkolwiek.

0

W Allegro są spoko zrobione, bardzo duży automatyzm, wypracowane patterny itd. W końcu śmiga ich już 1000+, a nie 3 na krzyż - błędy dużo kosztują :D

2
ArchitektSpaghetti napisał(a):
  • Masz więcej mikroserwisów niż programistów.

Liczba programistów nie ma nic wspólnego z liczbą mikro serwisów.

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

Może powinni zrozumieć?

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

Skalowalność, to tylko jeden z problemów możliwych do rozwiązania za pomocą mikro serwisów

  • 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.

Jak z programistami - niech się douczą

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

Trzeba myśleć w kontekście kontraktów i mieć sposób na utrzymywanie API tak, żeby dołożenie jakiejś funkcji w serwisie A, bo serwis B jej potrzebował nie wymuszało z automatu zmian na 50 innych usługach

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

Nigdy nie znasz wszystkich wymagań, dlatego warto zachować elastyczność architektury.

  • Programista musi znać i tak wszystkie moduły.

Mikro serwisy nie są po to, żeby było łatwiej programować

  • Biznes nie rozumie podziału.

I nie musi

  • Biznes nie ma korzyści z podziału.

No ma

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

Podejście mój kod taki piękny rozwali też monolit". Fakt, że tam trudniej o niezgodność modułów między sobą.

Mikro serwis to nie jest technika "kodowania", to technika deploymentu. Robi się to z następujących powodów:

  • ograniczenie zakresu zmian przy deploymencie
  • łatwość określenia gdzie jest błąd
  • łatwość wycofania zmian
  • skalowalność

Przykład, gdzie ma to moim zdaniem sens (mój aktualny projekt):

  • Oczekiwane SLA 99.7%, RTO 1h, RPO 0
  • Nadmiarowość geograficzna
  • Obsługa kilku tysięcy użytkowników jednocześnie w trakcie kilku szczytów dobowych
  • Usługa dostarczana klientowi w modelu SaaS

Nie skończyliśmy rozbijać monolitu na usługi, więc nie powiem ci jak wyszło, na razie wyciągamy powoli kawałki "modularnego monolitu" i pakujemy w osobne usługi podzielone domenowo. Brakuje nam jeszcze pełnego cyklu CI/CD, bo produkt nie jest dostatecznie dojrzały. żeby się w coś takiego bawić.

1

imo Self-contained System rulez.
Nie jest to nic nowego a wręcz odgrzebany staroć sprzed wieków.

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