Mikroszaleństwo?

6

Czy też spotykacie się z sytuacjami, że deweloperzy zamiast pisać kod i rozwiązywać problemy biznesowe zaczynają pracę od d**y strony i wszystko ładują w mikroserwis?
Przeciwnikiem mikroserwisów nie jestem, pracowałem nad rozproszoną aplikację na produkcji, ale już któryś raz widzę fanatyczne podejście do tematu, zachwyt jak to będzie super działać, skalować.
Parę tygodni później okazuje się, że do sklejenia czegokolwiek w jeden kawałek trzeba mnóstwo ticketów, pozwoleń, dostępów a nawet prosty hello world nie działa :)
Może jestem stary i po prostu nieogarniam tematu, a może architekci są zbyt słabi w te klocki i w miare biegły programista bez trudu przerzuci go w dyskusji argumentami?

0

Mi się jeszcze nie zdarzyło pracować przy projekcie, w którym wykorzystane byłyby mikroserwisy, więc chyba nie jestem tró programistą. Rozważane owszem, były, ale i to raczej z myślą o ominięciu jakichś problemów projektowych, choć i tak koniec końców znalazły się prostsze i bardziej eleganckie rozwiązania, niż pakowanie czegoś w osobny serwis by uciec od problemu.

Ale to może dlatego, że jeszcze nie zdarzyło mi się robić czegoś, co docelowo miałoby używać więcej niż kilka osób naraz, więc skalowalność jest tak potrzebna, jak lewarek i koło zapasowe w samolocie.

1

To jest często problem widzimisia architektów, którzy to twierdzą, że coś będzie super hiper a potem problem bo zamiast napisać coś w 100h trzeba na to poświęcić 300h i się okazuje, że budżet się nie spina. Miałem przykład gdzie mój pomysł zakładał zrobienie pewnej rzeczy w 2 tygodnie, pomysł architekta zakładał przerobienie 1/3 aplikacji by wdrożyć tę samą funkcję, efekt taki, że całość zajęła 3 miesiące 2 osobom, zamiast 2 tygodni jednej :D A szefostwo wkurzone oczywiście na programistów, "czemu tak długo".

4

title

Pracowałem w firmie, w której było kilkaset naprawdę mikroserwisów, na jakieś ~400 developerów podzielonych na kilkadziesiąt zespołów. Działało to nadzwyczaj sprawnie. Była to już 4'rta iteracja ich platformy na przestrzeni dwóch dekad, gdzie pierwsze 2 były monolitami, a 3'cia SOA, ale niekoniecznie micro.

Ale jak mamy team kilku-kilkunasto osobowy i projekt który nigdy jeszcze produkcji i klienta nie widział to co my wiemy o jego prawidłowej architekturze i skalowaniu.

5

Pracuję obecnie przy dużym systemie, napisaliśmy go od zera. System oparty o mikroserwisy i event sourcing, stosujemy również DDD. Czy warto? Warto. Czy takie rozwiązanie ma duże korzyści? Jak najbardziej. Czy ma wady? Oczywiście.

Fakt, w dzisiejszych czasach mikroserwisy to nowy buzzword. Jest sporo osób dla których mikroserwisy to jakiś złoty środek- również tutaj na forum. Z jakim problemem architektonicznym się nie zderzyć to zaproponują mikroserwisy. Dla takich osób słowo monolit jest synonimem wielkiego molocha, kodu spaghetti itp. Jest to również stereotyp, ale jak każdy stereotyp skądś się wziął. Dla mnie to bzdura. Niestety nadal jest dużo naprawdę złych monolitów, szczególnie w starych aplikacjach które stale trzeba utrzymywać. Jednakże monolit może być dobrze napisany, stosować odpowiednią architekturę i świetnie się sprawdzać. Nie należy traktować mikroserwisów jako jedynego słusznego czy też lepszego rozwiązania. Powinno się je stosować tam gdzie mają sens, a więc należy rozważyć wszelkie za i przeciw. To nie jest naturalny etap rozwoju monolitów, a opcjonalna droga rozwoju systemu.

Tak więc mikroserwisy faktycznie są dziś nadmiernie proponowane/używane, ale nie zmienia to faktu że tam gdzie naprawdę warto je stosować są świetnym rozwiązaniem.

14

Pracuję w firmie gdzie panuje kult mikroserwisów. Sporo też rozmawiam na różnych meetup-ach i konferencjach.

