Ohjelmointi

Valmistaudu uuteen pinoon

Virtualisointi voi olla kaikkien aikojen menestynein teknologia, joka on ylittänyt yrityskeskuksen kynnyksen. Paljon parempi laitteiston käyttö ja kyky kehittää virtuaalikoneita pienellä summalla on tehnyt virtualisoinnista helpon myynnin viime vuosikymmenen aikana siihen pisteeseen asti, jossa Gartner arvioi äskettäin, että 70 prosenttia x86-työmääristä virtualisoidaan.

Silti hienot yksityiset pilvipalvelut virtualisointikerroksen päällä ovat tulleet hitaasti. Kyllä, VMwaren ja Microsoftin virtualisointihallintatyökalut ovat mahdollistaneet pilvikäytön palvelimille ja tallennustilalle, ja jopa OpenStack saa vihdoin vähän yritystoimintaa - mutta Amazonin, Googlen, IBM: n, Microsoftin ja Rackspacen tarjoamat edistyneet julkiset pilvet tarjoavat paljon enemmän edistynyt automaattinen skaalaus, mittaus ja itsepalvelu (puhumattakaan sadoista muista palveluista). Lisäksi kaikkien tärkeimpien julkisten pilvien tarjoama PaaS-pilvikerros sovellusten kehittämiseen, testaamiseen ja käyttöönottoon on löytänyt tiensä suhteellisen harvoihin yrityskeskuksiin.

Sitten Docker karjasi paikalle viime vuonna tarjoten uuden pilvipinon, joka perustuu kontteihin eikä virtuaalikoneisiin. Säiliöt ovat paljon kevyempiä kuin virtuaalikoneet ja mahdollistavat sovellusten pakkaamisen ja siirtämisen vaivattomasti ilman perinteisen asennuksen vaivaa. Jos VM-pohjaiset pilvet ovat pysähtyneet ja uusi konttipohjainen pino tarjoaa niin ilmeisiä etuja, hyppääkö uusi pino tiensä yritykseen toimittamaan uutta yksityistä pilviä?

Zorawar Biri Singh, entinen HP Cloud Services -yksikön johtaja ja nyt Khosla Ventures -yrityksen yhteistyökumppani, ajattelee uuden pinon voiton olevan väistämätöntä - mutta olemme vielä vuosien päässä yrityksen omaksumisesta. Tässä hän näkee pullonkaulat:

Ensinnäkin perinteisten yritysten ja perinteisten tuotantokuormitusten kohdalla nykyiset IT-menot keskittyvät virtuaalikoneiden leviämisen yksinkertaistamiseen ja hallintaan konvergoitujen ratkaisujen avulla konesalissa. Toiseksi uusi pino on edelleen hauras ja aikainen. Konttien ympärillä oleva todellinen hyödyllisyys, kuten karkaistu turvallisuus, ei ole vielä läheskään riittävä. Juuri nyt uusi pino on erittäin hyvä kylvöpaikka kehittäjille ja testikuormille. Todellinen kitkapiste on kuitenkin se, että yrityksen tuotannon ja työmäärän IT-tiimeillä ei ole devops-suuntautumista tai ketterää IT-taustaa voidakseen ottaa käyttöön ja tukea hajautettuja tai valtiottomia sovelluksia. Yksi suurimmista kysymyksistä on, että perinteisissä yritysorganisaatioissa on vain valtava osaamisvaje.

Toisaalta, Singh sanoo, "tietyt kehitystiimit ja greenfield -liiketoiminta-alueet jo ajavat tällä infrastruktuurilla." Tällaisissa tapauksissa joko devops-menetelmät ovat jo käytössä, tai edelläkävijät kehittäjät käsittelevät itse konttipohjaisen pinon toimintapuolta.

Aivan kuten kehittäjät ovat ajaneet NoSQL-tietokantojen käyttöönottoa, he ovat uuden pinon etulinjassa, lataavat avoimen lähdekoodin ohjelmistoja ja kokeilevat - tai kääntyvät julkisiin pilviin, kuten EC2 tai Azure, jotka jo tukevat kontteja.

