3.11 Cloudarkitektur

Overblik og motivation

Cloud computing er at leje en andens infrastruktur efter behov, over et netværk, afregnet for det, du bruger, og frigivet, når du er færdig. Cloudarkitektur er disciplinen at designe systemer, der behandler disse lejede ressourcer som deres naturlige hjem frem for som en lejet kopi af dit gamle datacenter. Den distinktion er hele pointen med dette kapitel. Du kan flytte en legacy-applikation til en cloududbyder og ændre intet ved dens design, og du vil få en større regning og nogenlunde samme skrøbelighed. Eller du kan designe til skyen og få elasticitet, administrerede tjenester, der udsletter hele kategorier af udifferentieret arbejde, og evnen til at overleve svigtet af en hel bygning uden at tilkalde nogen. Dette bygger direkte på grundlaget i kapitel 3.1: cloudarkitektur er arkitektur, med de samme afvejninger og kvalitetsegenskaber, anvendt på et substrat, du ikke ejer.

For store teams er indsatsen højere, fordi skyen omkobler, hvem der gør hvad. Når et team kan provisionere en database, en kø og en global belastningsfordeler på minutter, holder flaskehalsen op med at være indkøb og bliver styring: omkostning, sikkerhed og ensartethed på tværs af dusinvis af teams, der gør det samtidig. Skyen giver hver ingeniør et firmakreditkort og et lager af elværktøj, hvilket er vidunderligt og farligt i lige dele. At få arkitekturen rigtig betyder at fange fordelene (hastighed, elasticitet, robusthed), mens man installerer det rækværk, der holder udgifter, sikkerhedsholdning og dataresidens under kontrol.

Virksomheder og det offentlige mærker begge kanter skarpt. Virksomheder ankommer med årtiers eksisterende systemer, så deres cloudhistorie er som regel en migreringshistorie, fuld af hybridforbindelser og svære køb-versus-byg-kald. Det offentlige bærer den ekstra vægt af suverænitet, autorisationsregimer og borgeres data, der juridisk ikke må forlade bestemte grænser. Beslutningerne her (hvilken servicemodel, hvor mange udbydere, hvor fejldomænerne sidder, hvad der kører som administreret tjeneste versus jeres egen kode) former omkostning og risiko i et årti.

Grundprincipper

Design til skyen, fotografér ikke dit datacenter. Elasticitet, administrerede tjenester og bevidsthed om fejldomæner er grundene til at være her; et løft-og-flyt kaster dem væk.
Alt provisioneres som kode. Hvis et menneske klikker det i eksistens, er det udokumenteret, ugentageligt og ikke-reviderbart.
Design på tværs af fejldomæner med vilje. Regioner, tilgængelighedszoner og tjenester fejler; din arkitektur afgør, om det er et skuldertræk eller et nedbrud.
Modellen med delt ansvar er en kontrakt, ikke et slogan. Vid præcis, hvilken linje udbyderen sikrer, og hvilken linje du sikrer.
Køb det udifferentierede, byg det differentierende. Administrerede tjenester er reelle penge værd til rørføringen; hold din konkurrencefordel i dine egne hænder.
Indlåsning er en omkostning at prissætte, ikke en synd at undgå. Portabilitet har en pris, og gearing har en værdi; beslut bevidst frem for ved refleks.
Omkostning er en førsteklasses kvalitetsegenskab. I skyen er arkitektur og faktura den samme beslutning.

Anbefalinger

Vælg servicemodellen bevidst, og vælg administreret som standard

Cloududbydere sælger langs et spektrum fanget af as-a-service-modellerne: Infrastructure as a Service (IaaS) lejer rå beregning, lager og netværk; Platform as a Service (PaaS) lejer en administreret runtime, så du udruller kode uden at passe servere; Software as a Service (SaaS) lejer færdige applikationer. Serverless computing, herunder funktioner og administrerede hændelsesdrevne tjenester, skubber dette videre: du leverer kode eller konfiguration, og udbyderen håndterer al provisionering og skalerer til nul, når der er stille. Hvert trin op ad spektret bytter kontrol for gearing, fra IaaS med mest kontrol og mest driftsbyrde til serverless med mindst af begge.