Moje doświadczenia na szybko:

Na plus:

  • rozwiązują problem wielkiej skali. Jak jesteś Netflixem, Amazonem to jedyna droga.
  • rozwiązują problem wielkich i bolesnych wdrożeń

Na minus:

  • Ludzie myślą, że mikroserwis powinien być mały, gdzie tak na prawdę, to zwykle gruba i bogata aplikacja zarządzająca jedną domeną biznesową,
  • Ludzie źle wydzielają granice pomiędzy mikroserwisami np. tnąc je ze względu technicznego. (tutaj mikroserwis do pdfów, a tutaj do resta). Błędem jest też ciąć niepodzielne domeny, gdzie mamy dużo zalezności i komunikacji. Wówczas, cała ta komunikacja jest po reście i kolejkach co jest wolne, czasochłonne i generuje błędy.
  • Ludzie wdrażają mikroserwisy tam gdzie nie ma odpowiedniej kultury organizacyjnej / DevOps (Słynne "you must be this tall to use microservices"). Tzn. trzeba mieć niezależne zespoły zorientowane produktowo. Zautomatyzowane pipeline CI/CD, infrastructure as a code etc.
  • Ludzie w architekturze mikroserwisów zapominają o transakcjach i spójności danych. Myśląc, że mikroserwisy są łatwe, zapominają o błędach sieci etc.
  • Mikroserwisy spowalniają development na wczesnym etapie, wtedy gdy potrzebujemy szybkiego feedbacku i nie wiemy czy projekt wypali, oraz gdy biznes oczekuje szybkiej wartości dodanej.

Uważam, że mikroserwisy powinny być efektem podziału udanego i działającego systemu na mniejsze, a nie architekturą od początku.

0
Aventus napisał(a):

Pracuję obecnie przy dużym systemie, napisaliśmy go od zera. System oparty o mikroserwisy i event sourcing, stosujemy również DDD. Czy warto? Warto. Czy takie rozwiązanie ma duże korzyści? Jak najbardziej. Czy ma wady? Oczywiście.

Fakt, w dzisiejszych czasach mikroserwisy to nowy buzzword. Jest sporo osób dla których mikroserwisy to jakiś złoty środek- również tutaj na forum. Z jakim problemem architektonicznym się nie zdeżyć to zaproponują mikroserwisy. Dla takich osób słowo monolit jest synonimem wielkiego molocha, kodu spaghetti itp. Jest to również stereotyp, ale jak każdy stereotyp skądś się wziął. Dla mnie to bzdura. Niestety nadal jest dużo naprawdę złych monolitów, szczególnie w starych aplikacjach które stale trzeba utrzymywać. Jednakże monolit może być dobrze napisany, stosować odpowiednią architekturę i świetnie się sprawdzać. Nie należy traktować mikroserwisów jako jedynego słusznego czy też lepszego rozwiązania. Powinno się je stosować tam gdzie mają sens, a więc należy rozważyć wszelkie za i przeciw. To nie jest naturalny etap rozwoju monolitów, a opcjonalna droga rozwoju systemu.

Tak więc mikroserwisy faktycznie są dziś nadmiernie proponowane/używane, ale nie zmienia to faktu że tam gdzie naprawdę warto je stosować są świetnym rozwiązaniem.

@Aventus Z ciekawości. Używacie w tym waszym systemie opartym o event sourcing dat lub UUIDów?

1

To co @nie100sowny napisal, nazwa jest fatalna i mylaca i mikroserwisy nie powinny byc takie mikro jak sie wydaje. Rozmawialem dzisiaj o tym z ludzmi po meetupie. Dzielenie transakcji to tez zlo w czystej postaci, chyba ze naprawde sie nie da inaczej.

Moze jakby to makroserwisami nazwac ?

Z drugiej strony pod katem pracy, jak mamy jakas automatyzacje Devops to czy to taka wielka roznica czy dodajemy nowe Dockery czy np. nowe VM na AWS? (poza roznica w rachunku)

1

Czy też spotykacie się z sytuacjami, że deweloperzy zamiast pisać kod i rozwiązywać problemy biznesowe zaczynają pracę od d**y strony i wszystko ładują w mikroserwis?

Wersja frontendowa:
"Akcja na twarz i pchasz"
Czyli pakowanie w Reduxa wszystkiego, łącznie z jakimiś lokalnymi stanami GUI, których pakowanie do Reduxa spowalnia tylko i komplikuje aplikację.

