Mikroservices: hva de er og hvorfor virksomheten din skal bry seg

Bedriftsprogramvarelandskapet er full av myke teknologier. Vi har skrevet om mange av dem, det være seg blockchain, utvikling av lav kode eller andre nye trender som endrer måten vi jobber på. Et nytt buzzword du kanskje ikke har hørt om før, er "mikroservices."

Det er av design. Mikroservices er en annen måte å arkivere programvare basert på et sett sammenvevd modulkomponenter i stedet for den tradisjonelle ideen om en "monolit" - en applikasjon som består av et stadig voksende fjell med kode. Mikroservicebaserte apper ser ikke annerledes ut enn brukergrensesnittet (UI), enten det er i en kompleks datasenter-app eller en nett- eller mobilapp som er vert på skalerbar skyinfrastruktur.

Grunnen til at bedrifter bør bry seg om mikroservices er at bak kulissene kan arkitekturen hjelpe utviklings- og IT-teamene dine til å jobbe og innovere raskere, administrere infrastruktur og redusere kostnadene og kompleksiteten ved å legge til nye funksjoner og funksjonalitet til en app. Al Hilwa, programdirektør for applikasjonsutviklingsprogramvareforskning ved IDC, forklarte hvordan han ville gi mikroservices til en exec mens han husket både de kulturelle og teknologiske utfordringene.

"Når du bygger nye systemer, er sannsynligvis hovedpoenget å erkjenne at en enkelt mikroservice bør bygges av et lite team, " sa Hilwa. For det andre impliseres ofte en toleranse for mangfoldighet i programmeringsspråk og utviklere arbeidsflyter av den uavhengige karakteren av en samlet mikroservicekultur. Hovedhøyden for en exec er å bygge programvare trinnvis ved hjelp av små team, med hver bygning en sammenhengende modul med en publisert Fordelen er at de uavhengige modulene kan utvikles i mye raskere tempo uavhengig så lenge de publiserte APIene administreres på en organisert måte."

Hva er mikroservices, egentlig?

Hilwa forfatter en IDC-rapport fra 2015 med tittelen "The Emerging of Microservices as a New Architectural Approach to Building New Software Systems." I rapporten definerer han mikroservices som en granulær programvarearkitektur der appkomponenter er designet og utviklet uavhengig for å oppfylle API-definerte interoperabilitetskrav (noe som betyr, bundet tilbake til appen som helhet). Mikroservices eksisterer imidlertid ikke i et vakuum. En ny arkitektur krever sterk organisasjonsstøtte og et skifte i IT-kultur.

Microservices er heller ikke definert av noen spesifikk teknologi, men som utviklingen av det mangeårige konseptet for serviceorientert arkitektur (SOA), forsterket av fremkomsten av containere og økningen av automatisering gjennom utviklingsmetoder som kontinuerlig levering (CD) og kontinuerlig integrasjon (CI).

"Organisasjoner som bruker mikroservices i dag er typisk motivert av ønsket om en raskere utvikling av tjenesten, " sa Hilwa. "I de fleste slike tilfeller bruker mikroservices CI / CD-automatisering i stor grad. Imidlertid kan tempoet for faktisk distribusjon være forskjellig mellom tjenestene. Jeg tror nøkkelen er å se godt på den interne kulturen og være sikker på at du er villig til å tolerere større desentralisering og mangfold i teknologibunken."

Ved "intern kultur" refererer Hilwa i stor grad til DevOps, en filosofi som kombinerer programvareutvikling, IT-drift og kvalitetssikring (QA) til en enkelt, arbeidsflyt. Oppstart av DevOps programvare HashiCorp og dets grunnleggere har lenge vært talsmenn for mikroservices. Selskapet, som nylig sikret en runde på $ 24 millioner med serie B-finansiering, teller selskaper som Cisco, DigitalOcean, Mozilla og Stripe blant open source-brukere og bedriftskunder.