Standarden bør være at klatre så højt op ad spektret, som dine krav tillader. En administreret database, der håndterer patching, backups, failover og skalering, er næsten altid en bedre brug af dine ingeniører end en selvdrevet. Forbehold IaaS på lavere niveau til tilfælde, der reelt har brug for det: specialiseret hardware, usædvanlige compliance-grænser, licensbegrænsninger eller ydeevne, den administrerede mulighed ikke kan møde. Skriv grunden ned som et arkitekturbeslutningsregister (kapitel 3.1), for “vi driver vores egen beskedmægler” er en påstand, der bør genretfærdiggøres hvert år.

Design på tværs af regioner og tilgængelighedszoner som eksplicitte fejldomæner

En cloudregion er et geografisk område; inden for den er tilgængelighedszoner fysisk adskilte datacentre med uafhængig strøm, køling og netværk, tæt nok til lavlatens-replikering, men langt nok til at ét svigt ikke tager de andre. Det er de sømme, skyen går i stykker langs, så din arkitektur må behandle dem som førsteklasses. Grundniveauet for enhver seriøs arbejdsbyrde er multizone: spred beregning og data på tværs af mindst to, helst tre, zoner, så tabet af én nedgraderer kapaciteten frem for at forårsage et nedbrud. Det er billig forsikring uden nogensinde en god undskyldning for at springe over.

Multiregion er en tungere beslutning, bundet til jeres robusthed og genopretningsmål (kapitel 3.5) og jeres katastrofegenopretningsplan (kapitel 9.5). At sprede på tværs af regioner køber overlevelse af et helt regionssvigt og kan placere data tættere på brugerne, men det indfører reel omkostning, latens og konsistensproblemer, fordi synkron replikering på tværs af regioner er langsom, og asynkron replikering betyder at acceptere datatab ved failover. Beslut ud fra eksplicitte genopretningstids- og genopretningspunktsmål, ikke et vagt ønske om at være “højt tilgængelig.” De fleste systemer har brug for robust multizone og en testet multiregion-genopretningssti; få har reelt brug for aktiv-aktiv på tværs af regioner, og dem, der bygger det uden at have brug for det, betaler for kompleksiteten hver dag.

Behandl modellen med delt ansvar som en arkitektonisk grænse

Cloudsikkerhed kører på en model med delt ansvar: udbyderen sikrer skyen (fysiske faciliteter, hypervisoren, de administrerede tjenesters indre) og du sikrer det, du lægger i skyen (dine data, adgangskontroller, netværkskonfiguration og kode). Den præcise linje flytter sig, efterhånden som du klatrer op ad servicespektret. Med IaaS patcher du operativsystemet; med en administreret database gør du ikke, men du ejer stadig, hvem der kan forbinde, og om dataene er krypteret. De dyreste hændelser kommer af at misforstå denne linje, mest berømt den åbne lagerspand, der lækker millioner af poster, fordi nogen antog, at udbyderen gjorde den privat som standard.

Gør grænsen eksplicit i dine designs og overlad detaljerne til kapitel 4.3, som dækker infrastruktur- og cloudsikkerhed i dybden. Arkitektonisk er imperativerne konstante: krypter data i hvile og under transport som standard, giv mindste privilegium gennem identitet frem for netværksposition, hold sprængradien af enhver enkelt legitimation lille, og antag at enhver internet-tilgængelig ressource vil blive prøvet af inden for minutter. Bag dette ind i jeres landing zone, så teams arver det.

Provisionér alt som kode, inde i en styret landing zone

I en moden cloudpraksis eksisterer ingen produktionsressource, fordi et menneske klikkede i en konsol. Alt er erklæret i infrastruktur som kode (kapitel 8.2), versionsstyret, gennemgået og anvendt gennem en pipeline, så jeres infrastruktur er reproducerbar, reviderbar og kan diffes. Det er, hvad der gør multizone, multiregion og katastrofegenopretning reelt i stedet for aspirationelt: I kan stille et identisk miljø op i en ny region, fordi miljøet er et program, ikke en hukommelse.

