Care sunt beneficiile microserviciilor și vor plăti pentru afacerea dvs.?

Publicat: 2022-01-12

Conceptul de microservicii, o abordare a proiectării unei aplicații software ca un set de servicii mici, există cel puțin din 2015. Oferind beneficii precum implementarea independentă și scalabilitatea componentelor, microserviciile sunt la modă astăzi. Acest lucru se datorează faptului că aceste beneficii ale microserviciilor se traduc în viteze de dezvoltare software incredibil de rapide. Cum consumatorii își schimbă rapid preferințele și comportamentele, cei care adoptă microservicii pot ține pasul. Viața este acum grozavă, spun ei. Aproximativ 56% dintre companiile care participă la un sondaj IMB recent intenționează să adopte o abordare de microservicii în următoarele 24 de luni.

Aproape 80% dintre utilizatorii actuali spun că afacerea lor va spori probabil investițiile în microservicii. Avantajele microserviciilor au determinat Netflix, Amazon, eBay, Twitter și mulți alți giganți ai tehnologiei să migreze de la arhitectura monolitică la cea de microservicii. Dar compania dvs. ar trebui să folosească microservicii? Depinde de context și dacă avantajele microserviciilor depășesc dezavantajele aplicației dvs. Acest blog oferă o privire de ansamblu asupra unei abordări microservicii vs. monolitice și cinci beneficii cheie ale utilizării unei arhitecturi de microservicii. De asemenea, împărtășește o parte din experiența ITRex cu microservicii și oferă sfaturi despre când companiile ar trebui (nu) să folosească microservicii. Scufundare in.

Definirea microserviciilor și compararea cu arhitectura monolitică

Ce este o arhitectură de microservicii ? Un stil de microservicii este o abordare a dezvoltării aplicațiilor software native din cloud ca o suită de componente mici sau servicii, care sunt concepute în jurul unui singur flux de lucru de afaceri și lucrează împreună. În esență, microserviciile fac parte dintr-o schimbare fundamentală către DevOps, o cultură în care echipele de dezvoltare și operațiuni IT cooperează strâns împreună folosind instrumente de automatizare pentru a livra mai rapid.

Microservicii:

sunt dezvoltate autonom,
folosesc propria lor bază de date și pot fi scrise în diferite limbi,
comunicați prin intermediul API-urilor cu protocoale ușoare precum HTTP, brokeri de mesaje sau streaming de evenimente și
efectuează o anumită funcționalitate de afaceri.

De exemplu, o aplicație de comerț electronic bazată pe microservicii poate avea servicii independente responsabile pentru imaginile produselor, gestionarea profilului utilizatorului, căutarea, verificarea inventarului, procesarea plăților și expedierea. Partea frontală (partea către client a site-ului web) este decuplată de partea din spate (partea orientată către afaceri), astfel încât este posibil să le personalizați și să le gestionați separat. Dacă luați un exemplu de Amazon, o arhitectură de microservicii ar putea părea copleșitoare, dacă nu terifiantă.

Cu toate acestea, fără a utiliza o arhitectură de microservicii, Amazon ar fi evoluat cu greu într-una dintre cele mai valoroase companii din lume (evaluată cu o capitalizare de piață de 1,694 trilioane USD în decembrie 2021). Decizia de a valorifica beneficiile microserviciilor a fost luată la începutul anilor 2000, când Amazon a înțeles că nu reușește să se extindă cu viteza creșterii bazei de clienți din cauza problemelor de dezvoltare și codificare lente.

Netflix s-a trezit de beneficiile unei arhitecturi de microservicii bazate pe cloud la sfârșitul anilor 2000, după ce nu a putut trimite DVD-uri clienților timp de câteva zile din cauza unei corupții masive a bazei de date. După ce și-au împărțit aplicația în peste 700 de microservicii, inginerii Netflix sunt capabili astăzi să implementeze cod de mii de ori pe zi, permițând companiei să transmită în flux zilnic aproximativ 250 de milioane de ore de conținut către mai mult de 200 de milioane de membri din întreaga lume. Ce arhitectură au folosit aceste vedete din tehnologie și multe alte companii anterior, în zilele pre-cloud? Au folosit monoliți.

Ce este o arhitectură monolitică?

O aplicație monolitică este construită ca o singură unitate care combină toate componentele, inclusiv o interfață utilizator pe partea client, operațiuni pe partea serverului și o bază de date. De obicei, o arhitectură monolitică:

are o singură bază de cod pentru toate funcționalitățile,
este strâns cuplată și
utilizează date centralizate.

