Microservicii: ce sunt și de ce ar trebui să le pese de afacerea ta

Peisajul software al întreprinderii este plin de tehnologii zgomotoase. Am scris despre o mulțime de ele, fie că este vorba despre blockchain, despre dezvoltarea codului scăzut sau despre alte tendințe emergente care schimbă modul de lucru. Un nou cuvânt cheie de care nu mai auziți până acum este „microservicii”.

Asta prin design. Microserviciile sunt o modalitate diferită de software-ul arhitect bazat pe un set de componente modulare împletite, mai degrabă decât ideea tradițională a unui „monolit” - o aplicație formată dintr-un munte de cod mereu în creștere. Aplicațiile bazate pe microservicii nu arată altfel decât partea interfață de utilizator (UI), indiferent dacă este într-o aplicație complexă pentru centrul de date sau o aplicație web sau mobilă găzduită pe infrastructura cloud scalabilă.

Motivul pentru care întreprinderile ar trebui să le pese de microservicii este că, în culise, arhitectura vă poate ajuta echipele de dezvoltare și IT să lucreze și să inoveze mai rapid, să gestioneze infrastructura și să reducă costurile și complexitatea adăugării de noi funcții și funcționalități unei aplicații. Al Hilwa, directorul de programe pentru cercetarea software de dezvoltare a aplicațiilor la IDC, a explicat cum va pune microservicii la un executant, ținând cont atât de provocările culturale, cât și de cele tehnologice.

"Atunci când construiți sisteme noi, probabil punctul principal este să recunoașteți că un mic microserviciu ar trebui să fie construit de o echipă mică", a spus Hilwa. "În al doilea rând, o toleranță a diversității în limbajele de programare și a fluxurilor de lucru ale dezvoltatorilor este adesea implicată de natura independentă a unei culturi de microservicii generale. Principalul pas către un exec este să construiască software în mod incremental folosind echipe mici, fiecare construind un modul coerent cu un publicat interfața. Avantajul este că modulele independente pot fi evoluate într-un ritm mult mai rapid independent, atât timp cât API-urile publicate sunt gestionate în mod organizat."

Ce sunt Microservices, într-adevăr?

Hilwa a scris un raport IDC din 2015 intitulat „Apariția microserviciilor ca o nouă abordare arhitecturală pentru construirea de sisteme software noi”. În raport, el definește microserviciile ca o arhitectură software granulară în care componentele aplicației sunt proiectate și evoluate independent pentru a satisface cerințele de interoperabilitate definite de API (adică, legate în aplicație în ansamblu). Microserviciul nu există însă în vid. O nouă arhitectură necesită un sprijin organizațional puternic și o schimbare în cultura IT.

De asemenea, microserviciile nu sunt definite de nici o tehnologie specifică, ci de evoluția conceptului de lungă durată a arhitecturii orientate către servicii (SOA), amplificat de apariția containerelor și de creșterea automatizării prin abordări de dezvoltare, cum ar fi livrarea continuă (CD) și integrarea continuă (CI).

"Organizatiile care folosesc microservicii astazi sunt de obicei motivate de dorinta unui ritm mai rapid de evolutie a serviciilor", a spus Hilwa. "Astfel, în majoritatea acestor cazuri, microserviciile utilizează automatizarea CI / CD într-o mare măsură. Cu toate acestea, ritmul implementării efective poate fi diferit între servicii. Cred că cheia este să aruncăm o privire bună asupra culturii interne și să fie sigur că sunteți dispus să tolerați o mai mare descentralizare și diversitate în stiva tehnologică."

Prin „cultura internă”, Hilwa se referă în mare măsură la DevOps, o filozofie care combină dezvoltarea de software, operațiunile IT și asigurarea calității (QA) într-un singur flux de lucru colaborativ. Startup software DevOps HashiCorp și fondatorii săi au fost de mult timp susținători de microservicii. Compania, care a asigurat recent o serie de finanțare din seria B de 24 de milioane de dolari, numără companii precum Cisco, DigitalOcean, Mozilla și Stripe printre utilizatorii open-source și clienții de întreprindere.

Micro-serviciile sunt esențiale pentru modul în care HashiCorp abordează dezvoltarea infrastructurii DevOps și fluxurile de lucru ale aplicațiilor în instrumentele sale populare open-source și în suita de produse pentru întreprinderi în creștere. Armon Dadgar, CTO și co-fondator al HashiCorp, a doborât diferența dintre monoliti și microservicii, folosind o analogie simplă: Amazon și eBay.

