A vállalati szoftverkörnyezet tele van buzzy technológiákkal. Nagyon sokról írtunk, legyen szó a blokkláncról, az alacsony kódfejlesztésről vagy más felmerülő tendenciákról, amelyek megváltoztatják a munkamódszert. Egy új szóbeszéd, amelyről korábban még nem hallottál, a "mikroszolgáltatások".
Ez a tervezés szerint. A mikroszolgáltatások a szoftverek architektúrájának különféle módjai, amelyek összefonódott moduláris összetevők halmazán alapulnak, nem pedig a „monolit” - az alkalmazás egy folyamatosan növekvő kódhegyéből álló - ötletén alapul. A mikroszolgáltatásokon alapuló alkalmazások nem különböznek a felhasználói felület (UI) oldalától, függetlenül attól, hogy egy összetett adatközpont-alkalmazásban, vagy egy méretezhető felhő-infrastruktúrán üzemeltetett webes vagy mobilalkalmazásban található-e.
A vállalkozásoknak azért érdekli a mikroszolgáltatásokat, hogy a színfalak mögött az architektúra elősegítheti fejlesztői és informatikai csapatainak gyorsabb innovációt és innovációt, az infrastruktúra kezelését, és csökkentheti az alkalmazások új funkcióinak és funkcionalitásainak hozzáadása költségeit és összetettségét. Al Hilwa, az IDC alkalmazásfejlesztő szoftver-kutatási program igazgatója elmagyarázta, hogyan fogja a mikroszolgáltatásokat végrehajtóra tenni, miközben szem előtt tartja mind a kulturális, mind a technológiai kihívásokat.
"Új rendszerek felépítésekor valószínűleg a legfontosabb szempont annak felismerése, hogy egy kis csapatnak egyetlen mikroszolgáltatást kell építenie" - mondta Hilwa. "Másodszor, a programozási nyelvek és a fejlesztői munkafolyamatok sokféleségének toleranciáját gyakran az átfogó mikroszolgáltatási kultúra önálló jellege vonja maga után. Az exe fő feladata a szoftver fokozatos létrehozása kis csoportok segítségével, mindegyik egy koherens modul elkészítésével egy közzétett publikációval. Előnye, hogy a független modulok sokkal gyorsabban fejlődhetnek egymástól függetlenül, feltéve, hogy a közzétett API-kat szervezett módon kezelik."
Mik valóban a mikroszolgáltatások?
Hilwa elkészítette az IDC 2015. évi jelentését, mely a "Mikroszolgáltatások megjelenése új építészeti megközelítésként új szoftverrendszerek felépítéséhez" címet viseli. A jelentésben a mikroszolgáltatásokat egy granulált szoftver-architektúraként határozza meg, ahol az alkalmazás összetevőit úgy tervezik meg és fejlesztették ki, hogy azok megfeleljenek az API által meghatározott interoperabilitási követelményeknek (azaz az alkalmazás egészéhez kapcsolódva). A mikroszolgáltatások azonban nem léteznek vákuumban. Az új architektúra erős szervezeti támogatást és az informatikai kultúra megváltozását igényli.
A mikroszolgáltatásokat szintén nem határozza meg egyetlen speciális technológia, hanem a szolgáltatásorientált architektúra (SOA) régóta kialakult koncepciójának fejlődésével, amelyet a konténerek megjelenése és az automatizálás növekedése fejlesztett olyan megközelítések révén, mint a folyamatos szállítás (CD) és a folyamatos integráció (CI).
"A mikroszolgáltatásokat használó szervezeteket általában a szolgáltatás gyorsabb fejlődésének vágya motiválja" - mondta Hilwa. "Tehát a legtöbb ilyen esetben a mikroszolgáltatások nagymértékben használják a CI / CD-automatizálást. Ugyanakkor a tényleges telepítés üteme eltérő lehet a szolgáltatások között. Úgy gondolom, hogy a kulcs a belső kultúra megfelelő áttekintése és a biztos, hogy hajlandó elviselni a nagyobb decentralizációt és sokféleséget a technológiai halomban."
A "belső kultúrán" Hilwa nagyrészt a DevOps-ra utal, egy olyan filozófiára, amely a szoftverfejlesztést, az informatikai műveleteket és a minőségbiztosítást (QA) egyesíti egyetlen, együttműködési munkafolyamatban. A DevOps szoftver indítása A HashiCorp és annak alapítói régóta a mikroszolgáltatások támogatói. A nemrégiben 24 millió dolláros B sorozatú finanszírozást biztosító társaság a nyílt forráskódú felhasználók és vállalati ügyfelek körébe sorolja a Cisco, a DigitalOcean, a Mozilla és a Stripe társaságokat.
A mikroszolgáltatások alapvető szerepet játszanak abban, hogy a HashiCorp hogyan közelíti meg a DevOps infrastruktúra fejlesztését és az alkalmazások munkafolyamatait a népszerű nyílt forráskódú eszközök és a növekvő vállalati termékcsomag segítségével. Armon Dadgar, a CTO és a HashiCorp társalapítója, egy egyszerű analógiával szüntette meg a monolitok és a mikroszolgáltatások közötti különbséget: Amazon és eBay.
"Gondolj az Amazonra és az eBay-re mint egyetlen alkalmazásra. A végfelhasználó szempontjából hasonlóak, ám a színfalak mögött a vállalatok ellentétes megközelítést alkalmaztak az alkalmazásuk felépítésében és felépítésében" - mondta Dadgar. "Az Amazon a kezdetektől egy mikro-szolgáltatáscsomag volt; egyetlen alkalmazásként működik. De ha a keresést, a termékkatalógust, a bevásárlókosárot, a számlákat, a rendelési folyamatokat elválasztja, és ezeket a funkciókat megosztja, akkor a két alkalmazás különböző gépek.”
Az Amazon analógiája kiterjed az Amazon felépítésére is. Dadgar a technológiai megközelítéseket, például a mikroszolgáltatásokat, úgy magyarázza, mint eszközöket, amelyek támogatják a nagyobb folyamatmozgást a DevOps felé. Jeff Bezos "Két pizza szabálya" úgy működik, hogy az Amazon csapata csak öt és nyolc ember között van. Ha a csapat nagyobb lesz, akkor ketté oszlik.
Az Amazon szervezeti hierarchiája megkezdi annak feltérképezését, amit Dadgar "a funkcionalitás bomlásának" nevez. A szervezeti és a moduláris architektúra szintjén elkülönítve minden csapatnak ezután lehetősége van szabadon fejleszteni és kísérletezni anélkül, hogy minden változtatást össze kellene hangolnia - mindazonáltal továbbra is egyetlen összetartó alkalmazás részeként működik.
"Az eBay a monolitikus megközelítést alkalmazta; az egész eBay-t hosszú, 50 millió soros kód alkalmazásként építették fel" - mondta Dadgar. "A mikroszolgáltatási megközelítés eleinte fájdalmasabb, mivel a modularitás és az interoperabilitás problémái nem léteznek egy monolitban. De a dolgok elkezdenek bomlani, amikor az alkalmazás túl nagyra növekszik. A monolitban nincs bomlás.
"Gondolj arra, hogy a fejlesztők százait vagy ezreit együttműködnek egyetlen kódbázison és megpróbálják koordinálni. Az alkalmazás egyik oldalán funkcionalitást hozzáadó minőségbiztosítási csapat tönkremehet a másik oldalon, mert nincs egyértelmű a szerepek és a felelősség szétválasztása. akkor egyre több koordinációra van szüksége a projektmenedzserek és a minőségbiztosítási folyamat között, amely hetekig tarthat, és szűk keresztmetszet kialakulhat, függetlenül attól, hogy a csapat működik milyen gyorsan. Túl sok szakács van a konyhában."
Konténerek és mikroszolgáltatások egy DevOps világban
Az a mód, ahogyan vállalkozása megvalósítja a mikroszolgáltatási architektúrát, nagyban megmutatja annak meghatározását, hogy a beruházás megtérül-e vagy sem. A mikroszolgáltatások nagy előrelépést jelentenek, különösen az API-integráció során, amely biztosítja, hogy minden szolgáltatás beszéljen egymással. Hilwa kifejtette, hogy még bonyolultabb, ha megpróbáljuk integrálni a mikroszolgáltatásokat egy meglévő rendszerbe; azt ajánlja, hogy a vállalkozások a lehető legjobban építsenek ki új rendszereket, ahelyett, hogy újraterveznének egy régi monolit alkalmazást a mikroszolgáltatásokhoz.
"A hagyományos rendszer-architektúrák általában nagy, összetett adatbázis-rendszereket tartalmaznak, bonyolult normalizált sémákkal" - mondta Hilwa. "Az ilyen rendszerek tényleges méretezése kisebb összetevőkbe saját független rendszereivel sok adatbázis-tervezési munkát igényel, és az alapvető alkalmazási logika nagy részének hatékony átírását igényli. Ez a legtöbb esetben általában költség- és időigényes."
Ha újra épít egy régi alkalmazást, akkor Hilwa azt javasolja, hogy tegye ezt fokozatosan. Noha az API-integrációnál még fontosabb, a mikroszolgáltatások nem működnek anélkül, hogy mögötte lenne a DevOps kultúra. A HashiCorp Dadgar elmondta, hogy amikor a DevOps nagyobb esernyőjére kerül sor, a mikroszolgáltatások eszközévé válnak, amely megkönnyíti a nagyobb folyamatváltást az alkalmazások szállítását szolgáló munkafolyamatok alapvető megváltoztatása felé. Rámutatott a HashiCorp Tao-ra, amelyet akkor állítottak fel, amikor ő és társalapítója, Mitchell Hashimoto megalapította a társaságot: egyszerű, moduláris és összeállítható.
"A DevOps bizonyos értelemben még inkább túlterhelt kifejezés, mint a mikroszolgáltatások" - mondta Dadgar. "De egy vállalkozás különböző tudással rendelkező emberekből áll: fejlesztők, üzemeltetők, biztonsági tisztviselők. És akkor megvan a folyamatod, ahogyan ezeket az embereket megszervezted. Akkor rendelkeznek eszközökkel a folyamat támogatásához, ahol a mikroszolgáltatások és konténerek állnak rendelkezésre. bejön."
A Docker nyílt forráskódú robbanása által népszerűsített konténerek messze nem az egyetlen eszköz, amelyet a vállalatok használhatnak a mikroszolgáltatások megkönnyítésére. Az IDC Hilwa elmondása szerint a konténereket a modern alkalmazásokban használják a CI / CD munkafolyamatok részeként, és bizonyos esetekben a termelésbe való beépítés során. De azt mondta, hogy a mikroszolgáltatások virtuális gépeket (virtuális gépeket) is kihasználhatnak konténerek nélkül.
Ugyanakkor, amikor az üzleti felhők fejlődésének módjáról van szó, a Docker konténerek és a mikroszolgáltatások hatékony szerszámkombináció, amelyet minden formájú és méretű vállalkozás magában foglal - kezdő vállalkozásokatól, például a HashiCorp-tól az olyan vállalati óriásokig, mint az Oracle. A HashiCorp Dadgar szerint a konténerek a kényelmes eszközök, amelyekkel a Dev és az Ops (és együttesen különféle csapatok és szolgáltatások) kommunikálnak egymással.
"Mi az a tárgy, amelyet átadunk a fejlesztők és az üzemeltetők között? Mire alaposan átépítünk és építünk? A konténerek kényelmesek az áthaladáshoz" - mondta Dadgar. "Gondolj egy globális vállalati szállítási termékre az egész világon. Akár teherhajó, tehervonat vagy teherautó, ugyanaz az egység áramlik át az egész rendszeren."
A DevOps és a mikroszolgáltatások még mindig messze vannak a széles körű vállalati alkalmazástól, de a piac csak növekszik. Az IDC jelentése szerint a mikroszolgáltatási architektúra az érési szakaszba lép a következő öt évben. Ez az érettség a DevOps kultúra nyomán történik, 2020-ig elérve a szervezetek 50% -át, a szoftver-automatizálási eszközök folyamatos fejlődését és az olcsó, méretezhető felhőinfrastruktúra uralmát, amelyet az Amazon Web Services (AWS) és a Microsoft Azure kedvel.
Dadgar elmondta, hogy még a DevOps-ot és a mikro-szolgáltatásokat átfogó vállalkozások azon kis töredéke ellenére is, hogy a HashiCorp már jelentősen túllicitált. Mindössze kilenc hónapos vállalati értékesítés után elérte az első hét számjegyű bevételét, egy több millió havi aktív felhasználói nyílt forrású közösség mellett a GitHubon. A mikroszolgáltatások csak egy része a HashiCorp munkafolyamat-alkalmazási eszközkészletének és a nagyobb DevOps infrastruktúra-ütemtervnek. De a moduláris jelleg és az interoperabilitás mindazonáltal, amelyet a vállalat épít, a Szilícium-völgy egyik legforróbb szoftverindítójának meteorikus növekedését támogatta.
"Négy évvel ezelőtt, amikor elkezdtük, találkozókba mentünk és elképzelésünket alakítottuk ki az infrastruktúra kezeléséről" - mondta Dadgar. "Nem pontosan nevetettünk ki a helyiségből; tudtuk, hogy már korán van. De most olyan eszközöink, mint például a Terraform, úton vannak az iparági szabványokká. A jövőben a verseny nyomásának dominóhatása lesz, és a Hosszú távon a CIO-kkal és a CTO-kkal való együttműködésünk az, hogy megértsük a folyamatváltást, amelyre szükségük van.
- Gondolj a Toyotara a nap folyamán - folytatta Dadgar. "Volt egy csomó autóipari vállalat, amely épített termékeket, de a költségek magasabbak voltak, mint amilyennek lennie kellene. A Toyota nem találta fel újra az autót; csak szigorúbbak és inkrementálisabbak voltak a folyamatban, és a nevetőállománytól az erőműhöz kényszerítették, Az iparág többi tagja ugyanazt a gyakorlatot alkalmazza a versenyképesség megőrzése érdekében: Most az iparági vezetők azt kérdezik, hogyan szerezzenek versenyelőnyt, és válaszuk az, hogy alkalmazzák a piac Googles és amazonjainak gyakorlatait. pont, akkor eléri a kritikus tömeget."