Pak den kode ind i en landing zone: et forudbygget, styret fundament af konti (eller abonnementer eller projekter), netværk, identitet, logning og rækværk, hvert team bygger på. Brug separate konti som sprængradie- og faktureringsgrænser, så ét teams fejl ikke kan nå et andets data, og hver krone kan spores til en ejer. Håndhæv rækværk som policy-as-code, der forhindrer forbudte konfigurationer (en offentlig database, et ukrypteret volumen, en ressource i en ikke-tilladt region) frem for at støtte sig til gennemgang bagefter. Et centralt platformsteam ejer som regel landing zonen, hvilket forbinder dette kapitel til platformsudvikling (kapitel 8.4) og til containere og cloud-native runtimes (kapitel 8.3).

Prissæt indlåsning ærligt, og vær skeptisk over for multicloud

Leverandørindlåsning er omkostningen ved at skifte udbyder, og den er et spektrum, ikke en binær. At bruge en udbyders administrerede kø skaber noget indlåsning; at bruge dens proprietære maskinlæringsplatform skaber meget. Den refleksive frygt for den driver teams til at ofre reel gearing (de administrerede tjenester, der gør skyen værd at bruge) for at bevare en portabilitet, de aldrig vil udøve. Det ærlige træk er at prissætte den: for hver betydelig afhængighed så estimér, hvad det reelt ville koste at forlade den, og vej det mod, hvad tjenesten sparer jer nu. At abstrahere en administreret tjeneste væk for at forblive portabel koster ofte mere, permanent, end den migrering, du forsikrer mod, nogensinde ville.

Det er grunden til, at ægte multicloud (at køre den samme arbejdsbyrde på tværs af to udbydere) som regel er cargo-kult frem for strategi. Det tvinger dig ned til den laveste fællesnævner, fordobler din driftsflade og multiplicerer den ekspertise, dine teams skal holde, alt sammen for at afdække en risiko, der sjældent materialiserer sig. Der er legitime grunde til at røre mere end én udbyder: en best-of-breed SaaS fra en anden leverandør, en tilsynsmyndigheds robusthedspåbud eller et bevidst suverænitetskrav (kapitel 10.11). Hybridcloud, at beholde nogle systemer on-premises forbundet til skyen, er ofte uundgåelig under virksomhedsmigrering og for data, der juridisk ikke kan flytte. Vælg disse med klare øjne og en skriftlig begrundelse, ikke fordi et slidedæk sagde “multicloud.”

Arkitektér for omkostning, og adoptér velarkitekteret tænkning

I skyen er en arkitektonisk beslutning en udgiftsbeslutning: overprovisionering “for en sikkerheds skyld” viser sig på næste måneds faktura. Behandl omkostning som en kvalitetsegenskab, du designer til, og adoptér FinOps-praksis, disciplinen med delt finansielt ansvar for cloududgifter (kapitel 9.4), så ingeniørarbejde, økonomi og produkt ejer regningen sammen. Mærk hver ressource med en ejer, gør omkostning synlig pr. team og pr. tjeneste, ret størrelse løbende, brug autoskalering, så du betaler for belastning frem for for spids, og udnyt de prisløftestænger (aftaler om forpligtet brug, spotkapacitet til afbrydelig arbejde), skyen tilbyder.

Ud over omkostning så brug et velarkitekteret framework som gennemgangstjekliste. De store udbydere udgiver hver et, og de konvergerer på de samme søjler: pålidelighed, sikkerhed, omkostningsoptimering, ydeevneeffektivitet, driftsekspertise og bæredygtighed. Kør en let gennemgang ved designtid og periodisk derefter, score systemet mod hver søjle og registrér hullerne som sporet arbejde. Det er en billig måde at fange den afvejning, du ikke lagde mærke til.

Afvejninger: fordele og ulemper

