Når bør man vurdere en privat sky?

Ideen om å drive en privat sky, vertsbasert eller på stedet, for et enkelt selskap er i ferd med å bli hverdagskost. Stadig flere bedrifter lærer om cloud computing og ser at det å drive sin egen skyplattform er både gjennomførbart og potensielt verdifullt for virksomheten. Men på grunn av en generell mangel på skykunnskap blir det stadig vanligere at skyer anbefales selv når de ikke passer bedriftens behov i det hele tatt, og de forveksles med tradisjonelle virtualiseringsadministrasjonssystemer.

En sky er en spesiell type virtualiseringsplattform og fyller en unik nisje. Cloud computing tar tradisjonell virtualisering og legger til automatisk skalering og klargjøring som muliggjør rask, horisontal skalering av applikasjoner. Dette er ikke et vanlig forretningsbehov. Sky egner seg også til, og er ofte knyttet til, selvbetjening av ressursklargjøring, men dette alene gjør ikke noe til en sky og rettferdiggjør heller ikke overgangen til en skyplattform – selv om det kan være et ekstra insentiv. Det som gjør sky interessant er evnen til å tilby selvbetjeningsportaler til sluttbrukere og muligheten for at applikasjoner selv kan klargjøre ressurser. Dette er de kritiske aspektene som skiller en skyplattform fra tradisjonell virtualisering.

Det en sky ikke innebærer er funksjoner som forenklet heldomeneadministrasjon fra ett enkelt grensesnitt, storskala konsolidering, enkel migrering mellom maskinvaresystemer, rask klargjøring av nye systemer, virtualisering, høy tilgjengelighet, overkjøring av ressurser osv. Disse funksjonene er alle tilgjengelige på andre måter, primært gjennom eller på toppen av standard plattformvirtualisering (VMware vSphere, Microsofts HyperV, Xen, m.fl.). Det er ikke slik at disse funksjonene ikke kan gjøres tilgjengelige i en privat sky, men funksjonene er ikke aspekter ved skyen, men heller ved den underliggende virtualiseringsplattformen. Skylaget er over disse og videresender rett og slett fordelene fra de underliggende lagene.

Sky er ofte en tilnærming som velges på grunn av en misforståelse om at mange av funksjonene som vanligvis forbindes med private skyer ikke er tilgjengelige i en annen, enklere form. Dette er sjelden tilfelle. Normale virtualiseringsplattformer, oftest VMwares vSphere og Microsofts HyperV, tilbyr alle disse alternativene. De kan brukes til å bygge robuste klynger av fysiske servere, administrert fra ett enkelt grensesnitt, med utrolig høy pålitelighet og rask klargjøring av nye systemer som krever minimal spesialkunnskap fra IT-avdelingen og opprettholder tradisjonelle arbeidsflyter. Mesteparten av tiden, når jeg snakker med bedrifter som tror at de kan være interessert i å eie sin egen sky, er funksjonene de egentlig ønsker ikke skyfunksjoner i det hele tatt.

Begrepet «sky» har rett og slett blitt så populært i det siste at folk begynner å anta at viktige funksjoner for nesten alle må tilskrives det for å forklare den plutselige økningen i viktighet, men dette er rett og slett ikke tilfelle. Sky forblir, og vil forbli, en overveiende nisjeløsning som kun passer for et svært lite antall selskaper å eie selv. Bruken av offentlige skyer eller bruk av vertsbaserte tjenester levert fra skyplattformer vil bli, og har faktisk allerede blitt, nesten allestedsnærværende. Men eierskap av en privat sky for et enkelt selskaps bruk er langt fra å være et forretningsbehov for de fleste virksomheter eller forretningsenheter, og i mange tilfeller mistenker jeg at det aldri vil bli det.

Private skyer skinner på to nøkkelområder. Det første er en bedrift som trenger et stort antall midlertidige eller ad hoc-systemer som «spinnes opp» regelmessig. Dette skjer ofte med store utviklingsteam og applikasjonstestgrupper, spesielt hvis disse gruppene retter seg mot flere operativsystemer. Muligheten til å raskt klargjøre midlertidige testsystemer eller labsystemer kan være svært fordelaktig, og skynaturens evne til enkelt å eksponere klargjøringsverktøy som lar forretningskunder opprette, administrere og ødelegge sine egne systeminstanser med, som vi ville forvente, innebygde tilbakebelastningsmekanismer kan være svært gunstig for bedriftseffektiviteten ettersom samspillet mellom IT-avdelingen og sluttbrukerne blir nesten friksjonsfritt for denne transaksjonen. Ansvar for å vedlikeholde skyen som helhet kan enkelt skilles fra ansvaret for å vedlikeholde individuelle systemer. Sjelden brukt på denne måten for produksjonsarbeidsbelastninger, gir dette en selvbetjeningstilnærming som mange forretningsenheter desperat søker i dag. Upraktisk i liten skala på grunn av overhead ved å opprette og vedlikeholde selve skyplattformen, men i stor skala kan det være enormt produktivt. I tillegg til tekniske fordeler kan dette aspektet ved cloud computing tjene som en modell for å tenke på IT som en intern tjenesteleverandør og avdelinger som kunder. Vi har lenge diskutert IT og andre forretningsenheter i disse termene, men vi tenker sjelden virkelig på dem på denne måten.

