Mikroservisi: kakšne so in zakaj bi moralo vaše podjetje skrbeti

Področje programske opreme podjetja je zasuto z buzzy tehnologijami. O številnih smo že pisali, naj bo to blockchain, razvoj nizke kode ali drugi nastajajoči trendi, ki spreminjajo način dela. Ena nova govorica, za katero morda še niste slišali, so "mikroservisi".

To je po zasnovi. Mikroservice so drugačen način za arhitekturo programske opreme, ki temelji na naboru prepletenih modularnih komponent, ne pa na tradicionalni zamisli o "monolitu" - aplikaciji, sestavljeni iz ene vedno večje goro kod. Aplikacije, ki temeljijo na mikroservisih, se ne razlikujejo od uporabniškega vmesnika (ne glede na uporabniški vmesnik), ne glede na to, ali gre za kompleksno aplikacijo za podatkovni center ali spletno ali mobilno aplikacijo, ki gostuje v razširljivi infrastrukturi v oblaku.

Razlog, da bi podjetja morala skrbeti za mikroservise, je ta, da lahko arhitektura svojim razvojnim in IT-ekipam pomaga, da hitreje delajo in inovirajo, upravljajo infrastrukturo ter zmanjšajo stroške in zapletenost dodajanja novih funkcij in funkcionalnosti v aplikacijo. Al Hilwa, programski direktor za raziskave programske opreme za razvoj programske opreme IDC-ja, je pojasnil, kako bo mikroservice postavil na eksek, pri tem pa upošteval tudi kulturne in tehnološke izzive.

"Pri gradnji novih sistemov je verjetno ključno spoznanje, da mora eno samo mikroservis zgraditi majhna ekipa, " je dejala Hilwa. "Drugič, toleranco do raznolikosti v programskih jezikih in delovnih procesih razvijalcev pogosto implicira neodvisnost celotne kulture mikroservisov. Glavni cilj izvedbe je graditi programsko opremo postopno z uporabo majhnih skupin, pri čemer vsaka izdela skladen modul z objavljenim Prednost je v tem, da se neodvisni moduli lahko razvijajo precej hitreje, če se objavljeni API-ji upravljajo na organiziran način."

Kaj so res mikroservisi?

Hilwa je leta 2015 napisala poročilo IDC z naslovom "Pojav mikroservisov kot nov arhitekturni pristop k izgradnji novih programskih sistemov." V poročilu opredeljuje mikroservis kot strukturo programske arhitekture, kjer so komponente aplikacij zasnovane in razvijane neodvisno, da izpolnjujejo določene API-je zahteve glede interoperabilnosti (kar pomeni, da so povezane z aplikacijo kot celoto). Kljub temu mikroservisi ne obstajajo v vakuumu. Nova arhitektura zahteva močno organizacijsko podporo in premik v IT kulturi.

Mikroservisov tudi ne opredeljuje nobena posebna tehnologija, ampak kot razvoj dolgoletnega koncepta storitveno usmerjene arhitekture (SOA), ki se je povečal s pojavom zabojnikov in porastom avtomatizacije z razvojnimi pristopi, kot sta nenehna dobava (CD) in nenehna integracija (CI).

"Organizacije, ki danes uporabljajo mikroservis, so navadno motivirane z željo po hitrejšem razvoju storitev, " je dejala Hilwa. "Tako mikroservice v večini takih primerov v veliki meri uporabljajo avtomatizacijo CI / CD. Vendar pa se lahko hitrost dejanske uporabe med storitvami razlikuje. Mislim, da je ključno, da dobro pogledate notranjo kulturo in prepričani ste, da ste pripravljeni dopuščati večjo decentralizacijo in raznolikost v tehnološkem paketu."

Hilwa se s "notranjo kulturo" v veliki meri sklicuje na DevOps, filozofijo, ki združuje razvoj programske opreme, IT-tehnologije in zagotavljanje kakovosti (QA) v enoten delovni potek dela. Zagon programske opreme DevOps HashiCorp in njegovi ustanovitelji so že dolgo zagovorniki mikroservisov. Podjetje, ki je pred kratkim zagotovilo 24 milijonov dolarjev kroga financiranja iz serije B, šteje podjetja, kot so Cisco, DigitalOcean, Mozilla in Stripe, med svoje odprtokodne uporabnike in poslovne stranke.