Mikropalvelut ovat välttämättömiä

Miksi kehittäjät pitävät uudesta pinosta niin paljon? Suurimmaksi osaksi siksi, että kontit edistävät mikropalveluarkkitehtuuria, jossa monikäyttöiset sovellukset korvaavat yhden käyttötarkoituksen, API: n käytettävissä olevien palvelujen kokoelmat. Mikroservice-arkkitehtuurin avulla kehittäjät voivat rakentaa sovelluksia, jotka ovat paremmin mukautettavissa uusiin vaatimuksiin, ja luoda täysin uusia sovelluksia nopeasti olemassa olevia palveluita käyttämällä.

John Sheehan, API-seuranta- ja testauspalvelun Runscope perustaja ja toimitusjohtaja, näkee mikropalvelujen olevan SOA: n (palvelukeskeisen arkkitehtuurin) "modernisointi". "Päävastuut ovat pääosin samat", Sheehan sanoo. "Haluamme jakaa ohjelmistoarkkitehtuurimme eri osat eri järjestelmiin ja hajottaa sen paitsi koodirajojen, myös palvelurajojen mukaan. Tämä oppiminen on siirtynyt mikropalveluihin."

Mikroservice-arkkitehtuuri perustuu yksinkertaisempiin, kehittäjäystävällisempiin protokolliin kuin SOA - REST SOAP: n sijaan; JSON toisin kuin XML. Sheehan panee merkille toisen keskeisen eron:

Minkä tyyppiset mikropalvelut, joita näemme ja joita asiakkaamme yleensä käyttävät, ovat hyvin devops-ohjaamia. Sisäisesti käytämme noin 31 kertaa päivässä yrityksessämme kaikissa palveluissamme. Olemme 14 ihmistä ja meillä on noin 40 erilaista palvelua sisäisesti. Joten suuri osa siitä on tarvittavan infrastruktuurin luominen, jotta jokainen joukkue pystyy itsenäisesti ottamaan käyttöön, laajentamaan, seuraamaan ja mittaamaan kutakin palvelua.

Tällaisessa tilanteessa linja dev ja ops hämärtyy. Optioiden henkilöstö kirjoittaa koodin infrastruktuurin hallitsemiseksi, ja siitä tulee olennaisesti osa kehitystiimiä. "Ops-tiimin ja sovellustiimin välillä ei ole juurikaan eroa", Sheehan sanoo. Opissa "satut koodaamaan palvelimia vastaan ​​koodaamisen sijaan palvelua vastaan".

Singh uskoo, että devops-intensiiviset mikropalvelumenetelmät saattavat poistaa "muodollisen" PaaS: n tarpeen. Tällaiset PaaS-palvelut, kuten Cloud Foundry tai OpenShift, tarjoavat ennalta määriteltyjä palvelu- ja prosessikokoelmia sovellusten rakentamiseen, testaamiseen ja käyttöönottoon - kun taas uudessa pinossa runsaat API-käytettävissä olevat mikropalvelut voidaan upottaa jokaiseen kerrokseen. Sekä dev että ops voivat kytkeytyä mikropalveluihin pinosta ylös ja alas ilman PaaS: n asettamia rajoituksia.

Erilainen hybridi

Mikropalveluarkkitehtuuri saattaa hyppää PaaS: iin, mutta koko uusi pino ei juurtua yön yli. Esimerkiksi Netflixin katsotaan yleisesti olevan edistyneimpien mikropalvelujen käyttöönotto missä tahansa, ja se tarjoaa monia valmiita palveluita avoimen lähdekoodin yhteisön saataville Docker-kuvina Docker Hubissa - mutta Netflix ei käytä Dockeria tuotannossa. Eikä Runscope myöskään. Molemmat käyttävät sen sijaan tavanomaisia ​​virtuaalikoneita.