Na dodatek, żeby upakować wszystko do Reduxa, okazuje się, że jeden ficzer przestaje być całością, a zaczyna być niepotrzebniony rozdrobniony po 5 różnych plikach (z naciskiem na niepotrzebnie. Czasem podział ficzera na wiele plików ma oczywiście sens, ale w przypadku używania Reduxa to taki overengineering, który nic nie daje - gdzie coś, co reprezentuje w sumie jedną wartość liczbową czy jednego stringa, musi mieć własną akcję, własnego actiona creatora, reducera, selektora...).

Obstawiam, że kult Reduxa na froncie to taki odpowiednik kultu mikroserwisów na backendzie.

1

@nie100sowny:

Ludzie myślą, że mikroserwis powinien być mały, gdzie tak na prawdę, to zwykle gruba i bogata aplikacja zarządzająca jedną domeną biznesową.

Nie chcę się wdawać w dywagacje, ale to zdanie jest trochę błędne. Tobie chyba chodzi o to że mikroserwis z definicji nie powinien być taki "mikro". Ludzie akurat słusznie myślą że mikroserwis powinien być mały, bo taka jest ogólno przyjęta definicja takiego serwisu. Jeśli każdy "mikroserwis" ma być duża aplikacją samą w sobie, to mamy architekturę opartą o serwisy (SOA), czyli to czym mikroserwisy w założeniu mają nie być.

No chyba że mamy różne definicje "grubej i bogatej" aplikacji. Ale słowo "gruba" w tym kontekście jednak sugeruje coś znacznie większego niż mikroserwis w ogólnie przyjętej definicji powinien być.

1

@Aventus. Świetnie to zobrazował kiedyś Jakub Kubryński, pytając publiczność ile mikroserwis powinien mieć orientacyjnie linii kodu. Większość twierdziła, że 1000 lub 10000.

To teraz przeciętny system enterprise to około 500 000 linii kodu. Jeśli go podzielimy na 50 serwisów, a takich systemów firma ma kilka to trzeba armii inżynierów.

Znam zespoły co mają nowy produkt, ledwo weszli na prod i już mają 40 serwisów. To jest bardzo popularne niestety.

EDIT1: I tak, wiem że LOC to dziadowska miara czegokolwiek. Ale na potrzeby rozmowy o wielkości ujdzie.

0

No tak, ale jakis arbitralny podzial na linie kodu nie ma sensu. Odnosze wrazenie ze dyskusja przechodzi z jednej skrajnosci w druga. Jak najbardziej mozna miec podzial nawet na 40 lekkich mikroserwisow przy stosunkowo niewielkiej liczbie programistow. W moim projekcie jest ich okolo 20 na dzien dzisiejszy, przy mniej wiecej 25 programistach. Nikt nie mowi ze jeden zespol moze pracowac tylko nad jednym mikroserwisem. Tak wiec, nie trzeba armii inzynierow. Jest to podejscie bledne i tworzenie problemow tam gdzie ich nie ma. Nie robmy tego, mikroserwisy swoje problemy juz maja- tak jak kazda inna architektura czy ekosystem ;) Nie zrozum mnie zle, ale argument ktory zastosowales jest argumentem stworzonym na potrzeby dyskusji. Nijak sie ma do rzeczywistosci.

EDIT: Zmienilem liczbe mikroserwisow bo mi sie pomylilo.

2

Mikroserwisy są od tego aby rozwiązywać problem skalowania aplikacji / systemu - nie masz problemu ze skalowaniem, nie wciskaj na siłę mikroserwisów.
Mam wrażenie, że ludzie lubią zapominać, ale mikroserwis to nie tylko kod, który natluczemy - ale taka baza danych jako osobny zbiór serwerów skalowalnych to przecież "mikroserwis" czy cache dla systemu.
Nie ma na siłu wydzielać z monolitu serwisu. U mnie jest jeden kod monolityczny wystawiany jako 6 serwisów -> zależnie od potrzeb zasobów i skalowalności danego rozwiązania i potrzebnego środowiska do działania. Na siłę nie dzielimy tego na osobne repozytoria.

To teraz przeciętny system enterprise to około 500 000 linii kodu.

@nie100sowny Skąd taka liczba - tak z ciekawości?

0
Aventus napisał(a):

No tak, ale jakis arbitralny podzial na linie kodu nie ma sensu. Odnosze wrazenie ze dyskusja przechodzi z jednej skrajnosci w druga. Jak najbardziej mozna miec podzial nawet na 40 lekkich mikroserwisow przy stosunkowo niewielkiej liczbie programistow. W moim projekcie jest ich okolo 20 na dzien dzisiejszy, przy mniej wiecej 25 programistach. Nikt nie mowi ze jeden zespol moze pracowac tylko nad jednym mikroserwisem. Tak wiec, nie trzeba armii inzynierow. Jest to podejscie bledne i tworzenie problemow tam gdzie ich nie ma. Nie robmy tego, mikroserwisy swoje problemy juz maja- tak jak kazda inna architektura czy ekosystem ;) Nie zrozum mnie zle, ale argument ktory zastosowales jest argumentem stworzonym na potrzeby dyskusji. Nijak sie ma do rzeczywistosci.

EDIT: Zmienilem liczbe mikroserwisow bo mi sie pomylilo.

Czyli 2 mikroserwisy na człowieka. Właśnie to według mnie jest w większości firm antywzorzec. 1-2 mikroserwisy na zespół brzmi spoko. 3-10 mikroserwisów na zespół brzmi też spoko. Więcej to według mnie już brzmi ryzykownie i pachnie over-enginieringiem.

Oczywiście to moje zdanie i zależy od projektu. Ja mam na myśli problemy o skomplikowanej domenie, gdzie wszystko od siebie zależy, a nie zbiór niezależnych małych problemów. Chętnie wysłuchałbym innych opinii.

0

Autorze brzmisz zupełnie jak pseudo architekt w mojej byłej firmie. Co to nie on i jaka kicha jest z mikroserwisami bo pisze je dziewczyna z innego działu i na pewno nie będą działać i inne bla bla bla. Przyszło co do czego ustrzelił focha i zniknął na jakiś czas, jak się okazało międzyczasie przyszli ludzie którzy w przeciwieństwie do niego umieli pisać w technologii którą się masturbował. Suma summarum przepisali wszystko od podstaw bo chłop wypluł z siebie bardzo dużo kodu który nadawał się do kosza.

1

Czyli 2 mikroserwisy na człowieka. Właśnie to według mnie jest w większości firm antywzorzec.

To jest tak samo błędna miara jak patrzenie na ilość tysięcy linii kodu na jeden mikroserwis.

Ja mam na myśli problemy o skomplikowanej domenie, gdzie wszystko od siebie zależy, a nie zbiór niezależnych małych problemów.

W moim przypadku to domena ubezpieczeń, a więc myślę że wystarczająco skomplikowana. Cały sens mikroserwisow polega na tym żeby rozbić system na niezależne małe problemy, które paradoksalnie tworzą jedną, współzależną całość. Moim zdaniem Twoja definicja mikroserwisów jest zwyczajnie błędna. Wydaje mi się że mieszasz mikroserwisy z Service Oriented Architecture (SOA), o czym już wspomniałem wyżej.

1

Cloud. Niższa bariera w wejscia. A przynajmniej tak sie wydaje. Produkty jak k8s i serverless - odpalasz i dziala.
A wiekszosc firm pewnie tego nie potrzebuje. Wiekszosc pewnie bylaby szczesliwa stawiajac pojedynczego klocka gdzies w cloud.

Mimo to pakuja sie w to bezmyslnie. Jak rekrutuje to wiekszosc nie umie uzasadnic po co to robia.

I pozniej mam mikroserwisy, kazdy nowy crud/resource to nowy mikroserwis.
A w dyskusji to nawet widze, ze nie padlo nic o "bounded context" ...

"Service-oriented architecture composed of loosely coupled elements that have bounded contexts"
"Microservices are a loosely coupled Service-Oriented Architecture (SOA) with bounded contexts."
by Adrian Cockcroft

najwiekszy sens mikroserwisow jest dla mnie w naprawde duzych organizacjach gdzie nieublagalnie działa Conway’s Law
https://www.infoq.com/presentations/google-microservices

0
karsa napisał(a):

Cloud. Niższa bariera w wejscia. A przynajmniej tak sie wydaje. Produkty jak k8s i serverless - odpalasz i dziala.