Tilgang	Fordele	Ulemper
Løft-og-flyt (rehost)	Hurtig, lav indledende indsats, forlader datacentret hurtigt	Beholder gammel skrøbelighed, misser elasticitet og administrerede tjenester, koster ofte mere
Cloud-native redesign	Fuld elasticitet, robusthed, gearing fra administrerede tjenester	Højere indsats og færdigheder på forhånd; større ændring at absorbere
Enkelt cloud, dyb integration	Enkelhed, maksimal gearing, lavere driftsflade	Koncentreret indlåsning og udbyderrisiko
Multicloud (samme arbejdsbyrde, to udbydere)	Afdækning mod udbydersvigt, forhandlingsgearing	Laveste-fællesnævner-design, fordoblet drift og ekspertise
Hybrid (cloud plus on-premises)	Møder dataresidens- og legacy-begrænsninger, trinvis migrering	Netværkskompleksitet, to driftsmodeller at køre på én gang
Serverless / høj grad af administreret	Minimalt manuelt slid, skalerer til nul, hurtig levering	Mindre kontrol, udbyderspecifik, koldstarts- og kvotegrænser

Den centrale spænding er kontrol versus gearing, og den løber gennem hver række. Jo mere du overdrager til udbyderen, desto hurtigere bevæger du dig og desto mindre driver du, på bekostning af dybere kobling. Løsningen er ikke at vælge én pol, men at placere hver arbejdsbyrde bevidst: klatr højt op ad det administrerede spektrum til rørføring af standardvaretypen, bliv lavere, hvor kontrol reelt tjener sit brød, og prissæt indlåsningen i begge retninger frem for at behandle portabilitet som gratis og afhængighed som synd. Store organisationer kommer i vanskeligheder, når de lader frygt (for indlåsning, for skyen, for omkostning) træffe dette valg ved refleks i stedet for ved analyse.

Spørgsmål til drøftelse med dit team

