De ce eșuează migrările la microservicii — și cum să le eviți

Problema nu e tehnică

Există un mit persistent în industria software: că migrarea la microservicii este o problemă de arhitectură. Nu este. Datele arată că proiectele care eșuează o fac de obicei în primele trei luni — înainte ca vreo componentă nouă să intre în producție. Motivele sunt organizaționale: echipe care nu au autonomia necesară să ia decizii de deployment, management care aprobă arhitectura distribuită fără să înțeleagă ce înseamnă operarea ei, și contracte de livrare care nu lasă loc pentru iterații. Microserviciile cer o cultură organizațională specifică înainte de orice decizie tehnologică. Fără ea, nu faci modernizare — faci un monolit distribuit, care e mai costisitor și mai greu de depanat decât originalul.

Un cadru de evaluare înainte de start

Prima întrebare: câte echipe diferite vor fi responsabile de componente distincte, și au ele autoritate reală de deployment? A doua: există monitoring centralizat capabil să coreleze trace-uri distribuite — nu doar dashboarduri de server? A treia: bugetul de operare post-migrare a fost estimat și aprobat, inclusiv costul serviciilor managed pentru orchestrare? A patra: există un plan de rollback testat pentru primele șase luni? A cincea: echipa a mai operat servicii cu SLA individual definit? A șasea — și cea mai ignorată: există un proprietar de produs care înțelege că livrarea de funcționalități va încetini în primele șase-doisprezece luni? Dacă răspunsul la oricare din primele cinci este negativ, amânarea migrării nu este o slăbiciune — este decizia corectă din punct de vedere ingineresc.