Am dorit să scriu de multă vreme un articol despre arhitectura microserviciilor, însă de fiecare dată m-au oprit două lucruri: cu cât mă adânceam mai mult în subiect, cu atât mai mult mi se părea că ceea ce știu este evident, iar ceea ce nu știu necesita încă multă studiere. Pe de altă parte, consider că deja există suficiente lucruri de discutat pentru o audiență mai largă. Așadar, sunt binevenite opiniile alternative.
Legea lui Conway și legătura dintre afacere, organizație și sistemul informațional
Îmi permit din nou să citez:
„Orice organizație care proiectează un sistem (în sens larg) va obține un design al cărei structură copiază structura echipelor din acea organizație”
— Melvyn Conway, 1967
În opinia mea, această lege este mai degrabă legată de viabilitatea unei organizații de afaceri, decât direct de sistemul informațional. O să explic printr-un exemplu. Să presupunem că avem o oportunitate de afaceri destul de stabilă, cu un ciclu de viață suficient de lung încât să aibă sens să organizăm o întreprindere (nu este o greșeală de tipar, dar îmi place foarte mult acest termen pe care l-am preluat). Desigur, sistemul care susține această afacere va corespunde organizațional și procesual acestui tip de afacere.
Orientarea în afaceri a sistemelor informaționale
O să explic printr-un exemplu. Să considerăm o oportunitate de afaceri pentru organizarea unei afaceri de vânzare de pizza. În versiunea V1 (să o numim pre-informațională), compania reprezenta o pizzerie, o casă de marcat, un serviciu de livrare. Această versiune a fost de lungă durată în condiții de mică volatilitate a mediului înconjurător. Apoi a venit versiunea 2 — mai avansată și capabilă să utilizeze un sistem informațional ca bază pentru afacere cu o arhitectură monolitică. Și aici, în opinia mea, apare o nejustificată nedreptate față de monolite — se spune că arhitectura monolitică nu corespunde modelului domenial al afacerii. Dacă ar fi așa, sistemul nu ar putea funcționa deloc - contrar aceleași legi a lui Conway și bunului simț. Nu, arhitectura monolitică se aliniază pe deplin modelului de afaceri în această etapă de dezvoltare a afacerii - mă refer, desigur, la etapa în care sistemul a fost deja creat și pus în funcțiune. Un fapt absolut remarcabil este că, indiferent de abordarea arhitecturală, atât arhitectura orientată pe servicii versiunea 3, cât și arhitectura pe microservicii versiunea N vor funcționa la fel de bine. Care este capcana?
Totul curge, totul se schimbă sau microserviciile sunt un instrument de combatere a complexității?
Înainte de a continua, să analizăm câteva concepții greșite legate de arhitectura microserviciilor.
Suporterii utilizării abordării microserviciilor spun adesea că deschiderea monolitului în microservicii simplifică procesul de dezvoltare prin reducerea bazei de cod a fiecărui serviciu. Din punctul meu de vedere, această afirmație este pur și simplu absurdă. Serios, interacțiunea evidentă în cadrul monolitului și a codului omogen pare complicată? Dacă ar fi fost cu adevărat așa, toate proiectele ar fi fost inițial construite ca microservicii, în timp ce practica arată că migrarea din monolit în microservicii este cu mult mai frecventă. Complexitatea nu dispare, ea se transferă pur și simplu din module individuale în interfețe (fie că sunt magistrale de date, RPC, API și alte protocoale) și sisteme de orchestrare. Și asta este complicat!
Avantajul utilizării unui stoc heterogen este, de asemenea, discutabil. Nu voi contesta că este posibil, dar în realitate este rar întâlnit (Ca o anticipare - ar trebui să existe - dar mai degrabă ca un rezultat, decât ca un avantaj).
Ciclul de viață al produsului și ciclul de viață al serviciului
Uitați-vă din nou la diagrama de mai sus. Nu am evidențiat întâmplător ciclul de viață în scădere al fiecărei versiuni a afacerii - în condițiile actuale, accelerarea trecerii afacerii între versiuni este determinantă pentru succesul acesteia. Succesul produsului este definit de viteza de testare a ipotezelor de afaceri în acesta. Și aici, din punctul meu de vedere, se află cheia avantajului principal al arhitecturii microserviciilor. Dar să o luăm pe rând.
Să trecem la următorul nivel de evoluție a sistemelor informaționale — arhitectura orientată pe servicii SOA. Așadar, la un moment dat, am diferențiat în produsul nostru servicii durabile — durabile în sensul că, atunci când trecem între versiunile produsului, există șanse ca ciclul de viață al serviciului să fie mai lung decât ciclul de viață al unei noi versiuni a produsului. Ar fi logic să nu le schimbăm deloc — pentru noi este importantă rapiditatea cu care trecem la următoarea versiune. Dar din păcate, suntem nevoiți să facem modificări constante în servicii — și aici se potrivesc toate, de la practici DevOps, la containerizare, și altele — tot ce îți vine în minte. Dar asta nu sunt încă microservicii!
Microserviciile ca mijloc de a combate complexitatea… gestionarea configurației
Și aici putem, în sfârșit, să ajungem la rolul definitoriu al microserviciilor — acesta este un mod de a simplifica gestionarea configurației produsului. Mai exact, funcția fiecărui microserviciu descrie o funcție de afaceri în cadrul produsului conform modelului de domeniu — iar acestea sunt lucruri care nu există în versiuni de scurtă durată, ci în oportunități de afaceri de lungă durată. Și trecerea la următoarea versiune a produsului se întâmplă, în mod literal, fără a fi observată — schimbi/adaugi un microserviciu, iar poate doar schema interacțiunii lor și, dintr-o dată, te regăsești în viitor, lăsând în urmă concurenții plângând care continuă să sară între versiunile monolitilor lor. Acum imaginează-ți că ai un volum suficient de mare de microservicii cu interfete și oportunități de afaceri clar definite. Și vii și construiești structura produsului tău din microservicii gata făcute — doar desenând un diagramă, de exemplu. Felicitări — ai o platformă — și acum poți să îți implementezi afacerea. Visuri, visuri.
Conclusions
- Arhitectura sistemului ar trebui să fie definită de ciclul de viață al componentelor sale. Dacă componenta trăiește în cadrul versiunii produsului — nu are sens să crești complexitatea sistemului, aplicând abordarea microserviciilor.
- Arhitectura microserviciilor ar trebui să se bazeze pe modelul de domeniu — din motivul că oportunitatea de afaceri este domeniul cu cea mai lungă durată.
- Practici de livrare (practici DevOps) și orchestration au o importanță semnificativă pentru arhitectura microserviciilor — deoarece creșterea vitezei de modificare a componentelor impune cerințe mai mari pentru viteza și calitatea livrării.
Sursa: habr.com