Hvilke af vores arbejdsbyrder er løftet-og-flyttet, og betaler vi cloudpriser for datacenterarkitektur? Det er almindeligt at migrere under en deadline, rehoste alt som det er og erklære sejr, og så opdage at regningen er højere end datacentrets, og at ingen af robusthedens eller elasticitetens fordele materialiserede sig. Den ærlige revision er at liste jeres større arbejdsbyrder og markere hver som rehostet, re-platformet eller reelt redesignet, og så se på, hvilke der stadig kører på fastdimensionerede, altid-tændte, enkeltzone-fodaftryk. Noget løft-og-flyt er et legitimt første skridt, så spørgsmålet er ikke, om I gjorde det, men om I har en plan og en tidslinje for at gå videre. Tag omkostning pr. arbejdsbyrde og hændelseshistorikken med, fordi de arbejdsbyrder, der både er dyre og skrøbelige, er, hvor redesign betaler sig hurtigst. Hvis alt stadig har formen af det gamle datacenter et år efter migrering, købte I et dyrere datacenter.
Når en tilgængelighedszone eller en hel region fejler, hvad sker der egentlig, og har vi testet det? Mange teams tror, de er robuste, fordi de udrullede til en sky, uden at have designet deres fejldomæner eller nogensinde have trukket stikket ud for at tjekke. Den konkrete version: for hvert kritisk system, hvor mange zoner spænder det over, hvad er det dokumenterede genopretningstids- og genopretningspunktsmål, og hvornår kørte vi sidst en game day, der fejlede en zone eller øvede en regionsgenopretning? Multizone bør være det umærkelige grundniveau, så enhver kritisk enkeltzone-arbejdsbyrde er et fund; multiregion er en tungere, dyrere beslutning bundet til eksplicitte genopretningsmål, ikke adopteret som standard. Tag jeres afhængighedskort med, fordi den fejl, der gør ondt, som regel er en fælles tjeneste (en database, en identitetsudbyder), hvis fejldomæne ingen kortlagde. Robusthed, I aldrig har testet, er en hypotese, ikke en egenskab.
For vores største udbyderafhængigheder, hvad ville det reelt koste at forlade dem, og er det en pris, der er værd at betale for at undgå? Indlåsningsdebatter har tendens til at køre på ideologi frem for tal, med den ene lejr, der abstraherer hver administreret tjeneste væk for at forblive portabel, og en anden, der ignorerer koncentrationsrisiko helt. Forankr det: vælg jeres tre dybeste afhængigheder, estimér den reelle ingeniøromkostning og forløbne tid til at erstatte hver, og vej det mod, hvad tjenesten sparer jer i dag, og hvor sandsynligt det er, at I nogensinde skifter. Læg de risici på, som portabilitet ikke løser, såsom en tilsynsmyndighed, der kræver en anden kilde, eller en suverænitetsregel om, hvor data må bo, da de kan retfærdiggøre multicloud eller hybrid, selv når ren økonomi ikke ville. Målet er en bevidst, skriftlig position pr. afhængighed, ikke en generel politik. Når I prissætter det, viser den frygtede indlåsning sig for det meste at være billigere at acceptere end det abstraktionslag, der bygges for at undgå den.
Hvilke tjenester driver vi selv, som udbyderen gerne ville drive for os, og hvad koster det valg i ingeniørtimer? Hele skyens gearing er at overdrage patching, backups, failover og skalering til nogen, hvis fuldtidsjob er netop de ting, men alligevel beholder teams rutinemæssigt en selvdrevet database, beskedmægler eller søgeklynge af vane eller malplaceret stolthed. For en stor organisation er omkostningen ikke ét teams manuelle slid, men det samme udifferentierede driftsarbejde genopfundet i et dusin hjørner, hver en vagtrotation og en kilde til drift. Det modstridende hensyn er ægte: specialiseret hardware, licensvilkår, en usædvanlig compliance-grænse eller ydeevne, en administreret mulighed ikke kan møde, kan retfærdiggøre at blive lavere på spektret, så svaret er pr. tjeneste frem for generelt. Tag en opgørelse over selvdrevne tjenester med, de ingeniørtimer hver bruger på vedligeholdelse og hændelser og den administrerede alternativs pris, og kræv et arkitekturbeslutningsregister for hvert “vi driver selv”, der genretfærdiggøres årligt. I virksomheds- og offentlige sammenhænge så tilføj, om det selvdrevne valg faktisk er en compliance- eller licensbegrænsning eller blot inerti klædt ud som en, fordi revisorer og budgetejere vil stille det samme spørgsmål.
Kan vi se, hvad hvert team og hver tjeneste koster os denne måned, og føler en navngiven person sig ansvarlig for det tal? Cloududgifter svulmer stille op, fordi den samme selvbetjening, der lader en ingeniør provisionere en global database på minutter, også lader vedkommende lade den køre i spidsstørrelse for evigt, og ingen enkelt fakturalinje nogensinde ser alarmerende ud. I en stor organisation uden omkostningssynlighed pr. team og pr. tjeneste opdager økonomien problemet måneder for sent, og reaktionen er en stump fastfrysning, der straffer de disciplinerede sammen med de ødsle. Spændingen er reel: at jage hver krone sinker leveringen, så målet er ansvarlighed og størrelsesjustering, ikke asketisme, med omkostning behandlet som en kvalitetsegenskab, I designer til, frem for en rapport, I læser bagefter. Tag en omkostningsfordeling pr. team med, andelen af udgifter, der er umærket eller ikke kan tilskrives, nuværende udnyttelse mod provisioneret kapacitet og hvor aftaler om forpligtet brug eller spotkapacitet efterlades på bordet. For virksomheder og offentlige organer så bind dette til FinOps-praksis og til offentlig udgiftsgranskning, da en umærket ressource ikke blot er spild, men et revisionsfund, der venter på at ske.
Kan et team stille et offentligt datalager, et ukrypteret volumen eller en ressource i en forbudt region op lige nu, og ville vi overhovedet finde ud af det? De fleste dyre cloudhændelser er fejlkonfigurationer, ikke brud hos udbyderen, og modellen med delt ansvar betyder, at den lækkende lagerspand eller databasen åben mod internettet ligger solidt på jeres side af linjen. At forebygge dette i skala på tværs af mange teams er et landing zone-spørgsmål: rækværk håndhævet som policy-as-code, der blokerer forbudte konfigurationer, før de findes, frem for en gennemgang bagefter, der finder dem, når posterne allerede er lækket. Det modstridende pres er udviklerautonomi, fordi rækværk, der er for stramt, skubber teams ind i skyggekonti, så designet må forebygge det reelt farlige, mens der levnes plads til at bevæge sig. Tag en opgørelse over de rækværk, der faktisk håndhæves, et ærligt forsøg på at provisionere en ikke-kompatibel ressource i en reel konto og opdagelsesforsinkelsen, når forebyggelse svigter. I regulerede og offentlige sammenhænge så forbind dette til dataresidens og autorisationsregimer, for en ressource i en ikke-tilladt region er ikke et stilbrud, men et juridisk brud, en revisor vil behandle som en rapporteringspligtig hændelse.

