Programmering

Gjør deg klar for den nye stabelen

Virtualisering kan være den mest vellykkede teknologien noensinne for å krysse terskelen til bedriftens datasenter. Meget bedre maskinvareutnyttelse og muligheten til å spinne opp virtuelle maskiner på en krone har gjort virtualisering til et enkelt salg det siste tiåret, til det punktet hvor Gartner nylig anslått at 70 prosent av x86-arbeidsbelastningene er virtualisert.

Likevel har de fancy private sky-tingene på toppen av det virtualiseringslaget kommet sakte. Ja, virtualiseringsstyringsverktøy fra VMware og Microsoft har muliggjort skylignende oppførsel for servere og lagring, og til og med OpenStack får endelig litt trekk i bedriften - men de avanserte offentlige skyene som tilbys av Amazon, Google, IBM, Microsoft og Rackspace gir mye mer avansert autoskalering, måling og selvbetjening (for ikke å nevne hundrevis av andre tjenester). I tillegg har PaaS-skylaget for utvikling, testing og distribusjon av apper - som nå tilbys av alle større offentlige skyer - funnet veien til relativt få bedriftsdatasentre.

Da brølte Docker ut på scenen i fjor, og tilbyr en ny skystakke basert på containere i stedet for virtuelle maskiner. Beholdere har mye lavere vekt enn virtuelle maskiner, og gjør det enkelt å pakke og flytte applikasjoner uten bryet med konvensjonell installasjon. Hvis VM-baserte skyer har stoppet opp, og den nye containerbaserte stakken gir så åpenbare fordeler, vil den nye stakken hoppe frem i virksomheten for å levere en ny privat sky?

Zorawar Biri Singh, tidligere sjef for HP Cloud Services og nå en venturepartner i Khosla Ventures, synes triumfen til den nye stacken er uunngåelig - men vi er fremdeles mange år unna bedriftens adopsjon. Her ser han flaskehalsene:

For det første, for tradisjonelle bedrifter og tradisjonelle arbeidsbelastninger, er dagens IT-forbruk fokusert på å forenkle og administrere VM-utbredelsen via konvergerte løsninger i datasenteret. For det andre er den nye stabelen fortsatt sprø og tidlig. Virkelig verktøy rundt containere, som herdet sikkerhet, er fortsatt ikke i nærheten av tilstrekkelig. Akkurat nå er den nye stabelen en veldig god såplass for utvikling og testarbeidsbelastning. Men det virkelige friksjonspunktet er at IT-team for bedriftsproduksjon og arbeidsmengde mangler devops-orientering eller smidig IT-bakgrunn for å kunne distribuere og støtte distribuerte eller statsløse apper. En av de største problemene er at det bare er et stort ferdighetsgap i devops i tradisjonelle bedriftsorganisasjoner.

På den annen side, sier Singh, "kjører visse dev-team og greenfield-bransjer allerede på denne infrastrukturen." I slike tilfeller er enten devops-metoder allerede på plass, eller banebrytende utviklere håndterer operasjonssiden av den containerbaserte stakken selv.

Akkurat som utviklere har drevet adopsjonen av NoSQL-databaser, ligger de i frontlinjen til den nye stabelen, laster ned programvare med åpen kildekode og eksperimenterer - eller vender seg til offentlige skyer som EC2 eller Azure som allerede støtter containere.

Mikrotjenestene er avgjørende

Hvorfor liker utviklere den nye stakken så mye? For det meste fordi containere bidrar til mikrotjenestearkitektur, der samlinger av API-tilgjengelige tjenester for én formål, erstatter monolitiske apper. Microservices-arkitektur gjør det mulig for utviklere å bygge applikasjoner som er mer tilpassbare til nye krav - og å opprette helt nye applikasjoner raskt ved hjelp av eksisterende tjenester.

John Sheehan, medstifter og administrerende direktør for API-overvåkings- og testtjenesten Runscope, ser mikrotjenester som en "modernisering" av SOA (serviceorientert arkitektur). "Kjerneansvaret er stort sett det samme," sier Sheehan. "Vi ønsker å distribuere forskjellige deler av programvarearkitekturen på tvers av forskjellige systemer og bryte den opp ikke bare ved kodegrenser, men etter tjenestegrenser. Denne læringen har overført til mikrotjenester."

Mikrotjenestearkitektur er avhengig av enklere, mer utviklervennlige protokoller enn SOA gjorde - REST i motsetning til SOAP; JSON i motsetning til XML. Sheehan bemerker en annen viktig forskjell:

De typer mikrotjenester som vi ser, og som kundene våre pleier å bruke, er veldig devops-drevet. Internt distribuerer vi omtrent 31 ganger om dagen hos selskapet vårt på tvers av alle våre forskjellige tjenester. Vi er 14 personer, og vi har omtrent 40 forskjellige tjenester som kjører internt. Så stor del av det er å få på plass den nødvendige infrastrukturen slik at hvert team er i stand til å uavhengig distribuere, skalere, overvåke og måle hver tjeneste.

