Virtualizacija gali būti pati sėkmingiausia technologija, peržengusi įmonės duomenų centro slenkstį. Labai geresnis aparatinės įrangos naudojimas ir galimybė susikurti VM ant cento padarė virtualizavimą lengvą parduoti per pastarąjį dešimtmetį, kai „Gartner“ neseniai apskaičiavo, kad 70 procentų „x86“ darbo krūvių yra virtualizuota.
Vis dėlto puošni privataus debesies medžiaga ant šio virtualizacijos sluoksnio buvo lėta. Taip, „VMware“ ir „Microsoft“ virtualizacijos valdymo įrankiai įgalino debesuotus veiksmus serveriuose ir saugyklose, ir net „OpenStack“ pagaliau gauna šiek tiek įmonės traukos, tačiau pažangūs viešieji debesys, kuriuos siūlo „Amazon“, „Google“, IBM, „Microsoft“ ir „Rackspace“, teikia daug daugiau pažangus automatinis mastelio keitimas, matavimas ir savitarnos paslaugos (jau nekalbant apie šimtus kitų paslaugų). Be to, „PaaS“ debesų sluoksnis, skirtas programoms kurti, išbandyti ir diegti, kurias dabar siūlo visi pagrindiniai viešieji debesys, pateko į palyginti nedaug įmonių duomenų centrų.
Tada Dockeris pernai rėkė į sceną ir pasiūlė naują debesų kaminą, pagrįstą konteineriais, o ne VM. Konteineriai yra daug mažesnio svorio nei VM, todėl programas galima lengvai supakuoti ir perkelti be jokio paprasto diegimo vargo. Jei VM pagrindu veikiantys debesys sustojo ir naujas konteinerių pagrindu sukurtas kaminas siūlo tokius akivaizdžius pranašumus, ar naujasis kaminas peršoks kelią į įmonę pristatydamas naują privatų debesį?
Zorawaras Biri Singhas, buvęs „HP Cloud Services“ vadovas, o dabar - „Khosla Ventures“ rizikos partneris, mano, kad naujojo kamino triumfas yra neišvengiamas, tačiau mes vis dar esame toli nuo įmonės perėmimo. Štai kur jis mato kliūtis:
Pirma, tradicinėms įmonėms ir tradicinėms gamybos apkrovoms dabartinės IT išlaidos skiriamos VM išplėtimo supaprastinimui ir valdymui, naudojant duomenų centre suvestinius sprendimus. Antra, naujas kaminas vis dar trapus ir ankstyvas. Tikras naudingumas aplink konteinerius, kaip ir sustiprintas saugumas, vis dar nėra pakankamas. Šiuo metu naujasis kaminas yra labai geras dirvožemis dev ir bandymų krūviams. Tačiau tikroji trinties sritis yra ta, kad įmonės gamybos ir darbo krūvio IT komandoms trūksta orientacijos į „devops“ ar judrių IT fonų, kad būtų galima diegti ir palaikyti platinamas ar be pilietybės programas. Viena didžiausių problemų yra ta, kad tradicinėse įmonės organizacijose yra tik didžiulis įgūdžių trūkumas.Kita vertus, sako Singhas, „tam tikros„ dev “komandos ir žaliųjų laukų verslo linijos jau važiuoja šia infrastruktūra“. Tokiais atvejais jau yra įdiegti „devops“ metodai, arba novatoriški kūrėjai patys tvarko konteinerių pagrindo kamino operacijų pusę.
Kaip kūrėjai paskatino priimti „NoSQL“ duomenų bazes, jie yra naujojo kamino priekinėse linijose, atsisiunčia atvirojo kodo programinę įrangą ir eksperimentuoja arba kreipiasi į viešus debesis, tokius kaip EC2 ar „Azure“, kurie jau palaiko konteinerius.
Mikroservių būtinybė
Kodėl kūrėjai taip mėgsta naują kaminą? Didžiąja dalimi todėl, kad konteineriai yra palankūs mikropaslaugų architektūrai, kur vienos paskirties API prieinamos paslaugų kolekcijos pakeičia monolitines programas. „Microservices“ architektūra leidžia kūrėjams kurti programas, labiau pritaikomas naujiems reikalavimams, ir greitai sukurti visiškai naujas programas, naudojant esamas paslaugas.
Johnas Sheehanas, API stebėjimo ir testavimo paslaugos „Runscope“ įkūrėjas ir generalinis direktorius, mikroservis laiko SOA (į paslaugas orientuotos architektūros) „modernizavimu“. „Pagrindinės pareigos iš esmės yra tos pačios“, - sako Sheehanas. "Mes norime paskirstyti skirtingas savo programinės įrangos architektūros dalis skirtingose sistemose ir suskaidyti ją ne tik pagal kodo, bet ir pagal paslaugų ribas. Tas mokymasis persikėlė ir į mikropaslaugas."
„Microservices“ architektūra remiasi paprastesniais, kūrėjams patogesniais protokolais nei SOA - REST, o ne SOAP; JSON, o ne XML. Sheehanas pažymi dar vieną esminį skirtumą:
Mikropaslaugų tipai, kuriuos mes matome ir kuriuos dažniausiai naudoja mūsų klientai, labai priklauso nuo paslaugų teikėjų. Viduje savo įmonėje visose įvairiose tarnybose mes dislokuojame apie 31 kartą per dieną. Mes esame 14 žmonių ir turime apie 40 skirtingų paslaugų, veikiančių viduje. Taigi didžioji jos dalis yra reikalingos infrastruktūros sukūrimas, kad kiekviena komanda galėtų savarankiškai diegti, keisti mastą, stebėti ir matuoti kiekvieną paslaugą.Tokiu atveju riba tarp „dev“ ir „ops“ išnyksta. Organizacijos personalas rašo kodą infrastruktūrai valdyti, iš esmės tampa kūrėjų komandos dalimi. „Operacijų komanda ir programų komanda labai mažai skiriasi“, - sako Sheehanas. Operacijose „atsitiktinai koduojate serverius, o ne koduojate paslaugą“.
Singhas mano, kad intensyvus mikropaslaugų metodas gali panaikinti „oficialios“ PaaS poreikį. Tokie „PaaS“ pasiūlymai kaip „Cloud Foundry“ ar „OpenShift“ siūlo iš anksto nustatytas paslaugų ir procesų kolekcijas, skirtas kurti, išbandyti ir diegti programas - tuo tarpu naujame kaupinyje kiekviename sluoksnyje galima įterpti gausius API prieinamų mikropaslaugų rinkinius. Tiek „dev“, tiek „ops“ gali prisijungti prie mikropaslaugų kamino aukštyn ir žemyn, be „PaaS“ nustatytų apribojimų.
Kitokio tipo hibridas
„Mikroserviso“ architektūra gali iššokti „PaaS“, tačiau visas naujas kaminas neįsišaknys per naktį. Pavyzdžiui, laikoma, kad „Netflix“ yra visur įdiegta pažangiausia mikroservikų diegimo sistema, todėl atvirojo kodo bendruomenė gali naudotis daugeliu iš anksto sukurtų paslaugų kaip „Docker“ vaizdais „Docker Hub“, tačiau „Netflix“ gamyboje nenaudoja „Docker“. Runscope taip pat nėra. Abi vietoj to naudoja įprastus VM.
Nepaisant didžiulio kūrėjų susidomėjimo konteineriais pagrįstais sprendimais, tai ankstyvos dienos. Viena vertus, konteinerių, tokių kaip Mesosphere ir Kubernetes, orkestravimo ir valdymo įrankiai vis dar tobulinami. Kita vertus, neaišku, kuris konteinerių standartas laimės, nes „CoreOS“ praėjusį gruodį „Docker“ kėlė didelį iššūkį. Konteinerių pagrindu sukrautas galiausiai gali triumfuoti, bet tai užtruks.
„Matome, kad labiausiai tikėtinas rezultatas yra tai, kad konteineriai ir VM bus naudojami kartu“, - sako Kurtas Milne'as iš daugelio debesų valdymo teikėjo „Cliqr“. Tai gali reikšti, kad konteineriai veikia VM viduje, arba tiesiog tai gali reikšti, kad nauji konteinerių ir VM pagrindu esantys kroviniai eis greta.
Šis hibridinis scenarijus atveria galimybę „VMware“ ir kitiems, sukūrusiems valdymą ir organizavimą virtualizacijai. Interviu praėjusią savaitę „VMware“ vykdomasis viceprezidentas Raghu Raghuramas atsisakė konteinerius vertinti kaip grėsmę. Vietoj to jis pasakė:
Konteineriai yra būdas pritraukti naujų programų į mūsų platformą. Kai kūrėjai ar IT žmonės domisi, ko jiems reikia norint patikimai paleisti konteinerius, paaiškėja, kad jiems reikia infrastruktūros sluoksnio apačioje - jiems reikia atkaklumo, jiems reikia tinklo, reikia užkardos, jiems reikia išteklių valdymo ir visų kitų rūšių daiktus. Mes tai jau pastatėme. Kai pridėsite konteinerių mechanizmą, tada galėsite pradėti naudoti tą pačią infrastruktūrą ir tiems dalykams. Matome modelius, kur be pilietybės žiniatinklio priekinė dalis yra visi konteineriai, o atkaklumas ir duomenų bazės yra visos VM . Tai abiejų mišinys. Taigi dabar kyla klausimas: kas yra bendra infrastruktūros aplinka ir bendra valdymo aplinka? Mes tai matome kaip didžiulę galimybę.„Raghuram“ atsisakė pasakyti, kada „VMware“ gali išplėsti savo valdymo įrankius į konteinerio sluoksnį, tačiau potekstė yra aiški. Bus įdomu sužinoti, kaip „VMware“ į operacijas orientuotą požiūrį laikys kūrėjai, kurie vadovauja šiandieniniams konteinerių eksperimentams.
Aišku yra tai, kad, nepaisant dabartinio jaudulio, naujas kaminas neišstums esamo per dramatišką „nuplėšti ir pakeisti“ bangą. Kaip ir debesų priėmimo atveju, konteinerių pagrindu sukurtas kaminas bus naudojamas išimtinai pirmiausia kuriant ir bandant. Didelės esamos investicijos į virtualizacijos infrastruktūrą nebus išmestos iš duomenų centro lango.
Nepaisant to, naujas konteinerių pagrindas yra didelis šuolis į priekį judrumo ir kūrėjų valdymo srityje. Kūrėjai atranda ir priima įrankius, kurių jiems reikia norint sukurti mikropaslaugų architektūrą ir pateikti daugiau ir geresnių programų fantastiškame klipe. Kai kūriniai patenka į vietą ir devops įgūdžiai tampa visur, galite lažintis, kad naujasis krūva įsišaknys taip pat negailestingai, kaip tai padarė virtualizacija.