Mikroservices er kjernen i hvordan HashiCorp tilnærmer seg DevOps infrastrukturutvikling og app-arbeidsflyter på tvers av de populære open source-verktøyene og den voksende virksomhetsprodukten. Armon Dadgar, CTO og medgründer av HashiCorp, brøt sammen forskjellen mellom monolitter og mikroservices ved å bruke en enkel analogi: Amazon og eBay.

"Tenk på Amazon og eBay som enkeltapplikasjoner. Fra sluttbrukerperspektivet ser de like ut, men bak kulissene tok selskapene motsatte tilnærminger til hvordan de bygde og arkitekterte applikasjonene sine, " sa Dadgar. "Amazon fra begynnelsen har vært et knippe mikroservices; det fungerer som en enkelt app. Men hvis du tar søket, produktkatalogen, handlekurven, fakturaer, ordre strømmer og deler disse funksjonene, kjører de to applikasjonene på forskjellige maskiner."

Amazon-analogien utvides også til hvordan Amazon selv er strukturert. Dadgar forklarer teknologiske tilnærminger som mikroservices som verktøy for å støtte den større prosessbevegelsen mot DevOps. Jeff Bezos "Two Pizza Rule" fungerer slik at bare mellom fem og åtte personer er med på et gitt Amazon-team. Blir laget større, deler det seg i to.

Amazons organisasjonshierarki begynner å kartlegge det Dadgar beskrev som en "dekomponering av funksjonalitet." Atskilt på både et organisatorisk og et modulært arkitekturnivå, har hvert team evnen til å utvikle og eksperimentere mer fritt, uten behov for å koordinere på hver eneste endring - mens den fremdeles fungerer som en del av en samlet sammenhengende app.

"eBay tok den monolitiske tilnærmingen; de bygde hele eBay som en lang kodelinje på 50 millioner, " sa Dadgar. "Mikroservicetilnærmingen er mer smertefull i begynnelsen fordi problemene med modularitet og interoperabilitet er de som ikke eksisterer i en monolit. Men ting begynner å bryte sammen når appen blir for stor. I en monolitt er det ingen spaltning.

"Tenk på hundrevis eller tusenvis av utviklere som samarbeider om en enkelt kodebase og prøver å koordinere. Et QA-team som legger til funksjonalitet på den ene siden av applikasjonen, kan ødelegge noe på den andre siden fordi det ikke er noen klar separasjon av roller og ansvar. Å fikse det, du begynner å trenge mer og mer koordinering mellom prosjektlederne og en QA-prosess som kan ta uker og flaskehalsutvikling, uansett hvor raskt det teamet jobber. Det er for mange kokker på kjøkkenet."

Beholdere og mikroservices i en DevOps-verden

Måten din virksomhet implementerer en mikroservicearkitektur på vil gi en lang vei mot å avgjøre om investeringen lønner seg eller ikke. Mikroservices er mye arbeid på forhånd, spesielt i API-integrasjonen som trengs for å sikre at alle tjenestene snakker med hverandre. Hilwa forklarte at det er enda mer komplisert når du prøver å integrere mikroservices i et eksisterende system; han anbefaler at foretak bygger nye systemer når det er mulig, i stedet for å arkeitere en arvelig monolit-app for mikroservices.

"Tradisjonelle systemarkitekturer involverer typisk store, komplekse databasesystemer med forseggjorte normaliserte skjemaer, " sa Hilwa. "Å faktorere slike systemer til mindre komponenter med egne uavhengige systemer krever mye databasedesignarbeid og omskriving av det meste av kjerneprogrammets logikk. Dette er vanligvis kostnads- og tidsforbudende i de fleste tilfeller."

Hvis du arkitekterer en arv-app, anbefaler Hilwa at du gjør det trinnvis. Selv om det er enda viktigere enn API-integrasjonen, fungerer ikke mikroservices uten DevOps-kulturen bak. HashiCorps Dadgar sa at når det kommer til den større paraplyen til DevOps, blir mikroservices et verktøy for å legge til rette for et større prosessskifte mot fundamentalt å endre arbeidsflytene som vi leverer apper til. Han viste til Tao of HashiCorp som ble lagt ut da han og medgründer Mitchell Hashimoto startet selskapet: enkelt, modulært og komponerbart.

