Each microservice is relatively small
- Easier for a developer to understand
- The IDE is faster making developers more productive
- The web container starts faster, which makes developers more productive, and speeds up deployments
4 Likes
As vrea sa resuscitez thread-ul asta, aveti careva experienta cu migrarea de la un monolit la microservices? A meritat efortul? Ati mai face-o? De ce da, de ce nu?
Menționez ca eu sunt în situația de a analiza aceasta trecere și datorită faptului ca sunt intr-o echipa mică, multe din avantajele lor sunt putin redundante.
Am ceva experiență cu asta - am fost parte din echipa care a mutat o platformă mare monolit de Java + JSP către microservicii de Scala care hrănesc prin REST microservicii de Node + React. În principiu, aș spune că trebuie găsită o balanță potrivită între monolit și microservicii, să tindă mai mult spre „milisercicii” decât „nanoservicii” 
Aparent multe firme cad în plasa de a sparge monolitul în servici foarte mici și, evident, cu cât ai mai multe servicii, cu atât devine mai greu de menținut.
Avantajul cel mai mare este că un fuck-up al unui developer într-un serviciu nu dărămâ toată platforma.
Dezavantajul cel mai mare este atunci când ai nevoie să faci o schimbare pe toată platforma și trebuie să updatezi și deploy fiecare serviciu.
IMHO merită, dar cu măsură. Nu e totul alb și negru - gândiți-vă și la opțiunea de a sparge monolitul în 3-4-5 servicii domain-oriented mai măricele.
7 Likes
Am si eu experienta cu asta, dar nu exista o reteta valabila general, depinde foarte tare de proiect. Mai specific, de business-ul proiectului. In unele cazuri efectiv iti faci mult mai mult de lucru si la final nu o sa fie mai bine (dar hey, ai aderat la movement-ul international de microservices macar… 
).
Eu personal as face urmatoarele:
- analiza la business-ul proiectului, cum ar putea fi impartit
- analiza la stack-ul tehnologic, daca impartiti totul, puteti folosi diferite tehnologii de ex.
- discutat si cu clientul neaparat, pentru ca va fi un timp initial investit masiv si el trebuie sa plateasca asta pana la urma
- pentru Netflix functioneaza super tare asta, dar serviciile lor sunt si total independente, ceea ce nu este tot timpul cazul
- exista multe avantaje, intrebarea este daca merita investitia
Sunt multe de povestit pe tema asta, este greu de oferit un raspuns aici sincer.
1 Like
Discutia asta mi-o amintit de video-ul asta:
2 Likes
Microserviciile rezolva mai mult o problema de echipe: fiecare echipa lucreaza la un microserviciu si trebuie coordonata doar interfata (API-ul) dintre microservicii. Daca sunt echipe clar delimitate, atunci microserviciile vor ajuta. Daca nu, atunci oricum vor fi sedinte fara sfarsit pe tema cine/cum sa schimbe ceva, si nu e mare diferenta fata de un monolit.
Trebuie sa fii constient ca microserviciile au si dezavantaje: schimbari globale trebuiesc coordonate mult mai atent, mai ales cand sunt breaking changes, apar probleme de distributed computing (probleme cu reteaua, probleme de sincronizare, etc). Evaluarea performantei intr-un mediu distribuit e mult mai grea, iti trebuie instrumentare mult mai buna a codului ca sa poti sa vezi “de ce requestul X de la enduser a durat atata”.
5 Likes
Sunt la a 3-a migrare de genul asta. Mie imi plac foarte mult microserviciile insa trebuie avuta mare grija. Merita sa faci asa ceva daca:
- Ai minim 10 oameni in echipa si perspective de a primi buget pentru mai mult. Sa te apuci de ms in 3 oameni e aproape garantia fail-ului.
- microserviciile aduc un overhead imens. Logging, service registration and discovery, distributed tracing, queues, circuit breaker. Apoi echipa trebuie sa inteleaga si niste patternuri care ajuta in structurare sau decuplarea serviciilor existente: api gateway, strangler pattern, aggregator, cqrs, saga. Apoi mai vine si partea de infrastructura(k8s)…deja v-am plictisit
- Daca ai echipa maricica, oamenii au experienta si pot face monoliti decenti si oamenii sunt constienti de overheadul adus de microservicii…atunci are sens. Insa daca nu poti face 1 monolit decent, sigur-sigur nu vei face microservicii decente.
- Are mai mult sens daca nevoia este mai mare pe partea de dezvoltare in paralel versus nevoia de scalabilitate. Din punctul meu de vedere un monolit il scalezi la fel de usor. Insa e diferit cand ai o echipa de Catalog, una de Payments, alta de Search si lucreaza in paralel, fac release in paralel, etc.
Nu va lasati dusi de hype.
10 Likes
Multumesc de pareri, sunt in situatia in care un junior e foarte entuziasmat de “the latest and the greatest”, astea fiind DDD + Microservices si evident ar face orice ca sa capete experienta in acele domenii, chiar daca la sfarsitul drumului “s-ar pune lantul pe usa”.
Noi momentan suntem o echipa super mica (2 persoane) asa ca din ce mi-ati spus voi si din ce m-am mai documentat pare 100% o cale gresita.
4 Likes
n-am lucrat niciodata cu microservicii, doar ceva tutoriale. Si pe mine ma mananca degetele sa transform monolitii pe care lucrez in microservicii, dar se intampla fix ce spune tache, daca nu sunt devi suficienti pentru lucru in paralel, nu are nici un rost, mai mult ma ingreuneaza sa ma plimb dintr-un serviciu in altul cu dezvoltarile, deployuri, cereri servere (practic 10 aplicatii cu toate cele necesare in loc de una, documentatii, etc).
Ce mi se pare mie ca sunt pasi mult mai ok de facut, daca o aplicatie devine suficient de mare cat sa te gandesti la microservicii:
-
- incepi sa o structurezi pe module (3 4 module)
-
- refactorizezi fiecare modul in cate un monolit
-
- daca inca nu te multumeste (sau echipa creste, sau x motive), spargi din nou fiecare monolit in servicii
2 Likes
Poti aplica DDD fara nici o problema pe monolit.
1 Like
Asta si intentionez, doar ca trebuie sa acumulez putin mai multe cunostinte ca sa pot sa o aplic cu incredere. Ai sugestii/sfaturi referitor la asta?
Mie mi-a placut cel mai mult cartea rosie a DDD. Avea o abordare mai practica. De acolo am invatat ca pentru a refactoriza ceva existent la DDD trebuie sa incepi cu un Use-Case.
Practic un Usecase este un Application Service la nivel de cod. Si are un rol destul de clar in aplicatia ta. Gandeste-te ca pe vremuri cand se livra software pe CD, iar pe spatele CD-ului scria ce poti face cu acel software. Exemplu: MS Office. Pai poti vizualiza documente, poti edita documente, le poti printa, etc. Astea sunt use-case-urile aplicatiei tale si de acolo ar cam trebui sa incepi.
Exemplu: ViewDocumentService sau EditDocumentService. Astea folosesc de o entitate Document si un repository(interfata) tot Document. E destul de straight forward ce ar putea face acele clase. Plus ca nu vor depasi 60-70 de linii de cod.
Usor de testat, mockuiesti DocumentRepository si cam aia e. Testezi indirect si acele metode 
P.S. Atentie, un application service nu foloste nimic din infrastructura. Nimic de baze de date, http, etc. Foloste doar entitati sau repository din domain.
4 Likes