Microservices: co jsou a proč by se vaše firma měla starat

Prostředí podnikového softwaru je poseté bzučivými technologiemi. Napsali jsme o mnoha z nich, ať už jde o blockchain, vývoj nízkého kódu nebo o dalších objevujících se trendech, které mění způsob práce. Jedním z nových hesel, o kterých jste možná ještě neslyšeli, jsou „mikroservisy“.

To je záměrné. Mikroservisy jsou odlišným způsobem, jak navrhnout software založený na sadě protkaných modulárních komponent, spíše než na tradičním nápadu „monolitu“ - aplikace tvořená jednou stále rostoucí horou kódu. Aplikace založené na mikroservisech se na straně uživatelského rozhraní (UI) nijak neliší, ať už se jedná o komplexní aplikaci datového centra nebo webovou nebo mobilní aplikaci hostovanou na škálovatelné cloudové infrastruktuře.

Důvodem, proč by se podniky měly o mikroservisy starat, je to, že v zákulisí může architektura pomoci vývojovým a IT týmům pracovat a rychleji inovovat, spravovat infrastrukturu a snižovat náklady a složitost přidávání nových funkcí a funkcí do aplikace. Al Hilwa, programový ředitel pro vývoj softwaru pro vývoj aplikací na IDC, vysvětlil, jak by měl vykonávat mikroskopické služby na exekutivu, přičemž by měl brát v úvahu kulturní i technické výzvy.

„Při budování nových systémů je pravděpodobně klíčovým bodem uznání, že malý tým by měl postavit jeden mikroprocesor, “ řekl Hilwa. „Zadruhé, tolerance rozmanitosti v programovacích jazycích a pracovních postupech pro vývojáře je často implikována nezávislou povahou celkové kultury mikroservisů. Hlavní náskok pro vykonávajícího je stavět software postupně pomocí malých týmů, přičemž každý vytváří soudržný modul s publikovaným Výhodou je, že nezávislé moduly lze vyvíjet mnohem rychleji nezávisle, pokud jsou publikovaná API spravována organizovaným způsobem. ““

Co jsou to opravdu mikroúpravy?

Hilwa napsala zprávu IDC z roku 2015 nazvanou „Vznik mikroprocesorů jako nový architektonický přístup k budování nových softwarových systémů“. Ve zprávě definuje mikroservisy jako podrobnou softwarovou architekturu, ve které jsou komponenty aplikace navrženy a vyvíjeny nezávisle tak, aby splňovaly požadavky na interoperabilitu definované v API (což znamená, že jsou vázány zpět do aplikace jako celku). Mikroservisy však ve vakuu neexistují. Nová architektura vyžaduje silnou organizační podporu a posun v IT kultuře.

Mikroservisy také nejsou definovány žádnou konkrétní technologií, ale jako vývoj dlouhodobého konceptu architektury orientované na služby (SOA), která je posílena příchodem kontejnerů a nárůstem automatizace prostřednictvím vývojových přístupů, jako je nepřetržité dodání (CD) a nepřetržitá integrace. (CI).

„Organizace, které dnes používají mikroprocesy, jsou obvykle motivovány touhou po rychlejším tempu vývoje služeb, “ uvedla Hilwa. „Ve většině takových případů tedy mikroservisy využívají automatizaci CI / CD do značné míry. Tempo skutečného nasazení se však mezi službami může lišit. Myslím, že klíčem je dobře se podívat na vnitřní kulturu a být ujistěte se, že jste ochotni tolerovat větší decentralizaci a rozmanitost v technologické komoře. “

„Interní kulturou“ Hilwa do značné míry odkazuje na DevOps, filozofii, která kombinuje vývoj softwaru, IT operace a zajištění kvality (QA) do jediného kolaborativního pracovního postupu. Spuštění softwaru DevOps HashiCorp a jeho zakladatelé jsou již dlouho zastánci mikroservisů. Společnost, která v nedávné době zajistila 24 milionů dolarů kola financování řady B, počítá mezi své open-source uživatele a podnikové zákazníky společnosti jako Cisco, DigitalOcean, Mozilla a Stripe.