Mikroservisi so bistvenega pomena za to, kako HashiCorp pristopi k razvoju infrastrukture DevOps in deljenju aplikacij po svojih priljubljenih odprtokodnih orodjih in rastočem podjetniškemu izdelku. Armon Dadgar, CTO in soustanovitelj HashiCorp-a, je z enostavnimi analogijami: Amazon in eBay, razkril razliko med monolitami in mikro servisi.

"O Amazonu in eBayu razmišljajte kot o posameznih aplikacijah. Z vidika končnega uporabnika so videti podobno, toda za kuliso so podjetja uporabila nasprotne pristope, kako so gradila in arhitekturirala svoje aplikacije, " je dejal Dadgar. "Amazon je bil že od začetka paket mikroservisov; deluje kot ena sama aplikacija. Če pa vzamete iskanje, katalog izdelkov, nakupovalno košarico, račune, pretoke naročil in razdelite te funkcije, se dve aplikaciji izvajata na različnih stroji."

Amazonska analogija sega tudi v strukturo samega Amazona. Dadgar pojasnjuje, da so tehnološki pristopi, kot so mikroservisi, orodje za podporo večjega gibanja procesov proti DevOpsu. Jeff Bezos "Pravilo dveh pizz" deluje tako, da je v kateri koli ekipi Amazon le med pet in osem ljudi. Če se ekipa poveča, potem se razdeli na dva.

Amazonova organizacijska hierarhija se začne preslikavati na tisto, kar je Dadgar opisal kot "razgradnjo funkcionalnosti". Vsaka ekipa, ločena tako na organizacijski kot na modularni arhitekturni ravni, ima možnost, da se razvija in eksperimentira svobodneje, ne da bi se bilo treba pri vsaki spremembi usklajevati, vendar še vedno deluje kot del ene same kohezivne aplikacije.

"eBay je uporabil monolitni pristop; ves eBay so zgradili kot dolgo, 50 milijonov vrstico uporabe kode, " je dejal Dadgar. "Mikroservisni pristop je na začetku bolj boleč, ker so težave z modularnostjo in interoperabilnostjo tiste, ki ne obstajajo v monolitu. Toda stvari se začnejo pokvariti, ko aplikacija postane prevelika. V monolitu ni razpada.

"Pomislite na stotine ali tisoče razvijalcev, ki sodelujejo na eni kodni zbirki in poskušajo uskladiti. Skupina za nadzor kakovosti, ki doda funkcionalnost na eni strani aplikacije, lahko na drugi strani nekaj prelomi, ker ni jasnega ločevanja vlog in odgovornosti. začeli boste potrebovati vedno več usklajevanja med vodji projektov in postopkom zagotavljanja kakovosti, ki lahko traja tedne in razvoj ozkega grla, ne glede na to, kako hitro ta ekipa deluje. V kuhinji je preveč kuharjev."

Zabojniki in mikroservisi v svetu razvitih naprav

Način, kako vaše podjetje izvaja arhitekturo mikroservisov, bo daleč do tega, ali bo ugotovilo, ali se naložba izplača ali ne. Mikroservice so veliko vnaprej, zlasti pri integraciji API-ja, ki je potrebna, da se vse storitve pogovarjajo med seboj. Hilwa je pojasnila, da je pri poskusu integracije mikroservisov v obstoječi sistem še bolj zapleteno; priporoča, da podjetja, kadar je le mogoče, gradijo nove sisteme, namesto da bi preuredili zasnovan monolitni program za mikroservis.

"Tradicionalne sistemske arhitekture običajno vključujejo velike, zapletene sisteme zapisov podatkov z zapletenimi normaliziranimi shemami, " je dejala Hilwa. "Vključitev takšnih sistemov v manjše komponente s svojimi neodvisnimi sistemi zahteva veliko dela na načrtovanju baz podatkov in učinkovito prepisuje večino osnovne logike aplikacije. To je v večini primerov stroškovno in časovno prepovedano."

Če preuredite starejšo aplikacijo, vam Hilwa svetuje, da to storite postopno. Čeprav so še pomembnejše od integracije API-ja, mikroservice ne delujejo brez kulture DevOps. HashiCorpov očka je povedal, da mikroservice, ko gre za večji dežnik DevOpsa, postanejo orodje za lažji večji procesni premik k temeljnemu spreminjanju delovnih tokov, s katerimi dostavljamo aplikacije. Pokazal je na Tao HashiCorp, ki je bil ustanovljen, ko je skupaj s ustanoviteljem Mitchelom Hashimotojem ustanovil podjetje: preprosto, modularno in sestavljivo.

