Micro-serviciile, un concept și nou și vechi, e din nou la modă. Acum doi ani nu prea îi dădeam prea mare importanță, însă azi dacă aș avea de proiectat un serviciu sau produs nou, aș folosi cu plăcere acest model. Iată câteva dintre motivele mele:
- Sunt mai ușor de întreținut: când o aplicație monolit are un defect, vei fi nevoit să descarci tot codul sursă (de obicei câteva zeci de mii de linii de cod), să reproduci problema și să faci deployment-ul. În cazul unui micro-serviciu ai doar câteva clase și câteva sute de linii de cod – găsirea problemei și rezolvarea ei va fi mult mai ușoară.
- Mai puțin cod rezultă mai puține defecte, și mai ușor de testat.
- De obicei, micro-serviciile oferă mai multe opțiuni de configurare, pentru că depind de alte micro-servicii. Asta face migrarea lor mai ușoară și cuplarea cu alte micro-servicii.
- Mai ușor de scalat, și în multe cazuri și costuri mai mici: fiindcă micro-serviciile de obicei au un scop foarte limitat, poți monitoriza mai ușor și scala doar acele micro-servicii care a căror performanță este direct dependentă de resurse.
- Mai ușor de monitorizat.
- Mai puțin dependente de platformă: doar în cazuri foarte rare, un micro serviciu este dependent de un furnizor de servicii cloud, de exemplu dacă folosești ca micro serviciu un serviciu specific acelui furnizor, cum este Mailchimp sau SES. Dar atunci când îți implementezi propriile servicii le poți face să comunice prin HTTP cu interfețe REST, și ai din start independență față de infrasctructură sau rețea.
Sper că v-am convins să considerați micro-serviciile pentru următorul proiect. Chiar dacă e nevoie de o planificare mai laboriaosă a componentelor și interfeței de comunicare/autentificare e un exercițiu foarte bun.