Microservices jsou jádrem toho, jak HashiCorp přistupuje k vývoji infrastruktury DevOps a pracovním postupům aplikací napříč svými oblíbenými open-source nástroji a rostoucí sadou podnikových produktů. Armon Dadgar, CTO a spoluzakladatel společnosti HashiCorp, rozdělil rozdíl mezi monolity a mikroskopickými službami pomocí jednoduché analogie: Amazon a eBay.

"Přemýšlejte o Amazonu a eBay jako o samostatných aplikacích. Z pohledu koncového uživatele vypadají podobně, ale v zákulisí společnosti zaujaly opačný přístup k tomu, jak své aplikace vytvářely a navrhovaly, " řekl Dadgar. „Amazon byl od začátku svazek mikroservisů. Funguje jako jediná aplikace. Pokud však provedete vyhledávání, katalog produktů, nákupní košík, faktury, toky objednávek a tyto funkce rozdělíte, obě aplikace běží na různých stroje. “

Amazonská analogie se také rozšiřuje na strukturu Amazonu. Dadgar vysvětluje technologické přístupy, jako jsou mikroservisy, jako nástroje, které podporují větší pohyb procesů směrem k DevOps. "Two Pizza Rule" od Jeffa Bezose funguje tak, že v daném Amazonském týmu je pouze pět až osm lidí. Pokud se tým zvětšuje, rozdělí se na dvě.

Amazonova organizační hierarchie začíná mapovat to, co popsal Dadgar jako „rozklad funkčnosti“. Každý tým, oddělený jak na úrovni organizační, tak na modulární architektuře, má schopnost svobodněji se vyvíjet a experimentovat, aniž by musel koordinovat každou změnu - a přitom stále funguje jako součást jedné soudržné aplikace.

„eBay použil monolitický přístup; postavili všechny eBay jako dlouhou, 50 milionovou linku aplikace kódu, “ řekl Dadgar. „Mikroobjektivní přístup je na začátku bolestivější, protože problémy s modularitou a interoperabilitou jsou problémy, které u monolitu neexistují. Ale když se aplikace zvětší, začnou se věci rozpadat. V monolitech nedochází k rozkladu.

"Přemýšlejte o tom, že stovky nebo tisíce vývojářů spolupracují na jedné kodexové základně a snaží se koordinovat. Tým QA přidávající funkce na jedné straně aplikace se může na druhé straně něco zlomit, protože neexistuje jasné oddělení rolí a odpovědností. Opravit začnete potřebovat stále větší koordinaci mezi projektovými manažery a procesem QA, který může trvat týdny a zúžit vývoj, bez ohledu na to, jak rychle tento tým pracuje. V kuchyni je příliš mnoho kuchařů. ““

Kontejnery a mikroservisy ve světě DevOps

Způsob, jakým vaše firma implementuje architekturu mikroprocesů, povede dlouhou cestu k určení, zda se investice vyplatí. Microservices jsou hodně práce předem, zejména v integraci API je třeba zajistit, aby všechny služby spolu mluvily. Hilwa vysvětlil, že je to ještě složitější, když se pokoušíte integrovat mikroservisy do existujícího systému; doporučuje, aby podniky budovaly nové systémy, kdykoli je to možné, místo aby přepracovávaly starší monolitickou aplikaci pro mikroprocesy.

"Tradiční systémové architektury obvykle zahrnují velké, komplexní databázové systémy záznamů s propracovanými normalizovanými schématy, " uvedl Hilwa. „Rozdělení takových systémů do menších součástí s jejich vlastními nezávislými systémy vyžaduje hodně práce na návrhu databáze a účinné přepsání většiny základní aplikační logiky. Ve většině případů je to obecně nákladově a časově nepřijatelné.“

Pokud přepíšete starou aplikaci, Hilwa vám doporučuje postupovat postupně. Ačkoliv je ještě důležitější než integrace API, nefungují mikroservisy bez kultury DevOps. HadiCorp's Dadgar řekl, že pokud jde o větší deštník DevOps, mikroservisy se staly nástrojem, který umožňuje větší posun v procesu směrem k zásadním změnám pracovních postupů, kterými dodáváme aplikace. Ukázal na Tao of HashiCorp, který založil, když on a spoluzakladatel Mitchell Hashimoto založili společnost: jednoduchou, modulární a skladatelnou.

