ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 100
Abonament PDF

Confuzia serverless – microservicii

Radu Vunvulea
Solution Architect
@iQuest



PROGRAMARE

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.

Corpul uman

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

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.

Experiența tehnică

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.

Moduri de lucru

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ă.

Nivelul de încărcare (Payloads)

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.

Comunicarea sistemelor

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.

Debugging și monitorizare

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:

Sisteme micro-frontend

Î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.

Câteva gânduri finale

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.

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects