Acum șase ani, am început să lucrez la primul proiect legat de microservicii. Era vorba de migrarea de la o soluție monolitică la ceva diferit, la containere și microservicii. Acum în 2020, în TOATE proiectele la care lucrez, avem containere, dar mai avem și altceva - componenta serverless.
Provocările de acum șase ani sunt, în majoritatea cazurilor, rezolvate deja de instrumentele folosite și de produsele care sunt parte a ecosistemului microserviciilor. Integrările disponibile azi - furnizori cloud (e.g., Microsoft Azure), load balancers, IDE, instrumente de debugging - le permit programatorilor să dezvolte soluții bazate pe microservicii la fel de ușor precum ar dezvolta o aplicație de tip consolă.
Reversul medaliei este lipsa cunoștințelor avansate legate de modul în care funcționează microserviciile și componenta serverless. Presiunea de a livra rapid, în conformitate cu metodologia agile, face ca bunele practici și consecințele anumitor decizii să fie ignorate. De exemplu, adesea se evidențiază multe sisteme de producție unde mentenanța unei soluții serverless este un fișier text și un editor versatil de text. Aceasta era o soluție bună pentru 2015, dar azi poate crea confuzie și poate ascunde cauza reală a problemelor.
Nu vă așteptați să găsiți soluții. Doresc să atrag atenția asupra unor aspecte mai puțin cunoscute când lucrăm pe proiecte serverless sau cu microservicii. Răspunsurile sunt deja disponibile pe piață, iar noi trebuie să le folosim.
Când vizualizez o soluție realizată cu microservicii și serverless mă gândesc la corpul uman. Diferitele organe sunt containerele care au fiecare câte o responsabilitate primară și poate câteva suplimentare. Organele trebuie să comunice unele cu altele. Pot funcționa o vreme, chiar dacă un alt organ ia o pauză, dar dependințele dintre organe este mare. Interfața dintre ele este bine definită, iar ochii noștri, urechile, gura sau mâinile sunt punctele de integrare cu sistemele externe. Ştim cum să ne menținem corpul, cum să comunicăm cu corpul nostru, cum să îl reparăm. Adesea, ignorăm toate aceste lucruri când construim un sistem IT complex bazat pe arhitectură serverless și pe microservicii.
Viitorul este deja aici! Microserviciile și componenta serverless nu pleacă nicăieri. Nu există nicio competiție între aceste două componente - viitorul le are pe ambele în vedere, în simbioză, din moment ce, în majoritatea cazurilor, codul pe care îl scrii poate rula în ambele moduri.
Gândiți-vă că 73% dintre companiile care planifică să folosească una dintre cele două abordări le consideră deja extrem de benefice pentru realizarea aplicațiilor. Aproape 65% dintre companii deja construiesc soluții cu abordarea bazată pe serverless și microservicii.
După cum puteți observa, viitorul este deja aici. Există o cerere foarte mare din partea pieței, avem instrumentele potrivite, dar vom ignora principiile de bază pe care le respectam acum 5-10 ani.
Raportul ''State of Microservices 2020" oferit de "The Software House" a reprezentat o sursă de inspirație pentru mine. Folosind datele furnizate de ei, am identificat foarte ușor lucrurile pe care echipele au uitat să le integreze, să le ia în considerare, să le abordeze. În multe cazuri, respectarea acestor principii poate face diferența dintre succesul sau eșecul unui proiect.
Nu este greu să găsim programatori cu 10 sau 15 ani de experiență. Chiar și așa, când căutăm oameni cu experiență în microservicii, aproape 50% dintre oameni au sub un an de experiență. Dacă căutați experiență cu serverless, procentele sunt și mai mici. Aceasta este cauza principală pentru care soluțiile bazate pe serverless și microservicii nu funcționează corespunzător, iar rezultatul este că rularea, operațiunile și îmbunătățirea funcționalităților sunt dificile și costisitoare.
Orchestrarea acestor soluții nu se poate reduce la simplitatea unei singure funcții. Sunt necesare instrumentele potrivite și procesele potrivite, iar lipsa personalului cu experiență (mai puțin de 7.5% cu mai mult de 5 ani de experiență) face dificilă reușita din prima iterație.
Aproape tot timpul, o echipă care începe să lucreze cu serverless și microservicii este entuziasmată și fericită în primele sprinturi. Apoi se acumulează multă frustrare, iar înainte de a merge în producție, mai mult de 58% dintre echipe sunt nefericite cu modul în care se fac debuggingul și mentenanța.
Acest lucru se întâmplă, deoarece furnizorii cloud precum Azure oferă medii scalabile, iar guvernanța cloud nu este realizată așa cum ar trebui tot timpul. Echipele pot să-și mărească numărul de core-uri sau consumul cu 40% fără a oferi foarte multe explicații. Acest lucru poate ascunde probleme de performanță sau implementare.
Da, serverless și microserviciile îmbunătățesc eficiența muncii și a echipei. Deși problemele de performanță pot fi ascunse ușor, definirea relațiilor contractuale stabile dintre componente nu este atât de ușoară.
Mai mult de 65% dintre soluțiile care folosesc containere rulează deja în cloud. Migrarea spre cloud se va face ușor atâta timp cât soluțiile folosite pentru sistemele on-premises pot fi folosite și în cloud.
De la bun început, cele mai multe din soluțiile hibrid și multi-cloud sunt construite pe această infrastructură. Chiar dacă AWS Lambda este preferată de 62% dintre soluțiile cloud bazate pe servicii, Azure Functions au un avantaj mare, deoarece pot rula oriunde (e.g., cluster Kubernetes on-premises).
Fiecare furnizor cloud oferă un model specific pentru a construi o astfel de soluție (e.g., AWS Serverless Application Model). Mai puțin de 26% dintre proiecte folosesc bune practici și recomandări în realizarea soluțiilor. Restul proiectelor nu iau în considerare aceste practici. Aceasta este una dintre cauzele principale ce poate genera costuri adiționale și întârzieri.
Dacă adăugăm presiunea de a realiza soluții multi-stack și multi-cloud, cu așteptarea falsă că echipele vor fi mai rapide deoarece 'componentele' (funcțiile) sunt mai simple, avem o rețetă perfectă pentru dezastru.
Mai mult de 66% din sistemele curente includ un sistem de comunicare internă între servicii, iar aproape 57% dintre ele comunică cu un frontend static. Din păcate, SSR frontends nu sunt comune (mai puțin de 27%) când folosim serverless și microservicii, ceea ce poate crea fricțiune între echipele backend și frontend.
Ați putea spune că avem deja metode standard care să ghideze comunicarea în interiorul acestor soluții, dar datele curente spun ceva cu totul diferit. Chiar dacă în 76% dintre proiecte folosim comunicare directă prin intermediul HTTP(s) sau gRPC, vedem că în jur de 43% dintre soluții folosesc evenimente. Dacă punem acest 43% lângă faptul că 63% dintre proiecte folosesc message brokers, ne dăm seama că echipa tehnică nu distinge clar evenimentele de mesaje. Acest lucru poate degenera foarte ușor și poate crea probleme de comunicare și de performanță când dorim să folosim un sistem de mesaje care să trimită un număr mare de evenimente sau dacă ne așteptăm ca evenimentele să persiste la fel de mult ca mesajele.
Deși suntem în 2020 și aproape 85% dintre soluții folosesc loguri, mai puțin de 34% dintre ele folosesc date metrice și monitorizează informația în timpul investigațiilor. Aceste lucru este îngrijorător, deoarece această informație este crucială când facem investigații, iar lipsa lor poate ascunde cauza principală a problemelor. Nu vreau să-mi imaginez cum se face debugul unei soluții ce are 30 de funcții și 20 de microservicii ce folosesc doar fișierele din loguri. Este imposibil. Înțelegerea contextului, atunci când apare o problemă, este dificil dacă nu avem date metrice I/O de exemplu.
Viitorul trebuie să ne furnizeze toleranță la eroare și predicții inteligente despre căderile de sistem (system failures). Acest lucru e posibil doar dacă adunăm toate informațiile legate de aplicație, audit, date metrice, viabilitate. Există multe instrumente ce pot fi folosite:
Auditul poate fi folosit de Falco pentru a detecta anormalitățile.
Monitorizarea se poate face ușor cu Grafana sau Prometheus ce pot analiza viabilitatea, datele metrice, componentele counter, logurile.
Debuggingul se poate face direct din IDE pentru aplicație (e.g., Visual Studio, shell), iar containerele efemere pot oferi un sandbox izolat unde putem analiza statusul curent, init, logurile, containerele și viabilitatea podului.
Când aveți probleme cu un container, trebuie să verificați următoarele:
Există acel serviciu?
Am rulat un test pentru acel serviciu?
Am conexiunile corecte între servicii și pods?
Am mapat corect porturile dintre servicii și pods?
Împărțirea unei soluții în funcții multiple și microservicii permite oamenilor să delege responsabilitatea de la o echipă la alta. Momentan, mai puțin de 24% dintre echipe folosesc sisteme micro-frontend, chiar dacă aceasta reprezintă viitorul realizării soluțiilor.
În general, avem câte o echipă pentru fiecare funcție a unui domeniu, responsabilă de gestionarea a 1-2 servicii. Pe lângă acest lucru, avem un nivel de agregare și o echipă frontend care, pe lângă realizarea componentei frontend trebuie să se alinieze cu toate echipele backend și trebuie să înțeleagă flowul de date și cum se poate consuma funcționalitatea expusă.
Când avem o abordare micro-frontend, responsabilitatea echipei acoperă toate nivelele, de la date la backend și frontend. Comunicarea în interiorul echipei este mai ușoară, toate funcționalitățile pot fi acoperite, asigurând succesul echipei și al proiectului.
Viitorul este aici. Serverless și microserviciile vor deveni modul standard de a construi nu doar sisteme complexe, ci vor deveni standardul industriei de programare a componentei backend.
Trebuie să înțelegem peisajul complet creat de serverless și de microservicii. Aici ne referim la instrumentele folosite, metodologia de a face debugging și modul de lucru. Modul clasic de a construi software poate funcționa prin intermediul noii abordării a modului de realizare a arhitecturii. Totuși, limităm ceea ce putem obține și modul în care facem dezvoltare, debug sau utilizăm astfel de soluții.
de Jari Laakso
