Virtualizācija var būt visu laiku veiksmīgākā tehnoloģija, kas pārsniegusi uzņēmuma datu centra slieksni. Ļoti labāka aparatūras izmantošana un spēja palielināt VM uz dimetānnaftalīna ir padarījusi virtualizāciju par ērtu pārdošanu pēdējās desmitgades laikā, līdz brīdim, kad Gartner nesen lēsa, ka 70 procenti x86 darba slodžu ir virtualizēti.
Tomēr iedomātā privātā mākoņa saturs, kas atrodas virs šī virtualizācijas slāņa, ir bijis lēns. Jā, VMware un Microsoft virtualizācijas pārvaldības rīki ir ļāvuši serveriem un krātuvēm rīkoties kā mākoņaini, un pat OpenStack beidzot iegūst nelielu uzņēmuma pievilcību, taču uzlaboti publiskie mākoņi, ko piedāvā Amazon, Google, IBM, Microsoft un Rackspace, sniedz daudz vairāk uzlabota automātiskā mērogošana, mērīšana un pašapkalpošanās (nemaz nerunājot par simtiem citu pakalpojumu). Turklāt PaaS mākoņu slānis lietotņu izstrādei, testēšanai un izvietošanai - ko tagad piedāvā visi galvenie publiskie mākoņi - ir nonācis salīdzinoši maz uzņēmumu datu centru.
Tad Dokers pērn rēca uz skatuves, piedāvājot jaunu mākoņu kaudzi, kuras pamatā ir konteineri, nevis VM. Konteineru svars ir daudz mazāks nekā VM, un tie ļauj ērti iepakot un pārvietot lietojumprogrammas, neraizējoties par parasto uzstādīšanu. Ja uz VM balstītie mākoņi ir apstājušies un jaunais konteineru bāzes kaudze piedāvā tik acīmredzamas priekšrocības, vai jaunā kaudze izlēcīs uzņēmumā, lai piegādātu jaunu privātu mākoni?
Zorawar Biri Singh, bijušais HP Cloud Services vadītājs un tagad riska partneris Khosla Ventures, uzskata, ka jaunās kaudzes triumfs ir neizbēgams, taču mēs joprojām esam gadu attālumā no uzņēmuma ieviešanas. Lūk, kur viņš redz vājās vietas:
Pirmkārt, tradicionālajiem uzņēmumiem un tradicionālajām ražošanas slodzēm pašreizējie IT izdevumi ir vērsti uz VM izplešanās vienkāršošanu un pārvaldību, izmantojot datu centrā apvienotus risinājumus. Otrkārt, jaunā kaudze joprojām ir trausla un agra. Patiesa lietderība ap konteineriem, tāpat kā rūdīta drošība, joprojām ne tuvu nav pietiekama. Pašlaik jaunā kaudze ir ļoti laba augsne izstrādātāju un testēšanas slodzēm. Bet patiesais berzes punkts ir tāds, ka uzņēmuma ražošanas un darba slodzes IT komandām trūkst novirziena orientācijas vai veiklās IT vides, lai varētu izvietot un atbalstīt izplatītās vai bezvalstnieku lietotnes. Viens no lielākajiem jautājumiem ir tas, ka tradicionālo uzņēmumu organizācijās ir tikai milzīgs prasmju trūkums.No otras puses, saka Singh, "noteiktas dev komandas un zaļo lauku uzņēmējdarbības virzieni jau brauc uz šīs infrastruktūras." Šādos gadījumos vai nu jau ir ieviestas devops metodes, vai arī novatoriski izstrādātāji paši apstrādā konteinera bāzes kaudzes darbības pusi.
Tāpat kā izstrādātāji ir virzījuši NoSQL datu bāzu pieņemšanu, viņi atrodas jaunās kaudzes priekšējās līnijās, lejupielādējot atvērtā pirmkoda programmatūru un eksperimentējot - vai vēršoties pie publiskiem mākoņiem, piemēram, EC2 vai Azure, kas jau atbalsta konteinerus.
Mikropakalpojumu obligāta prasība
Kāpēc izstrādātājiem tik ļoti patīk jaunā kaudze? Lielākoties tāpēc, ka konteineri veicina mikropakalpojumu arhitektūru, kur monolītās lietotnes aizstāj viena mērķa API pieejamu pakalpojumu kolekcijas. Mikroservisu arhitektūra ļauj izstrādātājiem veidot lietojumprogrammas, kas ir vairāk pielāgojamas jaunajām prasībām, un ātri izveidot pilnīgi jaunas lietojumprogrammas, izmantojot esošos pakalpojumus.
Džons Šīhans, API uzraudzības un testēšanas pakalpojuma Runscope līdzdibinātājs un izpilddirektors, mikroservisus uzskata par SOA (uz pakalpojumiem orientētas arhitektūras) "modernizāciju". "Galvenie pienākumi lielākoties ir vienādi," saka Šīna. "Mēs vēlamies izplatīt dažādas mūsu programmatūras arhitektūras daļas dažādās sistēmās un sadalīt to ne tikai pēc kodu robežām, bet arī pēc pakalpojumu robežām. Šī mācīšanās ir pārnesta uz mikropakalpojumiem."
Mikroservisu arhitektūra balstās uz vienkāršākiem, izstrādātājiem draudzīgākiem protokoliem nekā SOA - REST atšķirībā no SOAP; JSON pretstatā XML. Šeihans atzīmē vēl vienu būtisku atšķirību:
Mikropakalpojumu veidi, kurus mēs redzam un kurus mūsu klienti mēdz izmantot, ir ļoti novirzīti uz devopiem. Iekšēji mēs dažādos dienestos izvietojam apmēram 31 reizes dienā mūsu uzņēmumā. Mēs esam 14 cilvēki, un mums ir aptuveni 40 dažādi pakalpojumi, kas darbojas iekšēji. Tik liela daļa ir nepieciešamās infrastruktūras izveidošana, lai katra komanda varētu neatkarīgi izvietot, mērogot, uzraudzīt un izmērīt katru pakalpojumu.Šādā scenārijā robeža starp dev un op ir neskaidra. Operatoru personāls raksta kodu, lai pārvaldītu infrastruktūru, būtībā kļūstot par izstrādes komandas daļu. "Ir ļoti maz atšķirību starp ops komandu un lietotņu komandu," saka Šeihans. Operācijās "jūs nejauši kodējat pret serveriem, nevis kodējat pret pakalpojumu".
Singhs uzskata, ka pieeja, kas prasa intensīvu mikropakalpojumu sniegšanu, var novērst nepieciešamību pēc "formālas" PaaS. Tādi PaaS piedāvājumi kā Cloud Foundry vai OpenShift piedāvā iepriekš noteiktas pakalpojumu un procesu kolekcijas lietojumprogrammu izveidei, testēšanai un izvietošanai - turpretī jaunajā kaudzītē katrā slānī var iestrādāt bagātīgas API pieejamo mikropakalpojumu kopas. Gan dev, gan ops var pieslēgties mikropakalpojumiem augšup un lejup, bez PaaS noteiktajiem ierobežojumiem.
Citāda veida hibrīds
Mikroservisu arhitektūra var izlaist PaaS, taču visa jaunā kaudze netiks iesakņojusies vienā naktī. Piemēram, tiek uzskatīts, ka Netflix ir vismodernākā mikropakalpojumu izvietošana jebkur, un tas padara daudzus iepriekš sagatavotus pakalpojumus pieejamus atklātā pirmkoda kopienai kā Docker attēlus Docker Hub, taču Netflix neizmanto Docker ražošanā. Arī Runscope šajā ziņā nav. Abi tā vietā izmanto parastos VM.
Neskatoties uz izstrādātāju milzīgo interesi par konteineros balstītiem risinājumiem, ir sākumposms. Pirmkārt, konteineru, piemēram, Mesosphere un Kubernetes, orķestrēšanas un pārvaldības rīki joprojām tiek attīstīti. Citam nav skaidrs, kurš konteineru standarts uzvarēs, jo CoreOS pagājušā gada decembrī izvirza lielu izaicinājumu Docker. Uz konteinera balstīta kaudze galu galā var uzvarēt, taču tas aizņems kādu laiku.
"Mēs redzam, ka visticamākais rezultāts ir tāds, ka konteineri un VM tiks izmantoti kopā," saka Kurts Milne no daudzmākoņu pārvaldības nodrošinātāja Cliqr. Tas varētu nozīmēt konteineru palaišanu VM iekšienē - vai vienkārši tas varētu nozīmēt, ka jauni uz konteineriem un VM balstīti skursteņi darbosies blakus.
Šis hibrīdais scenārijs paver iespēju VMware un citiem lietotājiem, kuri ir izveidojuši virtualizācijas pārvaldību un orķestrēšanu. Intervijā pagājušonedēļ VMware izpilddirektora vietnieks Raghu Raghurams atteicās uzskatīt konteinerus par draudiem. Tā vietā viņš teica:
Mēs uzskatām, ka konteineri ir veids, kā mūsu platformā ienest jaunas lietojumprogrammas. Kad izstrādātājiem vai IT ļaudīm rodas jautājums, kas viņiem vajadzīgs, lai izturīgi darbinātu konteinerus, izrādās, ka viņiem ir nepieciešams infrastruktūras slānis zem tā - viņiem ir nepieciešama neatlaidība, viņiem ir nepieciešams tīkls, viņiem ir nepieciešama ugunsmūri, viņiem ir vajadzīga resursu pārvaldība un visi citi veidi. lietas. Mēs to jau esam izveidojuši. Kad jūs virsū uzspiežat konteineru mehānismu, varat sākt izmantot to pašu infrastruktūru arī šīm lietām. Mēs redzam modeļus, kur bezvalstnieka tīmekļa priekšējā daļa ir visi konteineri, un neatlaidība un datu bāzes ir visas VM . Tas ir abu sajaukums. Tātad tagad ir jautājums: kāda ir kopēja infrastruktūras vide un kopīga pārvaldības vide? Mēs to redzam kā milzīgu iespēju mums.Raghuram atteicās pateikt, kad VMware varētu paplašināt savus pārvaldības rīkus līdz konteinera slānim, taču tas ir skaidrs. Būs interesanti redzēt, kā izstrādātāji, kuri vada šodienas konteineros balstītus eksperimentus, izpildīs VMware uz operācijām vērsto pieeju.
Skaidrs ir tas, ka, neraugoties uz pašreizējo satraukumu, jaunā kaudze neizspiedīs esošo jau kādā dramatiskā plosīšanās un aizstāšanas vilnī. Tāpat kā mākoņa pieņemšanas gadījumā, uz konteineru balstītu skursteni gandrīz tikai vispirms izmantos izstrādei un testēšanai. Milzīgais esošais ieguldījums virtualizācijas infrastruktūrā netiks izmests no datu centra loga.
Neskatoties uz to, jaunā konteineru bāze ir liels lēciens uz priekšu veiklībā un izstrādātāju kontrolē. Izstrādātāji atklāj un pieņem nepieciešamos rīkus, lai izveidotu mikropakalpojumu arhitektūru un nodrošinātu fantastisku klipu, lai nodrošinātu vairāk un labākas lietojumprogrammas. Kad gabali nostājas savā vietā un devops prasmes kļūst visuresošas, varat derēt, ka jaunā kaudze iesakņosies tikpat nerimstoši, kā to darīja virtualizācija.
