Se pare că vârful entuziasmului pentru microservicii a trecut. Nu mai citim de câteva ori pe săptămână articole precum „Cum mi-am mutat monolitul pe 150 de servicii”. Acum aud mai des idei raționale: „Nu urăsc monolitul, mă preocupă doar eficiența”. Chiar am observat câteva migrații . Când treci de la o aplicație mare la mai multe servicii mai mici, va trebui să rezolvi câteva probleme noi. Să le enumerăm cât mai succint.
Instalare: de la chimie de bază la mecanica cuantică
Configurarea unei baze de date de bază și a unei aplicații cu un proces de fundal a fost un proces destul de clar. Public un readme pe Github — și adesea după o oră, maximum câteva ore, totul funcționează, iar eu încep un nou proiect. Adăugarea și rularea codului, cel puțin pentru mediu inițial, se face în prima zi. Dar dacă ne-am aventurat în microservicii, timpul de lansare inițial explodează. Da, acum avem Docker cu orchestrare și un cluster de mașini K8, dar pentru un programator începător, totul devine cu mult mai complicat. Pentru mulți juniori, aceasta este o povară care reprezintă cu adevărat o complexitate inutilă.
Sistemul nu este ușor de înțeles
Să ne oprim un moment asupra juniorului nostru. Cu aplicațiile monolitice, în cazul în care apărea o eroare, era ușor să o urmărești și să treci imediat la depanare. Acum avem un serviciu care comunică cu alt serviciu, care pune ceva într-o coadă pe un bus de mesaje, care procesează un alt serviciu — și aici apare eroarea. Trebuie să adunăm laolaltă toate aceste părți pentru a descoperi în cele din urmă că serviciul A funcționează în versiunea 11, iar serviciul E așteaptă deja versiunea 12. Acesta este un contrast puternic față de jurnalul meu consolidat standard: trebuie să folosesc un terminal interactiv/debugger pentru a parcurge procesul pas cu pas. Depanarea și înțelegerea, în esență, au devenit mai complicate.
Dacă nu putem depana, poate că îi vom testa
Integrarea continuă și dezvoltarea continuă devin în prezent o normă. Cele mai multe aplicații noi pe care le văd, cu fiecare nouă versiune, generează și rulează automat teste, cerând ca acestea să fie trecute și revizuite înainte de înregistrare. Acestea sunt procese excelente de care nu ar trebui să ne despărțim, ele constituind o schimbare semnificativă pentru multe companii. Dar acum, pentru a verifica cu adevărat serviciul, trebuie să lansez o versiune complet funcțională a aplicației mele. Țineți minte acel nou inginer cu un cluster K8 de 150 de servicii? Ei bine, acum vom învăța sistemul nostru CI cum să ridice toate aceste sisteme pentru a verifica că totul funcționează cu adevărat. Probabil că este prea mult efort, așa că vom testa fiecare parte în mod izolat: sunt sigur că specificațiile noastre sunt suficient de bune, API-urile sunt clare, iar eșecul unui serviciu este izolat și nu va afecta celelalte.
Toate compromisurile au un motiv întemeiat. Așa-i?
Există multe motive pentru a trece la microservicii. Am văzut că se face acest lucru pentru mai multă flexibilitate, pentru a scala echipe, pentru performanță, pentru a asigura o mai bună reziliență a serviciului. Dar, în realitate, am investit decenii în uneltele și practicile dezvoltării monolitice, care continuă să evolueze. Lucrez cu profesioniști din diferite tehnologii. De obicei, discutăm despre scalare, deoarece se confruntă cu limitele unui singur nod de bază de date Postgres. O mare parte din discuții se concentrează pe .
Dar întotdeauna mă interesează arhitectura lor. În ce etapă a tranziției către microservicii se află? Este interesant să observ cum tot mai mulți ingineri afirmă că sunt mulțumiți de aplicația lor monolitică. Multe persoane vor beneficia de pe urma microserviciilor, iar avantajele vor depăși obstacolele din calea migrației. Dar personal, dați-mi, vă rog, aplicația mea monolitică, un loc pe plajă - și sunt complet fericit.
Sursa: habr.com