"Gândiți-vă la Amazon și eBay ca aplicații unice. Din perspectiva utilizatorului final, acestea arată similar, dar, în culise, companiile au adoptat abordări opuse în modul în care și-au construit și arhivat aplicațiile", a spus Dadgar. "Amazon a fost de la început un pachet de microservicii; acționează ca o singură aplicație. Dar dacă efectuați căutarea, catalogul de produse, coșul de cumpărături, facturile, fluxurile de comandă și împărțiți aceste funcții, cele două aplicații rulează pe diferite mașini.“

Analogia Amazon se extinde și la modul în care Amazon este structurat. Dadgar explică abordările tehnologice precum microserviciile ca instrumente pentru a sprijini mișcarea mai mare a procesului către DevOps. „Two Pizza Rule” al lui Jeff Bezos funcționează astfel încât doar între cinci și opt persoane sunt pe orice echipă Amazon. Dacă echipa devine mai mare, atunci se împarte în două.

Ierarhia organizațională a Amazonului începe cartografierea către ceea ce Dadgar a descris drept o „descompunere a funcționalității”. Separată atât la nivel organizațional, cât și la nivel de arhitectură modulară, fiecare echipă are apoi capacitatea de a se dezvolta și experimenta mai liber, fără a fi nevoie să se coordoneze la fiecare schimbare - funcționând totuși ca parte a unei singure aplicații coezive.

"eBay a adoptat abordarea monolitică; au construit toată eBay ca o linie lungă de 50 de milioane de aplicații de cod", a spus Dadgar. "Abordarea microservicii este mai dureroasă la început, deoarece problemele de modularitate și interoperabilitate sunt cele care nu există într-un monolit. Dar lucrurile încep să se descompună când aplicația crește prea mare. Într-un monolit, nu există o descompunere.

"Gândiți-vă la sute sau mii de dezvoltatori care colaborează pe o singură bază de cod și încearcă să se coordoneze. O echipă de QA care adaugă funcționalitate pe o parte a aplicației ar putea rupe ceva din cealaltă parte, deoarece nu există o separare clară a rolurilor și responsabilităților. Începeți să aveți nevoie de o coordonare din ce în ce mai mare între managerii de proiect și un proces de QA care poate dura săptămâni și dezvoltarea gâtului, indiferent cât de repede funcționează echipa. Este prea multă bucătărie în bucătărie."

Containere și microservicii într-o lume DevOps

Modul în care afacerea dvs. implementează o arhitectură de microservicii va merge mult până la stabilirea dacă investiția plătește sau nu. Microserviciile lucrează mult mai devreme, în special în integrarea API necesară pentru a vă asigura că toate serviciile vorbesc între ele. Hilwa a explicat că este și mai complicat atunci când încerci să integrezi microservicii într-un sistem existent; el recomandă întreprinderilor să construiască sisteme noi, ori de câte ori este posibil, mai degrabă decât să re-arhitecturați o aplicație monolit pentru moștenire.

„Arhitecturile tradiționale de sistem implică de obicei sisteme mari de baze de date complexe de înregistrare cu scheme elaborate normalizate”, a spus Hilwa. "Factorizarea unor astfel de sisteme în componente mai mici, cu sisteme independente proprii, necesită multă lucrare de proiectare a bazelor de date și rescrierea efectivă a majorității logicii de bază a aplicației. Acest lucru este, în general, prohibitiv în costuri și timp în majoritatea cazurilor."

Dacă re-arhitecți o aplicație veche, atunci Hilwa vă recomandă să o faceți treptat. Deși chiar mai important decât integrarea API, microserviciile nu funcționează fără cultura DevOps din spatele ei. Dadgar-ul lui HashiCorp a spus că, atunci când vine vorba de umbrela mai mare a DevOps, microserviciile devin un instrument pentru a facilita o schimbare mai mare a procesului către schimbarea fundamentală a fluxurilor de lucru prin care livrăm aplicații. El a arătat către Tao of HashiCorp, când el și co-fondatorul Mitchell Hashimoto au început compania: simplă, modulară și compozibilă.

„DevOps într-un anumit sens este un termen și mai supraîncărcat decât microservicii”, a spus Dadgar. "Dar o afacere este alcătuită din oameni cu diferite specialități de cunoștințe: dezvoltatori, operatori, ofițeri de securitate. Și atunci aveți proces, modul în care organizați acei oameni. Apoi aveți instrumentele pentru a susține acel proces, care este locul în care sunt microservicii și containerele. intra."

Containerele, popularizate prin explozia open-source a Docker, sunt departe de a fi singurele întreprinderi de instrumente pe care le pot utiliza pentru a facilita microserviciile. Hilwa IDC a spus că containerele sunt utilizate în aplicațiile moderne ca parte a fluxurilor de lucru CI / CD și, în unele cazuri, în timp ce se desfășoară în producție. Dar el a spus că microserviciile pot folosi și mașinile virtuale (VM), fără a fi nevoie de containere.

Acestea fiind spuse, atunci când vine vorba de modalitățile în care evoluează norii de afaceri, containerele și microserviciile Docker sunt o combinație puternică de instrumente care este îmbrățișată de afaceri de toate formele și dimensiunile - de la startup-uri precum HashiCorp până la giganți de întreprinderi precum Oracle. Dadgar-ul lui HashiCorp a spus că containerele sunt mijloacele convenabile prin care Dev și Ops (și, prin asociere, echipe și servicii diferite) comunică între ei.

"Care este artefactul pe care îl transmitem între dezvoltatori și operatori? Ce curgem minuțios și construim în jurul valorii? Containerele sunt o unitate convenabilă pentru a trece", a spus Dadgar. "Gândiți-vă la un produs de transport maritim pentru întreprinderi la nivel mondial. Fie că este vorba despre o navă de marfă, un tren de marfă sau un camion, este aceeași unitate care curge prin întregul sistem."

DevOps și microservicii sunt încă departe de adoptarea pe scară largă a întreprinderii, dar piața este în creștere. Conform raportului IDC, arhitectura microservicii va intra într-o fază de maturizare în următorii cinci ani. Această maturitate se va întâmpla pe calea culturii DevOps, ajungând la 50 la sută din organizații până în 2020, evoluția continuă a instrumentelor de automatizare a software-ului și dominarea infrastructurii cloud ieftine și scalabile oferite de genul serviciilor web Amazon (AWS) și Microsoft Azure.

Dadgar a spus că, chiar și cu fracția mică a întreprinderilor care angajează DevOps și microservicii în acest moment, HashiCorp este deja mult suprasemnat. Acesta a atins primele sale venituri din șapte cifre după numai nouă luni de vânzări de întreprinderi, în topul unei comunități open-source pe GitHub, de câteva milioane de utilizatori activi lunar. Microserviciile sunt doar o parte a conductei de instrumentare a aplicațiilor pentru fluxul de lucru al HashiCorp și a foii de parcurs a infrastructurii DevOps mai mari. Însă modularitatea și interoperabilitatea sub tot ceea ce construiește compania au alimentat ascensiunea meteorică a uneia dintre cele mai tari startup-uri software din Silicon Valley.

„În urmă cu patru ani, când am început, ne-am duce la întâlniri și ne-am propune viziunea pentru modul în care va fi gestionată infrastructura”, a spus Dadgar. "Nu am râs exact din cameră; știam că este devreme. Dar acum instrumentele noastre precum Terraform sunt pe cale să devină standarde ale industriei. Ceea ce vom vedea este un efect domino al presiunii competitive și, în pe termen lung, rolul nostru va fi colaborarea cu CIO-urile și CTO-urile pentru a înțelege schimbarea procesului pe care trebuie să o facă.

- Gândește-te la Toyota în ziua respectivă, continuă Dadgar. "Aveai o grămadă de companii de construcții de produse auto, dar costul a fost mai mare decât ar trebui. Toyota nu a reinventat ceea ce a fost o mașină; ele au fost doar mai riguroase și incrementale în ceea ce privește procesul și au trecut de la laughingstock la powerhouse, forțând restul industriei să adopte același set de practici pentru a rămâne competitiv. În momentul de față, avem lideri din industrie care întreabă cum pot obține un avantaj competitiv, iar răspunsul lor este să adopte practicile Googles și Amazoanele pieței. punct, va lovi o masă critică ".