I et slikt scenario sløres grensen mellom dev og ops. Ops-personell skriver kode for å administrere infrastrukturen, og blir i hovedsak en del av utviklingsteamet. "Det er veldig lite skille mellom ops team og apps team," sier Sheehan. I ops, "du tilfeldigvis koding mot servere i stedet for koding mot tjenesten."

Singh mener den devops-intensive mikrotjenestetilnærmingen kan fjerne behovet for "formell" PaaS. Slike PaaS-tilbud som Cloud Foundry eller OpenShift tilbyr forhåndsbestemte samlinger av tjenester og prosesser for å bygge, teste og distribuere applikasjoner - mens i den nye stabelen kan rikt sett med API-tilgjengelige mikrotjenester være innebygd i hvert lag. Både dev og ops kan plugges inn i mikrotjenester opp og ned i bunken, uten begrensningene som er pålagt av PaaS.

En annen type hybrid

Mikrotjenestearkitektur kan hoppe over PaaS, men hele den nye stabelen vil ikke slå rot over natten. For eksempel anses Netflix å ha den mest avanserte distribusjonen av mikrotjenester hvor som helst, og det gjør mange forhåndsbygde tjenester tilgjengelige for open source-fellesskapet som Docker-bilder på Docker Hub - men Netflix bruker ikke Docker i produksjon. Heller ikke Runscope, for den saks skyld. Begge bruker konvensjonelle virtuelle maskiner i stedet.

Til tross for den enorme interessen blant utviklere for containerbaserte løsninger, er det tidlige dager. For det første er orkestrerings- og administrasjonsverktøyene for containere, som Mesosphere og Kubernetes, fortsatt i utvikling. For en annen er det ikke klart hvilken containerstandard som vil vinne, med CoreOS som utgjorde en stor utfordring for Docker i desember i fjor. Den containerbaserte stakken kan seire til slutt, men det tar litt tid.

"Vi ser at det mest sannsynlige utfallet er at containere og virtuelle maskiner vil bli brukt i kombinasjon," sier Kurt Milne fra multicloud-administrasjonsleverandøren Cliqr. Det kan bety at du kjører containere i virtuelle maskiner - eller det kan ganske enkelt bety at nye containerbaserte stabler og VM-baserte stabler kjører side om side.

Dette hybrid-scenariet åpner en mulighet for VMware og andre som har bygget ledelse og orkestrering for virtualisering. I et intervju med forrige uke nektet VMware-konserndirektør Raghu Raghuram å se containere som en trussel. I stedet sa han:

Vi ser containere som en måte å bringe nye applikasjoner inn på plattformen vår. Når utviklere eller IT-folk lurer på hva de trenger for å kjøre containere på en robust måte, viser det seg at de trenger et lag med infrastruktur under - de trenger utholdenhet, de trenger nettverk, de trenger brannmur, de trenger ressursadministrasjon og alle de slags tingene. Vi har allerede bygget det. Når du plopper beholdermekanismen på toppen av dette, kan du begynne å bruke den samme infrastrukturen også for disse tingene. Vi ser mønstre der det statsløse nettgrensesnittet er alle containere, og utholdenheten og databasene er alle virtuelle maskiner. . Det er en blanding av begge deler. Så nå er spørsmålet: Hva er et felles infrastrukturmiljø og et felles forvaltningsmiljø? Vi ser det som en enorm mulighet for oss.

Raghuram nektet å si når VMware kan utvide administrasjonsverktøyene til containerlaget, men implikasjonen er klar. Det vil være interessant å se hvordan VMwares ops-orienterte tilnærming vil bli møtt av utviklerne som driver dagens containerbaserte eksperimentering.

Det som er klart er at til tross for den nåværende spenningen, vil den nye stakken ikke erstatte den eksisterende i en eller annen dramatisk rip-and-repl-wave. Som med sky-adopsjon, vil den containerbaserte stakken nesten utelukkende brukes til utvikling og test først. Den enorme eksisterende investeringen i virtualiseringsinfrastruktur vil ikke bli kastet ut av datasentervinduet.

Likevel er den nye containerbaserte stakken et stort sprang fremover innen smidighet og utviklerkontroll. Utviklere oppdager og vedtar verktøyene de trenger for å bygge ut mikrotjenestearkitektur og for å levere flere og bedre applikasjoner på et fantastisk klipp. Når brikkene faller på plass, og ferdighetsferdigheter blir allestedsnærværende, kan du satse på at den nye stakken vil slå rot like nådeløst som virtualisering gjorde.

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