Det andre området der cloud computing virkelig kommer til sin rett, og det som konseptet opprinnelig ble utviklet for, er å håndtere automatisk klargjøring for horisontalt skalerende applikasjoner. Det vil si applikasjonsarbeidsbelastninger som er i stand til å øke sin kapasitetshåndteringsevne ved å skape nye instanser av seg selv. I liten skala gjør mange webapplikasjoner, på grunn av sin tilstandsløse natur, dette innenfor ett enkelt system ved å skape nye trådarbeidere for å håndtere ekstra tilkoblinger. En Apache-webserver kan starte med åtte lyttere klare til å betjene forespørsler, men etter hvert som disse trådene blir utmattet, starter den automatisk nye tråder for å håndtere ekstra innkommende tilkoblinger slik at den kan skalere innenfor en enkelt servers grenser. For å utvide dette konseptet, anvendt på cloud computing, ville den samme applikasjonen som oppdager at trådutmatting nærmer seg på systemnivå (eller basert på andre beregninger som mangel på ledig minne eller ytelsestap) bruke et API eksponert fra skyplattformen til å signalisere skyadministrasjonssystemet om å klargjøre en ny kopi av systemet som kalte det – i praksis klone seg selv på stedet. I løpet av sekunder ville en ny virtuell server, identisk med den første, være oppe og gå og slutte seg til sin overordnede i å betjene innkommende forespørsler. Dette underordnede systemet eller klonen ville på samme måte skape nye tråder internt etter behov, og hvis det også oppdaget utmatting, ville det kalle skyplattformen for å opprette enda et nytt system for å håndtere enda flere tråder. På denne måten kan applikasjonen vokse seg selv nesten uendelig (innenfor maskinvaregrensene til hele skyplattformen) etter behov, på stedet, automatisk. Deretter, etter hvert som individuelle systemer blir ledige og arbeidsbelastningene avtar, kan ett system om gangen signalisere til skyadministrasjonssystemet at det ikke lenger er nødvendig, og systemet vil bli slått av og ødelagt siden det bare var en tilstandsløs klon, noe som frigjør systemkapasitet for andre applikasjoner og arbeidsbelastninger som kan trenge å dra nytte av den ledige kapasiteten.

Som vi kan se, er cloud computing enormt kraftig, spesielt med tanke på at hoveddelen av dagens offentlige og bedriftsapplikasjoner er skrevet på en tilstandsløs måte for å dra nytte av webprotokoller og sluttbrukergrensesnitt. Webapplikasjoner er spesielt dyktige til å utnytte cloud computings skaleringsmodell, og de fleste storskala webapplikasjoner utnytter denne elastiske utvidelsen og kontraksjonen av kapasitet i dag. Mange nye NoSQL-modeller begynner å dukke opp som signaliserer at databaser, i tillegg til applikasjonsfrontendebehandlingsnoder, snart kan dra nytte av lignende modeller i stor skala. Dette kan absolutt utnyttes for interne applikasjoner så vel som offentlig rettede, men interne applikasjoner trenger sjelden å skalere utover ett enkelt system, og det er derfor ganske sjeldent å finne private skyer som utnyttes på akkurat denne måten.

Farene rundt cloud computing kommer i form av ekstra kompleksitet utover normal virtualisering. Det er potensialet for kompleks lagring som er nødvendig for å støtte plattformen og flere lag å lære og vedlikeholde. Cloud computings evne til raskt å opprette og ødelegge systemer kan gjøre det fristende for brukere å forsøke å bruke skyressurser som om de var vedvarende systemer, noe de kan gjøres til, noe som kan resultere i tap av data fra brukere som opplever atferd som er svært forskjellig fra hva som er tradisjonelt og forventet. Muligens den største skybekymringen er en menneskelig en, og det er den økte sannsynligheten for å oppleve ukontrollert systemspredning ettersom sluttbrukere gal spinne opp stadig flere nye systemer som, ettersom de opprettes av sluttbrukere og ikke IT, sannsynligvis ikke er stramt kontrollert og overvåket, noe som etterlater systemer i en useriøs og ofte glemt tilstand. Dette kan føre til et vedlikeholds- og sikkerhetsmareritt ettersom systemer forblir uoppdatert og uten tilsyn, noe som øker risikoen og tapper ressurser. Og mest bekymringsfullt er muligheten for at systemer opprettes og glemmes og potensielt eksisterer uten korrekt lisensiering. Sporing og rapportering av auto-klargjorte systemer bærer prosesskrisiko forårsaket av det enorme skiftet i hvordan systemer opprettes. IT-avdelinger er vant til de tunge lisensieringsprosessene som er nødvendige for å opprettholde samsvar, men med cloud computing er det potensial for at denne prosessen eksponeres for forretningsenhetene på en måte som de ikke er i det hele tatt rustet til å håndtere. Det finnes tilpasninger for lisensieringsbehovene til cloud computing, men dette er ekstra kompleksitet og administrasjon som må håndteres. Å tillate systemer å eksistere uten direkte tilsyn fra IT-avdelingen bærer åpenbart risiko av en potensielt uforutsett karakter.

Eierskap av privat sky bringer mange spennende muligheter, men det er klart at disse fordelene og mulighetene ikke er for alle. De henvender seg til større bedrifter, til de med god prosesskontroll, til selskaper som kjører spesielt tilpassede applikasjoner som er i stand til å dra nytte av ressursenes elastisitet på systemnivå, og til de som trenger storskala ad hoc-systemoppretting og -ødeleggelse levert som en tjeneste for at sluttbrukere skal kunne selv-klargjøre. De fleste store bedrifter vil finne begrenset bruk for cloud computing internt. Mindre organisasjoner vil sjelden finne cloud computing fordelaktig i nær fremtid, om noen gang.