Sektorperspektiv

Startup. Gå cloud-native på en enkelt udbyder fra dag ét og accepter indlåsningen med vilje. Kør på serverless og administrerede tjenester, der skalerer til nul, og lad to ingeniører eje hele platformen, fordi din knappeste ressource er opmærksomhed, ikke portabilitet. Sæt et hårdt loft på udgifterne, hold alt i infrastruktur-som-kode, så et viralt øjeblik ikke bliver et nedbrud, og skriv indlåsningsbeslutningen ned, så den kan genbesøges i skala, frem for at foregive at den er midlertidig.

Lille virksomhed. Uden en platformsingeniør og med et stramt budget så behandl skyen som noget, du forbruger frem for driver. Foretræk SaaS og fuldt administrerede tjenester frem for alt, du selv kører, støt dig til udbyderens sikre standarder, og lad den administrerede database håndtere backups og failover, så ingen andre behøver. Ram valget ind som køb-versus-byg med en stærk tommel på køb, sæt en faktureringsalarm, så en glemt ressource ikke kan dræne måneden, og ræk ud efter en lavkode- eller administreret mulighed, før du stiller servere op, du ikke kan bemande.

Stor virksomhed. Jeres cloudhistorie er en migreringshistorie på tværs af mange teams, så arkitekturen er reelt et styringsproblem. Stil en styret landing zone op med konti pr. enhed som sprængradie- og faktureringsgrænser, rækværk der krypterer som standard og policy-as-code, der blokerer offentlige datalagre, og lad et centralt platformsteam eje det fundament. Kør FinOps med showback pr. team, luk porten for betydelige designs med en velarkitekteret gennemgang, og styr hybridforbindelsen til de legacy-registersystemer, der ikke flytter i årevis.

Offentlig sektor. Indkøbsregler, åbenhed og suverænitet former hver beslutning. Udrul i en autoriseret eller offentlig cloudregion, dokumentér grænselinjen for delt ansvar linje for linje til revisorer, og fastlås lager og behandling til zoner i landet med policy-as-code, der blokerer enhver ressource i en ikke-tilladt region. Forfølg det krævede autorisationsregime, hold revisionsdokumentation som en git-historik frem for en panik, og foretræk administrerede tjenester, hvis compliance-holdning udbyderen vil attestere, frem for skræddersyet infrastruktur, I selv skal certificere.

Eksempler

Startup. Et startup med tolv medarbejdere bygger cloud-native fra dag ét på en enkelt udbyder og føler ingen skyld. API’en kører på serverless-funktioner, der skalerer til nul natten over, dataene bor i en administreret Postgres med automatiske backups og multizone-failover, og baggrundsjob kører på en administreret kø. Alt er defineret i infrastruktur-som-kode, og to ingeniører ejer hele platformen, fordi udbyderen driver de svære dele. Da et viralt øjeblik sender trafikken op med et faktor halvtreds på en time, absorberer autoskalering det, og regningen stiger i forhold til reelt forbrug og falder så igen. Grundlæggerne accepterer bevidst indlåsning som prisen for at bevæge sig hurtigt med et lille team, og de skrev den beslutning ned for at genbesøge i skala.

