Folositi microservicii in productie ?
In ce limbaje ?
Acum ma distrez cu asa ceva 
https://quarkus.io/
Sau cat de lung sau scurs ar trebui sa fie o aplicatie ca sa se cheme microserviciu ? 
Este fain ebook-ul acela. Il voi citi pe indelete.
Well, am folosit in limbajul Go unde ai avantajul ca faci extrem de usor un server pentru fiecare microserviciu ceea ce iti da posibilitatea sa obtii o performanta deosebita si scalabilitate pe orizontala. Daca e cazul se poate face o aplicatie care schimba date cu microserviciile pe protocoale standard (HTTP, JSON, etc) si centralizeaza lucrurile. Asa ai o alternativa extrem de buna la aplicatiile monolit si mai mult, poti dezvolta aplicatia oricat fara sa suferi in performanta.
Un alt avantaj e mentenanta pe care o poti face individual pe microserviciu fara sa afectezi infrastructura plus alte trucuri si posibilitati.
Totusi am observat ca din pacate tehnologia e destul de prost inteleasa si chiar combatuta in favoarea aplicatiilor monolit. In general multi consiera ca ea complica si mai mult lucrurile dar consider ca treaba asta depinde exclusiv de tehnologia folosita. Daca mergi pe un stack web clasic probabil va fi un cosmar dar pe un Go sau ceva similar le fluieri.
Unii mai adevarati le folosesc cu Docker si Kubernetes dar eu nu am ajuns (inca) pe acolo…
3 Likes
Java e un limbaj oribil pentru microservicii, cu graalvm tot nu e destul de rapid.
Partea bună e că se caută java low-latency developers, doar că nu e ușor.
Eu zic că e obligatoriu sa faci orchestrare și monitorizare la microservicii. Partea urâtă e la deployment dacă n-ai orchestrare, un serviciu poate pornește înainte să pornească unul de care depinde și după de ăla depind alte servicii și se pot complica lucrurile. Adică ceva va porni, dar doar pe jumătate și dacă nu gândești din start cum să se verifice că au pornit corect atunci o sa ai multă bătaie de cap.
Există servicii de la AWS, GCP care fac asta automat sau poți folosi ceva librărie/aplicație specifică limbajului. Docker nu e destul fiindcă dacă rulează vm-ul nu înseamnă că e up și serviciul cu toate dependențele.
Javascript/NodeJS, PHP, .net/core, scala. In cel mai recent proiect folosim .net core (2.2) care merge foarte bine comparativ cu nodejs pentru anumite tipuri de taskuri.
Sunt unul din haterii arhitecturii deoarece a devenit un buzzword și toată lumea vrea sa folosească microservicii chiar dacă nu se justifica. E o arhitectura care se potrivește unor situații foarte particulare si personal nu am avut proiect unde sa fi ajuns la concluzia ca ar fi adus ceva in plus.
Am participat la doua proiecte gen Start-Up care aveau finanțare de ordinul milioane $ și sa decis din prima zi sa se facă o arhitectura complexa pe care sa se lucreze 6+ luni fara o validare a ideii de business. In ambele cazuri trebuia început cu un monolit si MVP care sa se faca in timp cat mai scurt și pe măsura ce se validează sau nu ideea de business si se schimba cerintele sa se spargă in bucati sau sa se refactorizeze dacă e necesar.
Ce am mai observat lucrand cu ambele este ca o arhitectura pe microservicii nu duce obligatoriu la o calitate mai buna a codului, dacă ai scris cod naspa monolit vei face fel și folosind microservicii.
Un articol care mie mi-a placut:
7 Likes
Desigur ma refer la situatiile unde se preteaza pentru ca si acolo sunt evitate. Una din aceste situatii o reprezinta aplicatiile de tip ERP.
Well, din ce spui tu acolo pare ca s-a amestecat proiectarea cu implementarea si cu analiza de piata… nu sunt sigur ca e cel mai bun exemplu.
Daca implementarea este gresita, nu inseamna ca arhitectura pe microservicii nu este buna. Poti livra destul de rapid si nu trebuie sa ai un monolit, validezi fiecare microserviciu separat. Poti realiza un REST API si testa ceea ce livrezi cu Postman, sau iti faci teste unit / api / ce vrei…
Se referea la ideea de business, nu la cum testezi aplicația. Clientului nu-i pasă de Postman-ul tău 
și dacă serviciul pe care-l oferi nu e util acestuia, atunci poți să fii beton tehnic, tot degeaba.
2 Likes
-
Vorbeste despre Start-Up cu finantare e cateva milioane $. Pe ce anume pe o idee care nu este buna? Pe un plan de business care nu este ok?
-
Cu ce difera un monolit care ia 6 luni de 3 microservicii care sunt gata tot in 6 luni? Cum te opreste un microserviciu din a avea un MVP?
Un soft beton din punct de vedere tehnic dar care nu face ce vrea “business-ul” e ani lumina mai bun decat un soft care nu merge deloc dar “face” (adica nu face, ca nu merge) ce vrea business-ul.
Habar n-am, dar dacă el și-a pus problema că ideea nu e valid(at)ă, atunci nu-l pot contrazice, că nu știu despre ce e vorba. 
Asta din perspectiva ta, un developer care consideră că munca lui e cea mai importantă din toată compania și că toți ceilalți încurcă sau ar trebui să se întoarcă la cratiță. 
2 Likes
Ai dreptate. Faptul ca soft-ul e nefunctional nu e o problema. Adica asa e la noi 
Am trecut peste comparația mere-cu-pere, adică soft perfect făcut tehnic și cu toate feature-urile funcționale vs. soft care nu funcționează deloc, deci am considerat că „soft nefuncțional” e doar unul cu un codebase prost scris și care, eventual, are probleme de perfomanță pe ici-colo și/sau cu o mentenanță greu de făcut.
Sunt convins că de fapt asta voiai să compari ca să fie cât de cât logic, nu?
Nu stiu de ce s-a adus in discutie calitatea codului vs microservicii pentru ca nu au o legatura directa 
. Nu folosesti conceptul de microserviciu in arhitectura aplicatiei ca sa imbunatatesti calitatea codului, care tine exclusiv de priceperea programatorului, ci ca sa obtii scalabilitate si performanta pe termen lung.
Desi cuvantul de microserviciu te-ar cam duce cu gandul si la lungimea/marimea codului, in fapt definitia lui (general acceptata) nu are nicio treaba cu asta. Un microserviciu este un serviciu nu neaparat de sine statator care face numai o parte mica din nevoile business ale unui soft. Deobicei, intre ele, microserviciile sunt conectate printr-un protocol lightweight.
Mi se pare ca Nanoserviciul este defapt la ce ne gandim noi deobicei. Un serviciu de sine statator care rezolva o singura nevoie cam cum ar face o biblioteca.
Comentariul respectiv se referea la aspectul de “buzzword” al tehnologiei. Nu am spus ca tehnologia nu e buna ci ca e folosita in multe locuri unde nu ar fi necesar.
Din experienta mea este o diferenta enorma intre cele doua arhitecturi ca si costuri de implementare si utilizare si acest aspect vroiam sa evidentiez (estimativ ar fi un 3x-5x). In exemplul de mai sus ar fi fost diferenta de 2 luni implementare monolit vs 6 luni microservicii cu o echipa mai mica. Sunt curios sa vad si alte pareri pe tema asta de la cei care au lucrat cu ambele si au dezvoltate produse care au ajuns in productie si cum au rezolvat problemele specifice arhitecturii (si care ar fi problemele de care sau lovit).
Avand rolul de rotita in sistem ai incredere in layerul de business de deasupra ca si-a facut temele si ca investeste banii cu cap. Acest lucru nu e totdeauna adevarat independent de suma investita.
1 Like
Noi am inceput sa folosim si cerinta a fost clara: nu conteaza ca le numim microservicii, macro, nano, microliti sau Nelu, vrem sa facem releaseuri in paralel in mai multe zone de business.
Mementan avem 1 in productie as we speak. Performanta foarte buna. E scris in PHP. Folosim si MySQL, Redis, gRPC, RoadRunner, Apache Mesos si Docker.
Ne mai jucam(proof-of-concept) si cu alte forme de abordare precum GraphQL, REST sau chiar arhitecturi diferite precum CQRS si comunicare Event-Driven cu Kafka.
Concluziile mele(si nu numai) e ca gRPC e o tehnologie a dracului de misto. Nu e ok insa sa o folosesti cu PHP pentru ca suporta nativ doar clienti php(nu si servere) si pierzi unul din principalele selling point al grpc: bi-directional streaming. I know, Spiral si Roadrunner vin sa rezolve problema asta(grpc server pentru php apps) dar tot nu ai(si nu cred ca vom avea vreodata) suport pentru client server si/sau bi-directional streaming.
As fi vrut sa ma joc si cu Apache Thrift dar nu am avut timp. Daca are cineva experienta cu Thrift + PHP il rog sa scrie aici concluziile lui si zau daca nu imi iau weekendul sa il testez mai pe indelete. In teorie ce face grpc face si thrift doar ca thrift a fost scris de facebook. Deci ma astept sa stie php pe server.
PHP la noi e requirement obligatoriu. I know, << insert language name here >> is 1M times better than PHP, dar csf, n-ai csf.
3 Likes
Language doesn’t matter
Microserviciile sunt language agmostic. Sau asa ar trebui sa fie
Doua lucruri de care eu mam lovit ca si limitari ale arhitecturii microserviciu si care nu sunt probleme pe monolit:
-
Tranzactii
Presupunand ca ai un sistem gen shopping cart cu produse, stocuri cum rezolvi folosind o arhitectura de microservicii o operatie de cumparare presupunand ca implica modificarea entitatilor din domenii diferite si microservicii diferite. -
Raportare
Vrei sa faci un raport de vanzare pe sistemul de mai sus care implica entitati din microservicii diferite.
2 Likes
In teorie da, in practica e bine sa ti pe un limbaj sau 2-3 maxim. Sunt costuri extrem de mari legate de a avea un limbaj in productie : de la expertiza echipei cu limbajul, la tot tooling-ul din jur - logging, monitoring, integrarea cu metehnele companiei.
Aproape ca as numi ca o trasatura negativa a microserviciilor asta - ca iti permite “prea usor” sa incerci un limbaj nou.
3 Likes