O aplicație de comerț electronic dezvoltată folosind o abordare monolitică ar consta în servicii front-end și back-end strâns cuplate, implementate ca o singură unitate, ceea ce înseamnă că orice personalizare ar necesita modificări în baza de cod și platforma front-end (vezi diagrama de mai jos pentru comparaţie).

Aplicațiile monolitice sunt departe de a fi moarte. De fapt, ele pot fi încă o alegere bună, deoarece sunt adesea mai ușor și mai ieftin de construit (cel puțin la începutul lor). Cu toate acestea, vin cu dezavantaje. O schimbare într-o parte, fie în scopul modernizării sau al scalarii, necesită adesea reconstruirea și redistribuirea întregului sistem.

De asemenea, întregul sistem poate fi dărâmat de o parte care se comportă greșit, ceea ce înseamnă că monoliții sunt fragili. Monoliții sunt, de asemenea, greu de întreținut pe măsură ce cresc, iar integrarea cu instrumente terțe nu este nicio bucurie. Aceste dezavantaje sunt greu de ignorat în mediul de piață perturbator de astăzi, în care companiile ar trebui să reacționeze rapid la schimbări pentru a supraviețui și a prospera. De aici și zgomotul despre beneficiile microserviciilor care sunt construite de echipele DevOps.

5 beneficii cheie ale microserviciilor

1. Desfăşurare independentă

Acesta este poate cel mai important avantaj al microserviciilor, cel puțin potrivit lui Sam Newman, unul dintre primii pionieri ai microserviciilor. A face modificări unei aplicații pentru a îmbunătăți performanța sau pentru a adăuga o nouă funcție ca răspuns la nevoile emergente ale utilizatorilor este o briză cu microservicii autonome. Fiecare serviciu poate fi modificat și actualizat fără a atinge întregul sistem. Ele pot fi scalate independent unul de celălalt, de asemenea, dacă o caracteristică este sub încărcare prea mare din cauza solicitărilor în exces. De exemplu, vă puteți mări doar serviciul de procesare a plăților dacă primiți mai multe plăți, fără a crește consumul de resurse de către alte servicii. În acest fel, procesul necesită mai puțină infrastructură și duce la economii de costuri.

2. Raza inferioară a exploziei

Cuplarea liberă a unei arhitecturi de microservicii oferă, de asemenea, un alt avantaj al microserviciilor - o mai bună rezistență. Granițele clare între servicii, împreună cu dimensiunea lor micro, limitează impactul noilor versiuni și asigură izolarea erorilor. O defecțiune a unui serviciu nu elimină funcționalitatea care nu are legătură, restul sistemului rămânând intact și continuând să ofere servicii utilizatorilor.

3. Izolarea datelor

Acesta este un al treilea beneficiu pe care îl oferă microserviciile dacă sunt făcute corect. Suveranitatea datelor per componentă este o caracteristică esențială a microserviciilor. O arhitectură de microservicii face posibilă delimitarea clară a serviciilor care ating datele, ceea ce este esențial, mai ales dacă organizația trebuie să respecte reglementările privind datele de asistență medicală sau GDPR.

4. Utilizarea tehnologiei potrivite

Deoarece aplicațiile monolitice au o singură bază de cod, este dificil să personalizați o abordare tehnologică pentru fiecare funcționalitate și adesea se caută un compromis. Microserviciile, în schimb, sunt concepute în jurul capabilităților de afaceri în mod implicit, permițând echipelor să aleagă cea mai bună tehnologie disponibilă pentru o anumită funcționalitate pentru a profita la maximum de aceasta. Acest lucru se datorează faptului că microserviciile pot folosi diferite tehnologii sau limbaje de programare pentru diferite componente. Microserviciile simplifică, de asemenea, adoptarea celei mai noi tehnologii sau integrarea cu instrumente terțe, după cum este necesar. Absența blocării furnizorului este un alt avantaj al microserviciilor care decurge în mod natural din arhitectura sa slab cuplată.

5. Eficiență

Abordarea microserviciilor permite companiilor să înființeze echipe mici, interfuncționale, în jurul unui serviciu sau a unei suite de servicii care pot funcționa într-un mod agil. Acest model minimizează transferurile atunci când o echipă trebuie să aștepte ca o altă echipă să își finalizeze sarcina, fie că este vorba de implementare sau de testare, înainte de a-și putea începe munca. Fără dependență de altă echipă, viteza de dezvoltare se accelerează. Adoptorii raportează beneficii multiple ale utilizării microserviciilor, potrivit sondajului IMB efectuat pe 1.200 de directori și dezvoltatori IT. Cele mai importante avantaje ale microserviciilor pe care le-au resimțit includ: 30% — Satisfacție mai mare a clienților 29% — Securitate mai bună a datelor companiei/clienți 29% — Timp mai rapid de lansare pe piață 28% — Performanță îmbunătățită a aplicațiilor 27% — O flexibilitate mai mare pentru a extinde resursele sau scădere cu 26% — Productivitate îmbunătățită a angajaților. Există provocări cu microservicii? Ei bine, după cum spune un citat popular, microserviciile nu sunt un prânz gratuit. Citește mai departe.