Mam zgoła odmienne doświadczenia. Wręcz przeciwne, ale zakładam, że potrzebne jest pewne ogarnięcie, aby sprawy takie jak k8s i serveless tak jak mówisz - odpalały i działały
Odnośnie samego serverless - polecam ciekawy research Serverless Computing: One Step Forward, Two Steps Back [0]

W tym miejscu polecam jeszcze raz (i pewnie będę przez kolejny rok) ten talk Mark Hibberd - Programming in the Large: Architecture and... [1]

[0] https://arxiv.org/abs/1812.03651
[1]

1

Gorący wątek na ten temat z hacker news: https://news.ycombinator.com/item?id=19382765

0

Większość projektów jak w zalaczniku

0

Skalowanie skalowaniem, ale trzeba pamiętać że skalowanie jest też w dół: cały system powinien dać się postawić lokalnie na devowym pececie w rozsądnym czasie (kilka godzin, nie tygodni), a nie będzie problemów typu "że jak my odpalamy testy, to testerzy płaczą że mają za mało mocy".

Jeśli system jest rozdrobniony do tego stopnia że nie ma osoby która by wiedziała jak postawić całość, a na pomysł postawienia wszystkiego na localhoście pukają się w czoło, to jest źle.

3

W najnowszym Technology Radar v19 sygnowanym przez Martina Fowlera, są dwie wzmianki o mikroszaleństwie:
https://www.thoughtworks.com/radar/techniques?fbclid=IwAR3C1AQgByDzR_EMwDv_g_NGEqEOvJP0WxWYCNPtswOcDxLMpJ0BAvoY-IY

**21. Layered microservices architecture **
A defining characteristic of a microservices architecture is that system components and services are organized around business capabilities. Regardless of size, microservices encapsulate a meaningful grouping of functionality and information to allow for the independent delivery of business value. This is in contrast to earlier approaches in service architecture which organized services according to technical characteristics. We've observed a number of organizations who've adopted a layered microservices architecture, which in some ways is a contradiction in terms. These organizations have fallen back to arranging services primarily according to a technical role, for example, experience APIs, process APIs or system APIs. It's too easy for technology teams to be assigned by layer, so delivering any valuable business change requires slow and expensive coordination between multiple teams. We caution against the effects of this layering and recommend arranging services and teams primarily according to business capability.

23. Microservice envy
Microservices has emerged as a leading architectural technique in modern cloud-based systems, but we still think teams should proceed carefully when making this choice. Microservice envy tempts teams to complicate their architecture by having lots of services simply because it's a fashionable architecture choice. Platforms such as Kubernetes make it much easier to deploy complex sets of microservices, and vendors are pushing their solutions to managing microservices, potentially leading teams further down this path. It's important to remember that microservices trade development complexity for operational complexity and require a solid foundation of automated testing, continuous delivery and DevOps culture.

1

W sumie też ostatnio trafiłem na tekst w temacie, kolejny balonik pęka ;]

http://www.craigkerstiens.com/2019/03/13/give-me-back-my-monolith/

Co do samej skalowalności to ogólnie jest temat pułapka, przy projektach które dopiero raczkują. W skrócie: poświęcanie czasu i zasobów na skalowalność która nie jest prostym zagadnieniem, a która nie jest nam zazwyczaj potrzebna na wczesnym etapie.

0

Każdy fajny wynalazek, który staje się modny, w końcu jest źle używany lub nadużywany: https://thecodinglove.com/badly-using-a-framework-and-it-still-works

3

To ma nawet nazwę: https://en.wikipedia.org/wiki/Hype_cycle

Prawdziwy problem ludzi pozbawionych zdrowego rozsądku (czyli tych, którzy próbują pchać coś nowego wszędzie, bez przemyślenia, czy ma to sens, czy nie i w ten Hype cycle w ogóle wpadają), polega na tym, że porzucają nowe podejście zanim osiągną trough of disillusionment i z miłośników stają się hejterami. No bo skoro im w życiu nie wyszło z jakimś narzędziem, to znaczy, że ono w ogóle nie ma sensu dla nikogo w żadnej sytuacji.
I nie tylko zamieniają modę na coś w modę bycia przeciwko temu czemuś, ale przy okazji zazwyczaj wpadają też w nową modę, której stają się gorącymi zwolennikami. Oczywiście aż do kolejnego rozczarowania. Takie zachowanie można teraz obserwować z ORMami i kontenerami IoC, na mikroserwisy pewnie jeszcze przyjdzie czas.

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