"DevOps i en viss forstand er et enda mer overbelastet begrep enn mikroservices, " sa Dadgar. "Men en virksomhet er sammensatt av mennesker med forskjellige kunnskapsspesialiteter: utviklere, operatører, sikkerhetsansvarlige. Og så har du prosess, slik du organiserer disse menneskene. Da har du verktøyene for å støtte den prosessen, som er der mikroservices og containere kom inn."

Beholdere, popularisert av åpen kildekodeeksplosjonen av Docker, er langt fra det eneste verktøyet foretakene kan bruke for å lette mikroservices. IDCs Hilwa sa at containere brukes i moderne apper som en del av CI / CD-arbeidsflyt, og i noen tilfeller mens de distribueres til produksjon. Men han sa at mikroservices også kan utnytte virtuelle maskiner (VM) uten behov for containere.

Når det er sagt, når det gjelder måtene forretningsskyer utvikler seg, er Docker-containere og mikroservices en kraftig verktøykombinasjon som blir omfavnet av forretninger i alle former og størrelser - fra oppstarter som HashiCorp til bedriftsgiganter som Oracle. HashiCorps Dadgar sa at containere er det praktiske middelet Dev og Ops (og, foreningen, forskjellige lag og tjenester) kommuniserer med hverandre.

"Hva er gjenstanden vi fører mellom utviklerne og operatørene? Hva flyter vi grundig og bygger rundt? Containere er en praktisk enhet å passere rundt, " sa Dadgar. "Tenk på et globalt bedriftsfraktprodukt over hele verden. Enten det er et godskip, et godstog eller en lastebil, er det den samme enheten som strømmer gjennom hele systemet."

DevOps og mikroservices er fortsatt langt fra utbredt adopsjon av bedriften, men markedet vokser bare. I følge IDC-rapporten vil mikroservicearkitekturen gå inn i en modningsfase de neste fem årene. Denne løpetiden vil skje på hælene av DevOps-kulturen og nå 50 prosent av organisasjonene innen 2020, den fortsatte utviklingen av programvareautomatiseringsverktøy og dominansen av billig, skalerbar skyinfrastruktur levert av slike som Amazon Web Services (AWS) og Microsoft Azure.

Dadgar sa at selv med den lille brøkdelen av selskaper som omfavner DevOps og mikroservices for øyeblikket, er HashiCorp allerede enormt overtegnet. Den traff sin første syv-sifrede omsetning etter bare ni måneders salg av bedrifter, på toppen av et open source-community på GitHub med flere millioner aktive brukere hver måned. Mikroservices er bare en del av HashiCorps arbeidsflyt-appverktøy-rørledning og større DevOps infrastruktur veikart. Men modulariteten og interoperabiliteten under alt selskapet bygger har gitt den meteoriske økningen til en av de hotteste programvareoppstartene i Silicon Valley.

"For fire år siden da vi startet, ville vi gå inn på møter og sette visjonen for hvordan infrastruktur ville bli styrt, " sa Dadgar. "Vi lo ikke akkurat ut av rommet; vi visste at det var tidlig. Men nå er verktøyene våre som Terraform på vei til å bli industristandarder. Det vi får se er en dominoeffekt av konkurransepress og i På lang sikt vil vår rolle arbeide med CIOs og CTOs for å forstå prosessskiftet de trenger å ta.

"Tenk på Toyota tilbake på dagen, " fortsatte Dadgar. "Du hadde en haug med bilfirmaer som bygger produkter, men kostnadene var høyere enn den burde være. Toyota fant ikke opp igjen hva en bil var; de var bare strengere og trinnvis om prosessen, og gikk fra lattermild til kraftverk, og tvang resten av bransjen for å ta i bruk samme sett med praksis for å forbli konkurransedyktig. Akkurat nå har vi bransjeledere som spør hvordan de kan få et konkurransefortrinn, og deres svar er å ta i bruk praksisene fra Googles og Amazons i markedet. poeng, vil det treffe en kritisk masse."