ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 78
Abonament PDF

Drumul de la Monolit la Microservicii în lumea SaaS

Bogdan Nădișan
Digital Technology Architect @ Accenture



PROGRAMARE


În ultimii șase ani, împreună cu o echipă foarte bună de programatori, am lucrat la realizarea unei noi aplicaţii Enterprise. La momentul începerii proiectului, tehnologia disponibilă era destul de prematură, astfel încât am avut la dispoziţie doar variante alpha şi beta a mai multor librării (MVC5, WebAPI2, Entity Framework 6, KnockoutJS, jQuery, kendoUI). Şase ani mai târziu, tehnologia s-a maturizat. Acum avem pe piaţă o aplicaţie Enterprise, care a fost implementată cu succes la mai mulți clienţi din diferite părţi ale lumii. Recent, clientul care vinde acest produs a făcut o pivotare a modelului de business spre SaaS.

În acest articol nu voi încerca să expun avantajele şi dezavantajele unui monolit, respectiv ale unei arhitecturi bazate pe microservicii, ci mai degrabă doresc să prezint rezultatele cercetării făcute de noi pentru trecerea de la o arhitectură monolit la una bazată pe microservicii, având în vedere un model de business SaaS, cu deployment în cloud (AWS, mai exact).

Contextul

Aplicaţia are o arhitectură pe mai multe nivele. Acestea sunt DataLayer, BusinessLayer şi ServiceLayer, iar deasupra ServiceLayer-ului este o aplicaţie HTML5, construită ca o colecţie de SPA-uri (Single Page Application).

Toate nivelele aplicaţiei care sunt sub layerul de HTML5 şi deasupra RDB-ului rulează în acelaşi proces, ceea ce face ca aplicaţia să ruleze ca un monolit.

Schema este simplă, însă pentru a înţelege mai bine magnitudinea proiectului, găsiţi în continuare mai multe detalii despre conţinut:

Statisticile de mai sus au fost extrase din ultima rulare SonarQube, din pipeline-ul de Continuous Integration al proiectului.

Figura 1 - Arhitectura multinivel

Provocarea

Avem o aplicaţie care pune la dispoziţie o varietate de functionalităţi ce pot fi folosite în integrare cu terţe aplicaţii sau chiar pentru aplicaţii nou create.

Dacă dorim să expunem funcţionalităţile într-un business model SaaS, atunci ar trebui să luăm în considerare diverse aspecte tehnice, cum ar fi: "Costs of deployment", "Data Governance/Data segregation", "Multi tenancy", "Privacy", "Compliance", "Security", "Availability" and "Technology".

Soluţia

Microservicii

Termenul de microservicii este deja un buzz-word bine cunoscut, iar în domeniul nostru este un termen în jurul căruia s-au pornit multe dezbateri. Fără să intru într-o asemenea dezbatere şi fără să pornesc discuţia definirii termenului de microservicii, iată câteva provocări cu care ne-am întâlnit concret şi pe care am dorit să le rezolvăm folosind acest concept:

  1. La fiecare start-up al unui monolit, acesta consumă multe resurse, chiar dacă procesul e latent. În cazul în care am vrea să scalăm o anumită capabilitate a monolitului, trebuie să scalăm de fapt, tot monolitul, cu toate funcţionalităţile sale, ceea ce crește preţul deploymentului pentru clienţi.

  2. Restricţii privind mediul de deployment în care se rulează aplicaţiile. În cazul nostru, folosind tehnologii .NET, suntem mai mult sau mai puţin dependenţi de Windows OS.

  3. Mărimea aplicaţiei poate încetini procesul de pornire (Cold Start-up).

  4. La fiecare versiune la care facem release, e nevoie să facem redeploy la tot monolitul, ceea ce implică mai multe riscuri.

  5. Complexitatea codului şi a funcţionalităţii.

  6. Un singur technology stack de development. Vrem să luăm în considerare chiar şi folosirea altor tehnologii care sunt foarte potrivite pentru implementarea anumitor capabilităţi.

  7. Fiabilitate (Memory Leaks/Exceptiile netratate au un impact mai mare asupra aplicaţiilor de tip monolit).

Decuplează capabilităţi, nu cod

Aşadar, cum trecem de la o arhitectură monolit la o abordare bazată pe microservicii?

Încearcă să te uiţi la monolitul la care lucrezi şi gândeşte-te la ce capabilităţi oferă. Odată ce le vei înţelege în profunzime, ia în considerare extragerea codului ce face referire la una dintre aceste capabilităţi sau chiar consideră rescrierea acesteia de la zero. Dacă ai în perspectivă rescrierea, atunci ai opţiunea de a alege tehnologia care se potriveşte cel mai bine cu acea capabilitate specifică.

Porneşte de la separarea capabilităţilor simple şi separate deja; astfel poţi să exersezi acest proces pentru a-l aplica şi pe capabilităţile mai complexe.

Capabilitatea de autentificare este un exemplu de capabilitate marginală, ceea ce o face, în teorie, mai uşor de separat.

Începe cu "Macroservicii"

Extrage "macroservicii" în prima instanţă. Este mai important să extragi o capabilitate specifică ce aduce valoare produsului decât să extragi doar cod. Atenția trebuie orientată către capabilităţi, nu pe cod; codul e doar un tool care produce capabilităţi.

De exemplu, în procesul de decuplare a capabilităţilor unui sistem de ECommerce, programatorii ar putea porni de la extragerea unui singur serviciu de tip "buy", în care să înglobeze atât conţinutul coşului de cumpărături, cât şi capabilitatea de cumpărare ("check-out"). Acest serviciu poate să fie considerat "macroserviciu" în ideea în care din capabilitatea de mai sus se poate extrage ulterior o capabilitate de "check-out". Aceşti paşi sunt benefici procesului de a sparge un monolit în bucăţi mai mici.

"Slice"-urile capabilităţilor

Când separi capabilităţile pe "slice"-uri, încearcă să o faci vertical. Dacă e posibil, încearcă să atingi toate layerurile monolitului.

De exemplu:

Figura 2 - Arhitectura multinivel împreună cu verticalele tehnice

În imaginea de mai sus, pe partea dreaptă, se observă cum toate nivelele au acum un "slice" vertical, bazat pe capabilităţi specifice (reprezentate în diferite culori: fiecare culoare reprezintă o capabilitate), ce pot fi transformate în noi aplicaţii, rezultând noi microservicii. Fiecare capabilitate poate avea amprente diferite pe fiecare nivel. De aceea, efortul de a extrage o anume capabilitate diferă în funcţie de impactul pe care îl are asupra monolitului.

Cum se face separarea

Paşii de urmat pentru separarea unei noi capabilităţi:

Tehnologii folosite

Într-o arhitectură de tip monolit, când construieşti o nouă capabilitate, tehnologia pe care o vei folosi este în general constrânsă de tehnologia în care a fost scris monolitul. De exemplu, dacă construieşti o nouă capabilitate într-un monolit scris în .NET, va trebui să te limitezi la .NET; acelaşi lucru se aplică la Java sau alte tehnologii.

Într-un mediu bazat pe microservicii, atunci când construieşti o nouă capabilitate, ai puterea şi flexibilitatea să alegi tehnologia care se potriveşte capabilităţii ce urmează să o creezi.

Figura 3 - Arhitectura multinivel împreună cu verticalele tehnice și funcționale

Chiar dacă am separat trei capabilităţi din monolit, drumul până la un ecosistem bazat doar pe microservicii continuă. Faptul că ai monoliţi mai mici sau "macroservicii" nu înseamnă că drumul e greşit; orice "slice" reuşeşti să scoţi din monolit, e un pas în faţă.

Însă, să nu uităm că, pentru a putea vinde produsul la care lucrăm în continuare, trebuie să livrăm noi funcţionalităţi pe piaţă în timp record. Totdeauna trebuie să încercăm să punem în balanţă efortul de a livra rapid cu timpul investit în livrarea capabilităţii ca un microserviciu.

AWS

Înainte de a separa monolitul în bucăţi mai mici - microservicii, în cazul în care ştii că urmează să faci deployment pe o platformă cloud, e indicat să investighezi ce servicii sunt deja disponibile pe acea platformă pe care vei lansa produsul sau capabilitatea implementată.

Acest lucru este necesar deoarece platformele cloud pot avea servicii gata de folosit şi nu mai este necesar să le construieşti tu.

Desigur că trebuie să fii atent atunci când alegi să foloseşti un serviciu al unei platforme și vei deveni "tightly-coupled" cu acea platformă. Dacă planifici să suporţi diverse platforme could (Azure/AWS/Alibaba), va trebui să iei în considerare construcţia unui nivel de abstractizare deasupra serviciilor cloud pe care plănuieşti să le foloseşti.

Mai jos, este un exemplu de deployment a trei noi capabilităţi (reprezentate în diferite culori - în secțiunea de private subnet) ce au fost extrase din monolit, împreună cu aplicaţia monolit.

Figura 4 - Scenariu de deployment AWS multiregiune

Capabilităţile pot rula fie în instanţe de EC2, fie Serverless ca funcţii lambda. În diagrama de mai sus, acestea sunt deployed ca funcţii lambda.

Iată câteva dintre serviciile AWS pe care considerăm să le folosim:

Orchestrarea

Să presupunem că avem o colecţie de microservicii care ar trebui executate într-o ordine specifică şi configurabilă, cu un anumit nivel de atomicitate şi cu un nivel ridicat de interacţiune între acestea.

Pentru această orchestrare, am luat în considerare aplicaţii ce pot invoca servicii REST şi SOAP într-un mod configurabil. În cazul nostru, am decis să folosim Mendix.

Cu Mendix poţi crea ceea ce ei numesc "microflows". Un "microflow" îţi permite să exprimi schema logică a aplicaţiei SaaS. Acest microflow poate efectua acţiuni precum invocarea serviciilor REST şi SOAP într-un mod visual şi configurabil, fără a fi nevoie să scrii cod. Pe lângă invocări de servicii, ai posibilitatea să creezi entităţi şi view-uri pe care le poţi folosi pentru a face diferite transformări care sunt în general necesare pentru a îndeplini contractele microserviciilor. Trebuie să repet că funcţionalităţile de mai sus se pot face doar prin configurare.

Un exemplu de orchestrare prin configurare în Mendix se poate vedea în Figura 5.

Figura 5 - Exemplu de Mendix Microflow

Concluzie

Construirea unui produs SaaS pentru aplicaţii Enterprise este o încercare complexă. SaaS de abia a început să pătrundă în lumea Enterprise, în principal pentru aplicaţii noi. Adoptarea SaaS este condusă, evident, de business. Cu toate acestea, credem că în timp, mai multe aplicaţii "legacy" vor fi înlocuite de către SaaS, iar această tranziţie va fi accelerată odată ce produsele Enterprise SaaS se vor maturiza şi vor îndeplini cerinţele reale Enterprise.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

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

INTERVIURI VIDEO