"DevOps je v nekem smislu še bolj obremenjen izraz kot mikroservisi, " je dejal oče. "Toda podjetje je sestavljeno iz ljudi z različnimi posebnostmi znanja: razvijalci, operaterji, varnostniki. In potem imate postopek, način, kako organizirate te ljudi. Potem imate orodja, s katerimi lahko podpirate ta proces, kjer so mikroservice in zabojniki vstopi."

Kontejnerji, ki jih je popularizirala eksplozija Dockerja z odprtim virom, še zdaleč niso edino orodje, ki ga podjetja lahko uporabljajo za olajšanje mikroservisov. IDC-jeva Hilwa je dejala, da se posodi uporabljajo v sodobnih aplikacijah kot del delovnih tokov CI / CD, ponekod pa tudi med uporabo v proizvodnji. Vendar je dejal, da lahko mikroservisi uporabljajo tudi virtualne stroje (VM), brez potrebe po zabojnikih.

Glede na to, kako se razvijajo poslovni oblaki, so Docker posode in mikroservisi močna kombinacija orodij, ki jo zajemajo podjetja vseh oblik in velikosti - od zagonov, kot je HashiCorp, do podjetnih velikanov, kot je Oracle. HashiCorpov oče je povedal, da so zabojniki priročno sredstvo, s katerim se Dev in Ops (in po združenju, različne ekipe in službe) med seboj komunicirajo.

"Kakšen je artefakt, ki ga prenašamo med razvijalci in operaterji? Kaj vse temeljito pretakamo in gradimo? Kontejnerji so priročna enota za prehod, " je dejal oče. "Razmislite o globalnem podjetju, ki pošilja izdelke po vsem svetu. Naj gre za tovorno ladjo, tovorni vlak ali tovornjak, gre za isto enoto, ki teče skozi celoten sistem."

DevOps in mikro storitve so še vedno daleč od razširjenega sprejemanja podjetij, vendar trg le raste. Glede na poročilo IDC bo arhitektura mikroservisov v naslednjih petih letih stopila v fazo zorenja. Ta zrelost se bo zgodila za kulturo DevOps, ki bo do leta 2020 dosegla 50 odstotkov organizacij, nenehno razvijanje orodij za avtomatizacijo programske opreme in prevlado poceni, razširljive infrastrukture v oblaku, ki jo zagotavljata Amazon Web Services (AWS) in Microsoft Azure.

Dadgar je dejal, da je HashiCorp, čeprav je majhen del podjetij, ki trenutno zajemajo DevOps in mikroservise, že močno podpisan. Svoj prvi sedemmestni prihodek je dosegel po samo devetih mesecih prodaje podjetij, poleg odprte kode v GitHubu več milijonov aktivnih uporabnikov mesečno. Mikroservisi so le del HashiCorp-ovega orodja za izdelavo delovnih orodij in večjega DevOps-ovega načrta za infrastrukturo. Toda modularnost in interoperabilnost pod vsem, kar podjetje gradi, je spodbudilo meteorni vzpon enega najbolj vročih zagonov programske opreme v Silicijevi dolini.

"Pred štirimi leti, ko smo začeli, bi šli na sestanke in predstavili svojo vizijo o upravljanju infrastrukture, " je dejal oče. "Nismo se ravno smejali iz sobe; vedeli smo, da je že zgodaj. Toda zdaj so naša orodja, kot je Terraform, na poti k postajanju industrijskih standardov. Kar bomo videli, je domino učinek konkurenčnega pritiska in dolgoročno bo naša vloga sodelovala s službami za strateško strategijo in CTO, da bi razumeli premike procesov, ki jih potrebujejo.

"Pomislite na Toyoto čez dan, " je nadaljeval oče. "Imeli ste kup avtomobilskih podjetij, ki izdelujejo izdelke, vendar so bili stroški višji, kot bi morali biti. Toyota ni znova izumila, kaj je avtomobil; bili so samo bolj strogi in postopni glede postopka, in je šla od smeha do elektrarne in silila Preostali del panoge sprejema isti nabor praks, da ostaja konkurenčen. Trenutno vodje v industriji sprašujemo, kako lahko dobijo konkurenčno prednost, njihov odgovor pa je, da sprejmejo prakse Googlov in Amazonov na trgu. točke, zadel bo kritično maso."