Partea proastă despre microservicii

1. Complexitate

Complexitatea inerentă a microserviciilor crește odată cu numărul de servicii. Această complexitate este multiplă și atribuită următoarelor:

Controlul de sus în jos la niveluri tehnologice și operaționale este imposibil
Testarea este grea și nu va exista niciodată prea multă automatizare a testelor
Implementarea intercomunicațiilor este dificilă, așa că sunt necesari dezvoltatori talentați
Cantitatea de date înregistrate este prea mare, ceea ce poate duce la inconsecvența acesteia
Pot apărea probleme de compatibilitate cu noile versiuni
Există dificultăți în furnizarea cantității potrivite de resurse

2. Costuri

Microserviciile oferă companiilor mai multe opțiuni de a câștiga bani, dar nu de a-i salva. Pe lângă costul angajării dezvoltatorilor capabili să construiască un mediu complex de microservicii, există facturi pentru cloud și API. Vestea bună este că costurile continue pot fi optimizate în mod semnificativ, deoarece microserviciile utilizează resurse la cerere pe bază de plata pe măsură.

3. Riscuri de securitate

Jumătate dintre respondenții la sondajul IBM au menționat securitatea printre principalele provocări cu care s-au confruntat în călătoria lor de adoptare a microserviciilor. Securitatea trebuie să fie integrată de la început, deoarece fiecare microserviciu are propriul set de puncte de intrare pentru a comunica cu ceilalți prin diferite niveluri de infrastructură, ceea ce duce la o expunere crescută a aplicațiilor la atacuri. În plus, scalarea infrastructurii amplifică riscul de a pierde controlul și vizibilitatea componentelor aplicației.

Când (nu) să folosiți microservicii

Și, în sfârșit, ultima noastră întrebare: când merită arhitectura de microservicii? Deși zgomotul din spatele microserviciilor ca o potrivire naturală pentru aplicațiile native din cloud este garantat, ele nu ar trebui să fie stilul tău implicit. Literatura spune simplu: începeți cu un monolit și împărțiți-l atunci când întâmpinați probleme de scalabilitate sau de consum de resurse sau orice altceva care justifică adoptarea căii microserviciilor.

Iată sfaturile noastre cheie când NU folosiți microservicii:

1. Dacă sunteți un startup, microservicii sunt o idee proastă. Va fi mai înțelept să începeți cu o aplicație monolitică și să o despărțiți în componente mai mici atunci când devine prea dificil pentru o echipă de două pizza. Ceea ce doriți este să efectuați experimente ieftine, mai degrabă decât să investiți mult timp, efort și bani în construirea unei arhitecturi complexe pentru un produs a cărui valoare pentru clienți nu a fost încă validată. Monoliții sunt o modalitate perfectă de a testa (și de a elimina) MVP-urile pentru a afla rapid ce va aduce valoare clienților tăi. După cum spune Martin Fowler, un alt guru respectat al microserviciilor: i) Aproape toate poveștile de succes cu microservicii au început cu un monolit care a devenit prea mare și s-a rupt. ii) Aproape toate cazurile în care am auzit de un sistem care a fost construit ca sistem de microservicii de la zero, a ajuns să aibă probleme serioase. Notă: dacă domeniul produsului este incert, nu ar trebui să utilizați microservicii nici atunci când începeți. S-ar putea să fie prea devreme pentru a trece la decizii arhitecturale complexe, iar este posibil ca abordarea dvs. de a stabili comunicațiile și limitele să fie mult nerezolvată când proiectul dvs. se va maturiza.

2. Microserviciile nu sunt o alegere excelentă pentru o soluție care nu este complexă și poate fi întreținută de o echipă relativ mică. Lansarea unei arhitecturi complexe de microservicii pentru instrumentul de programare a evenimentelor al companiei dvs. ar putea într-adevăr să vă distreze dezvoltatorii, dar va merita toată problema? Microserviciile sunt concepute în primul rând pentru a aborda o singură problemă: complexitatea. După cum afirmă Martin Fowler, „nici măcar nu luați în considerare microservicii decât dacă aveți un sistem prea complex pentru a fi gestionat ca un monolit”.

