I artikkelen «Fraråder miksing av skytjenester. – En fulltidsjobb selv med bare én sky» rapporterer Digi om Gartners analytikerdirektør Sanjeev Mohan som mener at man ikke burde mikse og matche tjenester fra forskjellige skyleverandører. Digis artikkel refererer til denne artikkelen i The Register.
I Digis artikkel tegnes det et bilde av at jeg mener noe helt annet enn Mohan basert på et intervju jeg tidligere ga Digi. Slik jeg forstår det Mohan sier til The Register, er Digis artikkel basert på en misforståelse. I realiteten er det ingen motsetning mellom det Mohan sier og hvordan Elvia har implementert multi-sky.
Hensikten med denne kommentaren er å forklare hvorfor jeg mener at det ikke finnes noen motsetning mellom det Mohan og jeg har sagt, og jeg benytter samtidig anledningen til utdype hvordan vi tenker rundt temaet «multi-sky» i Elvia.
Enighet mellom Gartner og Elvia
Dersom man leser hva Mohan faktisk sier i artikkelen i The Register, ser man at han ikke snakker om multi-sky generelt. Det han sier er at man bør satse på kun en sky for den ene nisjen «data management tools». Han sier altså ingenting om det er smart å satse på multi-sky for andre funksjonsområder enn datahåndtering. Dette sitatet: «Just because you're in their cloud doesn't mean you have to go with the multibillion-dollar provider's data tools either», impliserer tvert imot at det er naturlig å tenke at enkelte tjenester kan være bedre i en annen sky enn den du er i.
Det er interessant å merke seg at det er nettopp innenfor nisjen «data management tools» at Elivia har valgt en annen plattform en skyen hvor vi har det meste av vår øvrige infrastruktur. Vi har i dag alt av applikasjoner, virtuelle maskiner, applikasjonsspesifikk datalagring, køer etc. i Azure. I Google Cloud har vi kun BigQuery (vår data plattform) samt en instans av BigTable som eier og benyttes av et bestemt system.
Halvparten av de unge synes ulovlig strømming er greit
Multi-sky, enten du vil eller ikke
I Elvia ser vi en generell bevegelse bort fra «on-prem» løsninger til SaaS. Vi skal for eksempel flytte fra vår lokalt installerte instans av ERP-systemet IFS til SaaS-versjonen, og vi annonserte nylig at vi skal satse på Salesforce som system for å håndtere kundesaker. På utviklings- og prosjektsiden har vi lenge vært på denne reisen med produkter som GitHub, Azure DevOps, Terraform Cloud, Miro, Jira og Confluence.
Hva er forskjellen på alle disse SaaS-løsningene og offentlig sky? Fra et forvaltningsperspektiv er det nærmest ingen forskjell, og vi blir i økende grad sittende med flere små «skydotter» i tillegg til det vi har i offentlig sky. Det ville altså blitt multi-sky på oss selv om vi skulle holdt oss til bare en av de store skyleverandørene der vi har de tingene som vi har utviklet selv.
Av regulerings- og sikkerhetsgrunner vil vi aldri komme oss unna behovet for å ha noen systemer på bakken. Allerede i dag er drift og vedlikehold av mesteparten av on-prem hardware, applikasjoner, nettverk og sikkerhet outsourcet til en driftspartner, og vi jobber med å overføre alt til vår nye leverandør (Intility). Den store forskjellen på infrastruktur i sky og hos lokal driftspartner har vært muligheten til å automatisere, og dette er et område hvor verden er i ferd med å bevege seg fremover ved at det vil bli like naturlig og enkelt å vedlikeholde on-prem på en automatisert måte som det i dag er for skyløsninger.
Poenget er at «sky» er mer enn bare det du har hos en av de store leverandørene av offentlig sky. Jeg tror de fleste i fremtiden kommer til å operere med flere SaaS/PaaS-tjenester, både enkeltstående (som Salesforce), som tjenester på en eller flere offentlig skyer og on-prem ved at driften og vedlikeholdet her har blitt automatisert slik at det til forveksling ser ut som en sky. Man blir da nødt til å bygge opp kapabilitet til å håndtere mange skyer og behandle hele porteføljen på en enhetlig og automatisert måte.
Automatisering, automatisering, automatisering
Hvilke egenskaper ved sky er det som tiltrekker? En fordel er at den underliggende driften er outsourcet og industrialisert, og en annen er muligheten til dynamisk skalering som typisk tilbys i de forskjellige sky-tjenestene. En tredje fordel som vi har sett her hos oss er at sky er en katalysator for innovasjon ved at det er enkelt og billig for organisasjonen å teste «ville ideer» siden det er billig og enkelt å spinne opp kraftige tjenester på sky (kontra det å være sikker nok til å bestille hardware og lisenser slik man tidligere måtte).
En fjerde viktig egenskap er muligheten til å automatisere driften av tjenestene. Alle de store skyene tilbyr funksjonalitet for å opprette og vedlikeholde ressurser via API. Denne muligheten for automatisering er svært viktig for oss i Elvia, og dette er den viktigste enkeltfaktoren bak det faktum at vi i dag opererer egenutviklede løsninger på to offentlige skyer med suksess.
Mange forholder seg trofast til en sky, og også til denne skyens språk for automatisering (ARM for Azure eller CloudFormation for AWS, for eksempel). Det å holde seg kun til en offentlig sky er en god strategi dersom man er fornøyd med det denne skyen har av tjenester, men jeg tror man gjør en tabbe ved å satse på en leverandørs språk og verktøy for automatisering. Årsaken er at man nesten helt sikkert kommer til å sitte med mange tjenester som med fordel kan automatiseres utover de man har i sin favorittsky (enkeltstående SaaS-tjenester og on-prem applikasjoner). Derfor bør man vurdere om man ikke først som sist bør ta i bruk et sky-agnostisk verktøy som kan brukes til å automatisere hele IT-porteføljen. Dette verktøyet bør være enkelt utvidbart slik at man kan skrive egen automatiseringslogikk mot det man måtte ha av nisjesystemer; sluttmålet bør være intet mindre en 100 % automatisering og «infrastruktur som kode» for absolutt hele systemporteføljen.
Ved å følge denne automatiseringsstrategien er vi i Elvia i dag godt på vei mot et hverdag der alt av tjenester og underliggende infrastruktur er definert i kode og hvor egenutviklet applikasjonskode henger sammen med infrastrukturen. Dette har allerede gitt en grad av fleksibilitet og kontroll som vi tidligere bare kunne drømme om, og situasjonen kommer til å forbedre seg ytterligere etterhvert som vi får migrert «legacy» systemer til automatiserbare tjenester.
Det er stort potensial for misbruk av smarthus-teknologi
Sikkerhet
Det skal ikke stikkes under en stol at man introduserer noe overhead for hver sky man beveger seg inn på. Vår erfaring er at det er snakk om noen ukers arbeid i oppstarten for vårt sentrale team for skyforvaltning. Det man trenger å gjøre er å innlemme den nye skyens struktur i ens egen, sette opp SSO og skrive moduler for automatisering av tjenestene på den nye skyen.
De offentlige skyene tilbyr et stort antall tjenester av forskjellige typer, og dersom man skulle ta i bruk alle former for tjenester på den nye skyen, vil man eksponere seg for en betydelig sikkerhetsrisiko, og man ville bli tvunget til å bruke masse ressurser på å drifte fra et sikkerhetsperspektiv.
Hos oss har vi en slik sky hvor vi både bruker PaaS/SaaS men også har virtuelle maskiner og andre typer lav-nivå tjenester, og det er vår «default» sky Azure. Det er en betydelig jobb å følge opp sikkerheten her.
Når vi så besluttet å benytte GCP, var det kun til enkeltstående tjenester hvor vi så at GCP hadde noe å tilby som ikke fantes på Azure. Ved kun å benytte noen få tjenester, og da gjerne høy-nivå tjenester hvor man ikke forvalter maskinvare direkte, er angrepsflaten liten. Fra et sikkerhetsperspektiv blir vår jobb i stor grad redusert til kun å sørge for at vi har kontroll på tilgangen til tjenesten.
Når det gjelder tilgangskontroll har vi fulgt samme strategi som for automatisering, nemlig å etablere et separat sky-agnostisk opplegg for å forvalte tilganger (Hashicorp Vault). Fordelen med dette er at vi kan få på plass tilgangskontroll til forskjellige tjenester hos ulike leverandører innenfor en og samme modell.
Konklusjon
De grepene og strategiene man trenger å få på plass for å ha suksess med multi-sky er de samme som man uansett har lyst på selv om man kun opererer på en sky: navnkonvensjoner og struktur, automatisering og sikker tilgangskontroll. Kostnaden ved å etablere seg på en ny sky er reell, men samtidig beskjeden dersom man kun bruker høynivå PaaS/SaaS-tjenester på «støtteskyen». Det kan være verdt etableringsinnsatsen dersom den nye skyen tilbyr en tjeneste som man vil ha nytte av og hvor den eksisterende «hovedskyen» ikke har en like god tjeneste innenfor det aktuelle området.
Gartners analytiker direktør Sanjeev Mohan sier at man bør holde seg til kun en sky for dataløsninger, vi tar han på ordet og vår strategi er å gjøre nettopp det. Men for andre områder ser vi nytten av å holde oss oppdatert på hva som finnes der ute, og kanskje ta noe av det i bruk dersom det passer oss.
Ikke nok grønn energi til å dekke KI-boomen i Norge
