Cloud: Hvad er det og hvordan virker det?
En af de mere irriterende aspekter af tech-industrien er den spredning af buzzwords og marketing-tale. Tage “skyen”, for eksempel. På en eller anden måde, har vi formået at re-label, praksis for at fylde op giant, magt-sugende, varme-pumper, sjælløse lagre af computerkraft til noget godt og floaty som “cloud”.
Og nu har vi også “multi-cloud.” I stemningsfyldt verden af DEN markedsføring, hvad der præcist er “multi-cloud”? Hvem bekymrer sig om det? Hvem bruger det?
Den bedste måde at forstå multi-cloud, er at billedet et scenarie som dette: for Nylig, Nordlige Widgets, besluttet at vedtage en cloud-først-strategi. Hvis en IT-funktionen kan sættes i cloud vs installeret på lokaler, skyen er det foretrukne valg.
Når Nordlige Widgets tilføjet en ny kunde opleve stemningen analyse af big data-infrastruktur, besluttede de, at det nye buzzword suppe ville være installeret på en virtuel rack i AWS. De spundet op af et netværk af virtuelle maskiner, der anvendes andre aspekter af Amazon ‘ s on-demand-infrastruktur, og indsat i deres løsning.
Så langt, så godt. Så Amazon havde en strømafbrydelse. Det var ikke en stor en, men det var et wake-up call til den Nordlige management team. Hver gang deres kunder har oplevet en strømafbrydelse, Nordirland, blev straffet. Udfald, og derfor er dårlige.
Efter cirka fire måneder af møder og telefonmøder, Nordlige besluttet at klone deres AWS infrastruktur til Azure.
Og så skete det Nordlige Widgets nu havde infrastructure-as-a-service (IaaS) buildouts, der kører på AWS og Azure. De havde også on-premises infrastruktur. På toppen af alt det, de brugte også en bred vifte af SaaS-systemer, der spænder fra SalesForce til Gmail til Slap og Dropbox.
Selvom der er en masse at diskutere, om SaaS, lad os begrænse dagens artikel til kun IaaS udfordringer Nordlige Widgets står over for med at koordinere AWS og Azure.
Det er fordi, det er aldrig så enkelt, er det? Sikker, kan du oprette virtuelle Linux-kasser i begge miljøer, bygge ud opbevaring, bygge ud microservices og alt det der. Men uanset hvor tæt du forsøger at få, de arkitekturer, vil være forskellige, Sla ‘ er kommer til at være anderledes, identity management systemer er kommer til at være anderledes, og så er ledelsen konsoller.
DET nordlige ledere befandt sig i konstant at hoppe mellem ledelse konsoller for deres arv-lokaler ting, plus for deres forskellige AWS og Azure anlæg. En afdeling, der gik rogue, og i stedet for at bygge fail-over til Azure, besluttet at bygge fail-over til Bluemix.
Ved den tid, CIO fandt ud af, at for meget data og infrastruktur, som var blevet bygget ud i Bluemix at trække det ud, så selskabet nu havde AWS, Azure, og Bluemix til at koordinere.
Dette er multi-cloud. Det er ikke kønt. Men grunden til at eksistens er bestemt forståeligt. Ingen intelligente virksomhed ønsker at lægge alle sine æg i én kurv, selv om, at kurven er ved at køre stærkt pålidelige virksomheder som Amazon, Microsoft eller IBM.
Der er en række årsager til denne advarsel. En af grundene er, failover og disaster recovery. Alle komplekse systemer opleve fiasko, og i de tilfælde, hvor infrastrukturen ikke lykkes for den ene eller anden grund, har en backup af virtuelle datacenter kan være kritisk. Dette er særligt vigtigt i en verden, hvor cyberangreb er nu normen.
En anden grund er hele leverandør-forhold en del af puslespillet. Hvad sker der, hvis din cloud-leverandør pludselig ændrer strategi eller ledelse og enten begynder at betragte dig som en konkurrent eller sætter sin form af service, priser eller andre betingelser for at noget uholdbart? Hvis du er en “going concern” med en aktiv bruger base, de måneder, det ville tage at migrere kan være for lang. Igen, du egentlig kigger på en failover-situation, men her er det baseret på forretningsmæssige vilkår, ikke tekniske problemer.
Du kan se hvor jeg vil hen med dette. Andre grunde til at gå på denne måde omfatter muligt regering eller lovmæssige spørgsmål, er potentialet for, at en ændring i en sælgers teknologi stakken bryde dine systemer, ønsket om at have evnen til at håndtere stigninger på tværs af leverandører, de har brug for til at bygge og praksis design abstraktion, så du har et lag, der ikke er afhængige af en leverandør underliggende platform, og meget mere.
En variant af den multi-cloud koncept er en hybrid DET. I det væsentlige, hybrid DET er en blanding af infrastruktur, der befinder sig på lokaler og infrastruktur, der befinder sig i skyen. Hybrid DET, og det kan derfor optage multi-cloud. Dette, selvfølgelig, øger management kompleksitet ved endnu et niveau.
Nordlige Widgets, vores eksempel scenario, er at køre en hybrid IT-drift. De har nogle af de ældre på stedet systemer og cloud-infrastrukturer i AWS, Azure, og Bluemix. Alle disse systemer er nødt til at være lykkedes ved hjælp af en blanding af overvågning, politikker, automatisering, og federation.
Hver multi-cloud eller hybrid IT-konfiguration er kommer til at være anderledes. Når du er højere i stakken, tingene er ikke så varieret. Din erfaring og min oplevelse af Gmail (separat fra et par add-ons) vil være stort set de samme. Det er fordi, på den offentlige ansøgning niveau, vi alle bruger de samme værktøjer.
Men på den private infrastruktur-niveau, hvor hver enkelt virksomhed opbygger sine egne IaaS stakken for at opfylde sine egne unikke behov, de stak konfiguration vil være forskellig for hver organisation.
Jeg har ikke tænkt mig at dykke ned i de forskellige af stakke i denne artikel. I stedet er mit budskab her er enkel: du skal bare flytte til skyen kommer ikke til at løse dine problemer. I virkeligheden, når du flytter til clouden, kan du tilføje helt nyt lag af kompleksitet til din operationer.
Husk, at det er nødvendigt at automatisere og administrere på tværs af skyer, og plan og budget, ikke kun for de ressourcer, der er fastsat af de forskellige offentlige cloud-udbydere, du vælger, men også for alle de software og licenser, du bliver nødt til at styre det hele.
Du kan følge min dag-til-dag-projekt opdateringer på sociale medier. Sørg for at følge mig på Twitter på @DavidGewirtz, på Facebook på Facebook.com/DavidGewirtz på Instagram på Instagram.com/DavidGewirtz og på YouTube på YouTube.com/DavidGewirtzTV.