Huolimatta kehittäjien suuresta kiinnostuksesta konttipohjaisiin ratkaisuihin, se on alkuaikoina. Ensinnäkin, konttien, kuten Mesosphere ja Kubernetes, orkestrointi- ja hallintatyökalut kehittyvät edelleen. Toisen osalta ei ole selvää, mikä konttistandardi voittaa, sillä CoreOS asettaa Dockerille suuren haasteen viime joulukuussa. Konttipohjainen pino voi lopulta voittaa, mutta se vie jonkin aikaa.

"Näemme todennäköisimmän lopputuloksen, että kontteja ja virtuaalikoneita käytetään yhdessä", kertoo multicloud-hallinnan toimittaja Cliqr Kurt Milne. Tämä voi tarkoittaa sitä, että kontteja ajetaan virtuaalikoneissa - tai se voi tarkoittaa yksinkertaisesti sitä, että uudet konttipohjat ja virtuaalikoneisiin perustuvat pinot kulkevat rinnakkain.

Tämä hybridiskenaario avaa mahdollisuuden VMwarelle ja muille, jotka ovat rakentaneet hallinnan ja orkestroinnin virtualisointia varten. Viime viikon haastattelussa VMwaren varatoimitusjohtaja Raghu Raghuram kieltäytyi pitämästä kontteja uhkana. Sen sijaan hän sanoi:

Mielestämme kontit ovat tapa tuoda uusia sovelluksia alustallemme. Kun kehittäjät tai IT-ihmiset ihmettelevät, mitä he tarvitsevat konttien pitämiseen vankalla tavalla, käy ilmi, että he tarvitsevat kerroksen infrastruktuuria alapuolella - he tarvitsevat pysyvyyttä, he tarvitsevat verkostoitumista, he tarvitsevat palomuureja, he tarvitsevat resurssien hallintaa ja kaikkea muuta asioita. Olemme jo rakentaneet sen. Kun työnnät tämän päälle säiliömekanismin, voit alkaa käyttää samaa infrastruktuuria myös näihin asioihin.Näemme malleja, joissa valtioton web-käyttöliittymä on kaikki kontteja, ja pysyvyys ja tietokannat ovat kaikki virtuaalikoneita. . Se on sekoitus molempia. Joten nyt kysymys on: Mikä on yhteinen infrastruktuuriympäristö ja yhteinen hallintaympäristö? Mielestämme se on valtava tilaisuus meille.

Raghuram kieltäytyi sanomasta, milloin VMware saattaisi laajentaa hallintatyökalunsa säiliökerrokseen, mutta se on selvä. On mielenkiintoista nähdä, kuinka kehittäjät, jotka ajavat tämän päivän konttipohjaista kokeilua, kohtaavat VMwaren ops-suuntautuneen lähestymistavan.

Selvää on, että nykyisestä jännityksestä huolimatta uusi pino ei syrjäytä nykyistä joissakin dramaattisissa rip-and-korva-aalloissa. Kuten pilvipalvelujen käyttöönotossa, konttipohjaista pinoa käytetään melkein yksinomaan ensin kehitystyöhön ja testaukseen. Virtualisointiinfrastruktuuriin tehtävää valtavaa investointia ei heidetä ulos datakeskuksen ikkunasta.

Siitä huolimatta uusi konttipohjainen pino on iso harppaus eteenpäin ketteryydessä ja kehittäjien hallinnassa. Kehittäjät löytävät ja ottavat käyttöön työkalut, joita he tarvitsevat rakentamaan mikropalveluarkkitehtuuria ja toimittamaan enemmän ja parempia sovelluksia upealla leikkeellä. Kun palaset putoavat paikoilleen ja devops-taidoista tulee kaikkialla, voit lyödä vetoa, että uusi pino juurtuu yhtä hellittämättömästi kuin virtualisointi.

$config[zx-auto] not found$config[zx-overlay] not found