„DevOps je v jistém smyslu ještě přetíženější termín než mikroservisy, “ řekl Dadgar. "Ale podnikání se skládá z lidí s různými specialitami znalostí: vývojáři, operátoři, bezpečnostní důstojníci. A pak máte proces, způsob, jakým tyto lidi organizujete. Pak máte nástroje, které tento proces podporují, což je místo, kde se nacházejí mikroobsluhy a kontejnery Vstupte."

Kontejnery, popularizované explozí Dockeru s otevřeným zdrojovým kódem, zdaleka nejsou jediným nástrojem, který mohou podniky použít k usnadnění mikroprocesů. Kontejnery společnosti Hilwa od společnosti IDC se používají v moderních aplikacích jako součást pracovních postupů CI / CD a v některých případech i při nasazení do výroby. Řekl však, že mikroprocesory mohou využívat i virtuální stroje (VM), aniž by bylo potřeba kontejnerů.

To znamená, že pokud jde o to, jak se vyvíjí obchodní mračna, jsou kontejnery a mikroprocesory Docker účinnou kombinací nástrojů, která zahrnuje podnikání všech tvarů a velikostí - od startupů, jako je HashiCorp, až po podnikové giganty, jako je Oracle. HadiCorp's Dadgar řekl, že kontejnery jsou vhodným prostředkem, pomocí něhož Dev a Ops (a asociací různé týmy a služby) spolu komunikují.

„Jaký je artefakt, který procházíme mezi vývojáři a operátory? Co to děláme důkladně a stavíme se kolem? Kontejnery jsou pohodlnou jednotkou, kterou můžeme projít, “ řekl Dadgar. "Přemýšlejte o globálním podnikovém přepravním produktu po celém světě. Ať už jde o nákladní loď, nákladní vlak nebo kamion, je to stejná jednotka, která protéká celým systémem."

DevOps a mikroprocesy nejsou ani zďaleka rozšířené, ale trh jen roste. Podle zprávy IDC vstoupí architektura mikroskopických služeb do fáze zrání v příštích pěti letech. Tato zralost nastane na patách kultury DevOps, která do roku 2020 dosáhne 50 procent organizací, neustálém vývoji nástrojů pro automatizaci softwaru a dominanci levné, škálovatelné cloudové infrastruktury poskytované například Amazon Web Services (AWS) a Microsoft Azure.

Dadgar řekl, že i když malá část podniků, která v současné době zahrnuje DevOps a mikroprocesy, je HashiCorp již nesmírně přepsán. Svých prvních sedmimístných příjmů dosáhl již po devíti měsících podnikových tržeb, a to díky komunitě s otevřeným zdrojovým kódem v GitHubu s několika miliony aktivních uživatelů měsíčně. Microservices jsou pouze součástí potrubí nástrojů pro práci s aplikacemi HashiCorp a většího plánu infrastruktury DevOps. Modularita a interoperabilita pod vším, co společnost buduje, však podpořila meteorický vzestup jednoho z nejžhavějších softwarových startupů v Silicon Valley.

„Před čtyřmi lety, když jsme začali, jsme se chystali na schůzky a představili si naši vizi toho, jak bude spravována infrastruktura, “ řekl Dadgar. „Nebyli jsme se z místnosti úplně smáli; věděli jsme, že to bylo brzy. Ale nyní jsou naše nástroje, jako je Terraform, na cestě k tomu, aby se staly průmyslovými standardy. To, co uvidíme, je dominový efekt konkurenčního tlaku a v Z dlouhodobého hlediska bude naše role ve spolupráci s řediteli CIO a CTO, abychom pochopili posun procesu, který musí podniknout.

„Přemýšlej o Toyota zpět v den, “ pokračoval Dadgar. „Měli jste spoustu stavebních výrobků pro automobilové společnosti, ale náklady byly vyšší, než by měly být. Toyota neobjevila, co to auto bylo; byly o tom procesu přísnější a přírůstkové a šli od smíchu k elektrárně, což nutilo zbytek výrobního odvětví přijmout stejný soubor postupů, aby zůstal konkurenceschopný. Právě teď máme vedoucí představitele odvětví, kteří se ptají, jak mohou získat konkurenční výhodu, a jejich odpovědí je přijetí postupů společnosti Google a Amazonek na trhu. bod, zasáhne kritickou masu. “