Stor virksomhed. Et multinationalt forsikringsselskab med tre hundrede legacy-applikationer kører en flerårig migrering styret af “6 R’erne” (rehost, re-platform, repurchase, refactor, retire, retain). Standardapps med lav værdi rehostes hurtigt for at forlade to datacentre inden en deadline; kernepoliceplatformen refaktoreres til cloud-native; hjemmelavede værktøjer genkøbes som SaaS; og forældede systemer pensioneres. Et centralt platformsteam ejer en landing zone med konti pr. forretningsenhed, rækværk der krypterer som standard og policy-as-code, der blokerer offentlige datalagre, mens hybridforbindelse binder skyen til de mainframe-registersystemer, der ikke flytter i årevis. Omkostning styres gennem en FinOps-praksis med showback pr. enhed, og en velarkitekteret gennemgang lukker porten for hver applikations produktionslancering.

Offentlig sektor. Et nationalt agentur, der leverer en borgerydelsestjeneste, er juridisk forpligtet til at holde beboerdata inden for nationale grænser og til at køre på autoriseret infrastruktur. Det udruller i udbyderens offentlige cloudregion og forfølger en autorisation under et regime som FedRAMP i USA (med compliance-arbejdet i kapitel 4.6) og dokumenterer grænsen for delt ansvar linje for linje til revisorer. Dataresidens og bredere suverænitetsbekymringer (kapitel 10.11) driver en arkitektur, der fastlåser lager og behandling til zoner i landet og blokerer, gennem policy-as-code, enhver ressource i en ikke-tilladt region. Systemet spænder over tre tilgængelighedszoner med en testet genopretningsplan på tværs af zoner og provisionerer alt som kode, så revisionsdokumentation er en git-historik frem for en panik.

Business case: motivation, ROI og TCO

Skyens overskriftsløfte er at omsætte investeringsudgifter til driftsudgifter: i stedet for at købe servere år forud for efterspørgslen og køre dem ved lav udnyttelse betaler du for det, du bruger, og skalerer med forretningen. Det er reelt, men det dybere afkast er hastighed og fokus. En administreret tjeneste, der udsletter patching, backups og failover, giver de ingeniørtimer tilbage til produktarbejde, og provisionering på minutter frem for måneder komprimerer tiden fra idé til produktion. Elasticitet betyder, at du holder op med at betale for spidskapacitet, du bruger to gange om året. Når arkitekturen er rigtig, akkumuleres disse til totale ejeromkostninger, der slår datacentret på både omkostning og evne.

Omkostningen ved at tage fejl er lige så reel, så business casen må være ærlig. Løft-og-flyt uden redesign hæver ofte omkostninger, mens det leverer ingen af fordelene, og ukontrollerede udgifter kan svulme stille op på tværs af dusinvis af teams, til økonomien slår alarm. Ram sagen ind over for ledelsen omkring tre løftestænger: hastighed (hurtigere levering og kortere provisionering), robusthed (færre og kortere større hændelser) og optionalitet (at gå ind på et nyt marked eller en ny region uden et datacenterprojekt). Sæt tal på det undgåede datacenterrefresh, den reducerede bemanding til standardinfrastruktur og de forebyggede nedbrudsminutter, og sæt dem over for migreringsomkostningen og den løbende FinOps- og platformsinvestering. Det stærkeste argument er sjældent rene omkostningsbesparelser; det er optionsværdien af at bevæge sig hurtigere end konkurrenter, der stadig venter på hardware.

Anti-mønstre og faldgruber

Løft-og-flyt, og kald det “cloud”. At rehoste et datacenterdesign på lejet infrastruktur fanger omkostningerne og ingen af fordelene.
Konsol-klikket infrastruktur. Ressourcer oprettet i hånden er ugentagelige, udokumenterede og umulige at genoprette eller revidere; behandl enhver manuel produktionsændring som en fejl.
Cargo-kult multicloud. At køre den samme arbejdsbyrde på tværs af to udbydere for at afdække en sjælden risiko og betale i kompleksitet og laveste-fællesnævner-design hver dag.
Enkeltzone-”høj tilgængelighed”. At tro, at skyen er robust som standard, mens kritiske arbejdsbyrder kører i én zone uden testet failover.
At misforstå delt ansvar. At antage at udbyderen sikrer det, du faktisk ejer, den klassiske vej til en offentlig spand, der lækker millioner af poster.
Omkostning som en eftertanke. At designe uden hensyn til udgift og så opdage, at fakturaen traf dine arkitektoniske beslutninger.

Modenhedsmodel