3. Nu apela la microservicii dacă aplicația ta este prea mică pentru a le justifica. Sistemele dvs. de gestionare a stocurilor sau de achiziție trebuie convertite în microservicii dacă fac perfect ceea ce ar trebui așa cum sunt? Încă o dată, ideea de a folosi microservicii este de a împărți o aplicație complexă într-un set de servicii mai mici. Descompunerea unui cod care este deja mic și simplu ar avea doar efectul de a adăuga complexitate - acum trebuie să navigați prin toate problemele de implementare, interoperabilitate și depanare cu o multitudine de artefacte în loc să implementați întreaga unitate într-un mod de modă veche.

Bine atunci, dar când să folosești microservicii pentru a-și culege beneficiile?

Microserviciile au sens atunci când oricare dintre afirmațiile de mai sus sunt false. Cu alte cuvinte:

Când produsul dvs. evoluează în ceva complex care trebuie îmblânzit sau când doriți să țineți pasul cu schimbările și să adăugați caracteristici importante care altfel sunt imposibil de implementat din cauza blocajelor arhitecturii monolitice.
Când construiți un produs mare și complex cu un domeniu de aplicare definit de la zero. Ori de câte ori o companie dorește să organizeze zeci de dezvoltatori pentru a construi o soluție la scară largă, cu un set clar de caracteristici, ar trebui să ia în considerare crearea de echipe mici, interfuncționale, fiecare responsabilă pentru o singură componentă. În acest fel, fiecare echipă poate lucra independent, cu persoane dedicate care se ocupă de gestionarea API-urilor, conductele de date, schemele și alte capabilități.

Un exemplu corect, din viața reală, din portofoliul ITRex ar fi un instrument intern de securitate cibernetică pe care clientul a dorit să îl transforme într-o platformă Security-as-a-Service. Microservicii s-au potrivit pentru acest proiect, deoarece o arhitectură monolitică pur și simplu nu poate oferi scalabilitatea de care are nevoie o soluție SaaS pentru a servi un număr tot mai mare de clienți, sau flexibilitate pentru a evolua și a rămâne în fața hackerilor.

Un alt proiect ilustrativ a fost o platformă de date mari bazată pe inteligență artificială pentru un retailer global. Clientul nostru și-a dorit o soluție independentă de cloud, construită de la zero. A fost clar de la început că platforma va gestiona tone de date și ar trebui să fie proiectată ca scalabilă pentru a satisface noi surse de date care vor fi adăugate în viitor. De asemenea, a trebuit să luăm în considerare necesitatea de a construi comunicații cu mai multe servicii externe. Deci, realizarea beneficiilor microserviciilor în acest proiect a fost și o strategie naturală. Arhitectura de microservicii ne-a permis să lansăm fără probleme acest sistem complex, folosind Kubernetes pentru orchestrarea microserviciilor și a API-urilor.

Și a existat o oglindă de fitness alimentată cu inteligență artificială, echipată cu camere 3D și un model ML care a venit cu senzori IoT atașați la echipamentul utilizatorului. Componentele sale majore, inclusiv un panou de administrare, o aplicație Android și un sistem de management al regulilor, au fost construite de diferite echipe în diferite etape ale proiectului, fiecare folosind un cod și o arhitectură diferite. Când complexitatea gestionării lor a devenit copleșitoare, am înțeles că trebuie să construim un backend pentru managementul centralizat. Și le-am transformat în microservicii, reproiectându-le codul și creând noi baze de date. Au existat și alte beneficii ale utilizării unei abordări cu microservicii, cum ar fi evitarea codului sau funcționalităților duplicate.

Prin urmare, din experiența noastră, este de preferat să utilizați microservicii atunci când trebuie să gestionați volume de date în creștere, să gestionați complexitățile de interoperare sau să vă asigurați că sistemul dumneavoastră este suficient de flexibil pentru a evolua odată cu afacerea.

Notă de final

Revoluția microserviciilor se desfășoară pe măsură ce companiile realizează avantajele microserviciilor pentru a obține un avantaj pe piață. Beneficiile microserviciilor permit organizațiilor să fie agile și agile pe fondul perturbărilor care au devenit noua normalitate. Fiind capabili să implementeze un software mai bun, mai rapid îi face pregătiți pentru orice urmează după „ce urmează”. Înainte de a urma exemplul, este important să știți ce beneficii ale microserviciilor pot fi disponibile pentru compania dvs. și dacă necazul va fi justificat. În afară de asta, microserviciile pot face minuni.

Încă sunteți confuz dacă compania dvs. ar trebui să se bucure de beneficiile microserviciilor? Luați legătura cu consultanții ITRex. Vă vom ajuta să vă dați seama.

Publicat inițial la https://itrexgroup.com pe 10 ianuarie 2022.