Wątek przeniesiony 2019-03-14 11:11 z przez somekind.

Mikroszaleństwo?

Odpowiedz Nowy wątek
2019-03-07 21:33
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?

w jakie klocki? marketingowe chyba ;) - Miang 2019-03-07 22:05
Tak jestes stary - Arek00 2019-03-07 22:20

Pozostało 580 znaków

2019-03-08 09:29
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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2019-03-08 09:30

Pozostało 580 znaków

2019-03-08 09:45
1

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?

edytowany 1x, ostatnio: aurel, 2019-03-09 13:04
Pytaj Jakuba Kubryńskiego. Ale z mojego doświadczenia to się pokrywa. Szczególnie gdy mówimy o branży finansowej. - nie100sowny 2019-03-08 11:26
@nie100sowny: dzięki, ja pracuję na systemach z 1-2 mln LOC i nie wiem czy to nawet jest średniej wielkości system i czy to dobra metryka - MuadibAtrides 2019-03-08 16:02
No to tym bardziej. - nie100sowny 2019-03-08 16:44

Pozostało 580 znaków

2019-03-08 11:57
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.


"Gdy się nie wie, co się robi, to się dzieją takie rzeczy, że się nie wie, co się dzieje"


edytowany 1x, ostatnio: nie100sowny, 2019-03-08 11:59
zależy od definicji Twojego mikroserwisu. Jeśli da się go przepisać w 1-2 tygodnie, to ja widzę nawet kilka na programistę. - Lukxxx 2019-03-09 21:17
@Lukxxx Problem w tym, że jak masz tyle mikroserwisów. To nie ma sensu ich przepisywać, bo problem leży prawdopodbnie w tym, że cały system jest do d**y. I cały kunszt polega na umiejętności reorganizacji tych mikroserwisów, a nie zabawie w przepisywanie. - nie100sowny 2019-03-10 12:01
@nie100sowny: wiesz w praktyce taki system "żyje" i ewoluuje, część serwisów się dezaktualizuje, powstają inne... - Lukxxx 2019-03-10 19:23
@Lukxxx: To tym bardziej tragedia. Bo zamiast robić rename w IntelliJ lub zmieniać interfejs w Javie i najwyżej się nie skompiluje, to majstrujesz przy integracji (REST, kolejki). Jest to bardzo podatne na błędy. - nie100sowny 2019-03-10 19:49

Pozostało 580 znaków

2019-03-08 15:48
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.

Pozostało 580 znaków

2019-03-08 16:14
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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
A jaka jest różnica między SOA a mikroserwisami? To nie jest to samo tylko nazwane inaczej? - wiciu 2019-03-08 16:21
@wiciu Nie, proponuję wygooglowac po prostu i poczytać. Jest masa materiałów na te tematy. - Aventus 2019-03-08 16:37
@Aventus: SOA to termin nic nie znaczący. I think SOA has turned into a semantics-free concept that can join 'components' and 'architecture'. https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html Mógłbyś nam wkleić te wspomniane materiały?. - nie100sowny 2019-03-08 17:07
W sensie że mam wygooglowac coś co samemu można znaleźć? Mógłbym, ale w pracy teraz jestem. - Aventus 2019-03-08 17:14
Może ujmijmy to tak: każdy system oparty o mikroserwisy jest w pewnym sensie również SOA, ale nie każdy system oparty o SOA jest mikroserwisami. SOA nie jest nic nie znaczącym terminem, bo istniał długo zanim pojawiły się mikroserwisy. - Aventus 2019-03-08 17:15
Zresztą spotkać się można z opinią że mikroserwisy to "SOA done right", chociaż ja się nie do końca z tym zgadzam. - Aventus 2019-03-08 17:16

Pozostało 580 znaków

2019-03-10 13:22
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

edytowany 6x, ostatnio: karsa, 2019-03-10 13:39

Pozostało 580 znaków

2019-03-11 00:55
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]

edytowany 1x, ostatnio: InterruptedException, 2019-03-11 00:56
Pokaż pozostałe 2 komentarze
Mnie jakoś te serverless nie jaraja. Imo i tak większość firm potrzebuje 1 Appke która gdzieś można zdeployowac. - karsa 2019-03-13 22:52
Wczoraj Ocada mialo fajne case study na meetupie jak sie mozna przejechac na Kubernetesie. - WhiteLightning 2019-03-13 23:27
@WhiteLightning: mógłbyś podrzucić? bo nie mogę nic z wczoraj znaleźć. - WeiXiao 2019-03-13 23:50
Kubernetes to ogromna armata. Trzeba wiedzieć na co się ktoś decyduje. - karsa 2019-03-14 06:53

Pozostało 580 znaków

2019-03-14 08:49
1

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

Ten wątek jest raz w miesiąc. Co nie umniejsza faktu, że sporo komentarzy jest wartościowych. Pozostałe bingo HN: - serveless is shit - events are harder than you think - FB, Google are pure evil, click and see why - software interview process is broken - enough of white box algo - do I need to know what monad is? - InterruptedException 2019-03-14 23:07

Pozostało 580 znaków

2019-03-17 11:21
0

Większość projektów jak w zalaczniku

Pozostało 580 znaków

2019-03-17 12:02
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.

Pokaż pozostałe 3 komentarze
To jest właśnie architektura którą pozwalam sobie skrytykować. Ale to ich sprawa ;-) - Azarien 2019-03-17 16:52
To ta krytyka nie ma sensu. Kwestia skali, setki serwisow, setki zespolow- nie ma sensu stawianie wszystkiego u siebie, poza kawalkiem. I prędzej to skala 1 zespołu i zabawy w mikroserwisy = patologia a nie na odwrot. - karsa 2019-03-17 16:58
zeby aplikacje bylo ciezko postawic lokalnie to czasami nawet monolit wystarczy :) - WhiteLightning 2019-03-17 17:08
Skoro ja pracuję przy API do obsługi zamówień klientów, to po co mam sobie stawiać lokalnie mikroserwisy do integracji z systemami płatności, konfiguracji towaru albo frontend dla księgowych? A przy budujących się dwie godziny monolitach zdarzało mi się już pracować, i to było dużo mniej przyjemne w pracy niż mikroserwisy. - somekind 2019-03-18 00:19

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: CCBot (2x)

Użytkownik: p_maciek