Niveau 1, Opstart: Cloudbrug er ad hoc og reaktiv. Teams klikker ressourcer i eksistens i fælles konti, arbejdsbyrder er løftet-og-flyttet, og der er ingen landing zone, ingen omkostningssynlighed, og robusthed antages frem for designes. Det første alvorlige nedbrud eller faktura-chok er en overraskelse.
Niveau 2, Udvikling: Grundlæggende praksis dukker op, men varierer fra team til team. Noget kerneinfrastruktur provisioneres som kode, og nogle arbejdsbyrder kører multizone, nogle få konti er adskilt, men dækningen er ujævn: servicemodel- og indlåsningsvalg træffes af vane, omkostning overvåges bagefter, rækværk er inkonsistent, og multiregion-genopretning er utestet.
Niveau 3, Standardisering: En styret landing zone med policy-as-code-rækværk er dokumenteret og håndhævet i hele organisationen. Et platformsteam ejer fundamentet, alt i produktion provisioneres som kode, velarkitekterede gennemgange lukker porten for betydelige designs, og køb-versus-byg- og fejldomænebeslutninger er bevidste og registreret ensartet i hvert team.
Niveau 4, Styring: Landskabet måles og styres mod baselines. Omkostning pr. team og pr. tjeneste følges gennem FinOps mod mål, genopretningstids- og genopretningspunktsmål verificeres frem for påstås, rækværksovertrædelser og konfigurationsdrift fremtræder som målinger, størrelsesjustering drives af udnyttelsesdata, og hver go/no-go-beslutning bakkes op af dokumentation fra omkostnings-, pålideligheds- og sikkerhedsdashboards.
Niveau 5, Orkestrering: Cloudarkitektur forbedres løbende og er integreret med forretnings- og risikoplanlægning. Fejldomæner udøves gennem rutinemæssige game days, størrelsesjustering og prissætning er automatiseret, suverænitet og residens håndhæves af politik, servicemodel- og indlåsningspositioner genprissættes efter en regelmæssig kadence, og arbejdsbyrdeporteføljen genbalanceres adaptivt, efterhånden som markedet, priserne og risikobilledet skifter.

Idéer til drøftelse

Hvor på IaaS-til-serverless-spektret sidder hver af jeres større arbejdsbyrder, og kunne nogen klatre højere for at afgive manuelt driftsslid uden at miste kontrol, I faktisk har brug for?
Hvis jeres primære udbyder hævede priserne kraftigt eller led et nedbrud i en region på flere dage, hvad er så jeres reelle plan, og retfærdiggør den nogen multicloud- eller hybridkompleksitet, I bærer?
Hvem ejer jeres landing zone og dens rækværk, og kan et team i dag udgive en ikke-kompatibel ressource (offentligt datalager, ukrypteret volumen, ikke-tilladt region)?
For en reguleret eller suveræn arbejdsbyrde, kan I fremlægge grænsen for delt ansvar og den autoriserede konfiguration som dokumentation uden en brandøvelse?

Vigtigste pointer

Design til skyen frem for at fotografere dit datacenter; elasticitet, administrerede tjenester og bevidsthed om fejldomæner er grundene til at være her.
Klatr op ad servicemodelspektret mod administreret og serverless til standardarbejde, og hold kontrol lavere kun, hvor den reelt tjener sin omkostning.
Gør regioner og tilgængelighedszoner til eksplicitte fejldomæner: multizone som grundniveau, multiregion bundet til testede genopretningsmål.
Provisionér alt som kode inde i en styret landing zone med policy-as-code-rækværk, separate konti og et platformsteam, der ejer fundamentet.
Prissæt leverandørindlåsning ærligt i begge retninger, og vær skeptisk over for multicloud, medmindre en konkret regulatorisk, suverænitets- eller best-of-breed-grund kræver det.
Behandl omkostning som en førsteklasses kvalitetsegenskab gennem FinOps, og kør velarkitekterede gennemgange for at fange de afvejninger, du missede.

Referencer og videre læsning

Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework and Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (and the “6 Rs” migration strategies)
J.R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, FedRAMP programme documentation and security baselines
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing