Cloud

it-ressourcer lejet i timen hos en anden

Hvad det er

At leje computere, man aldrig får at se, er den korteste ærlige beskrivelse af cloud, i fuld længde cloud computing og i daglig tale ofte bare »skyen«: en udbyder ejer bygningerne, strømmen og hardwaren, og kunden tænder og slukker for servere, lager og netværk via en webkonsol eller et API og betaler for det, der blev brugt. Maskinerne står stadig i et datacenter; en anden har bare købt dem og lejer skiver ud til mange kunder på én gang.

En præcis definition kommer fra det amerikanske standardiseringsinstitut NIST, National Institute of Standards and Technology. Special Publication 800-145, skrevet af Peter Mell og Timothy Grance og udgivet i september 2011, beskriver cloud computing som en model for netværksadgang efter behov til en fælles pulje af konfigurerbare it-ressourcer, der kan stilles til rådighed og frigives igen med minimal administrativ indsats. Definitionen nævner fem kendetegn. Selvbetjening efter behov betyder en ny server uden at tale med nogen. Bred netværksadgang betyder, at tjenesten nås over nettet fra almindelige enheder. Ressourcepuljer betyder, at kunderne deler udbyderens hardware og typisk vælger et land eller et datacenter, aldrig et bestemt rack. Hurtig elasticitet betyder, at kapaciteten vokser og skrumper med behovet. Målt forbrug betyder, at brugen bliver målt, og det er det, der overhovedet gør en regning pr. time eller pr. gigabyte mulig.

En dedikeret server, der lejes et år ad gangen, ændres via en supportsag og faktureres til fast pris, består kun få af de prøver. Det er hosting, ofte et godt valg, men en anden kontrakt med en anden økonomi.

Samme dokument deler cloud-tjenester i tre modeller. Med infrastructure as a service (IaaS) lejer kunden virtuelle maskiner, diske og netværk og opdaterer selv styresystemet. Med platform as a service (PaaS) lægger kunden sin kode på udbyderens afviklingsmiljø. Med software as a service (SaaS) bruger kunden et færdigt program, for eksempel webmail. Dertil kommer fire udrulningsmodeller: offentlig cloud, som alle kan leje; privat cloud til én organisation, eventuelt i dens egne lokaler; fællesskabscloud, som deles af organisationer med fælles behov; og hybrid cloud, hvor to eller flere af dem er bundet sammen, så data og programmer kan flytte imellem dem. De mest kendte offentlige clouds er store platforme som AWS, Azure og Google Cloud, og ved siden af dem sælger mindre udbydere almindelige virtuelle maskiner til enklere priser.

Hvorfor det betyder noget

Cloud gør et indkøb til en løbende udgift, og det er det meste af beslutningen sagt i én linje. At købe servere betyder at betale på forhånd for kapacitet dimensioneret efter et gæt om næste års travleste dag. At leje betyder at betale hver måned for det, der er tændt, med ret til at ændre svaret i næste uge. For et nyt produkt eller en sæsonpræget forretning er den fleksibilitet en merpris værd. For et system, der har kørt i samme størrelse i tre år, bliver merprisen ved med at blive opkrævet, længe efter at nogen har haft brug for fleksibiliteten.

Den anden beslutning er, hvor højt op i stakken man lejer. En virtuel maskine ligner en server, teamet allerede kender, og den kan flyttes mellem udbydere med lidt mere end en kopi af disken. En administreret database, en serverless-funktion eller et proprietært datavarehus tager arbejde fra teamet, og hver af dem er samtidig et stykke af applikationen skrevet mod ét firmas grænseflade. Den sunde vane er at vide, hvad det ville koste at forlade hver administreret tjeneste, og at acceptere den pris bevidst i stedet for at opdage den ved en prisstigning.

Den tredje er ansvar. Når man lejer hardware, overdrager man bygningen, strømmen og hypervisoren; hvem der kan logge ind, hvilke porte der står åbne, og om data har en kopi et andet sted, bliver hos kunden. De store udbydere udgiver hver især en model for delt ansvar, der trækker den grænse, og konti, konfiguration og data ligger på kundens side i dem alle.

Sådan ser det ud i praksis

For en international kunde handlede det om regningen. Deres AWS-setup var overdimensioneret og havde samlet tjenester, de ikke længere brugte, så den månedlige udgift var drevet langt ud af proportion med forretningen. Arbejdet begyndte med en gennemgang af, hvad der faktisk kørte, skar de duplikerede og unødvendige tjenester væk og tilpassede resten til den reelle efterspørgsel i stedet for gæt på det værste tilfælde. Derefter blev systemerne flyttet væk fra AWS til mere omkostningseffektiv hosting, i etaper, så forretningen kørte videre under flytningen. Udgifterne faldt omkring ti gange uden tab af produktivitet.

Virksomhedens egen produktionsvært ligger i den modsatte ende af skalaen. Det er en cloud-instans med én kerne, 512 MB hukommelse og 10 GB disk, hvoraf omkring 464 MB er brugbare, og den leverer TLS for syv domæner, en git-forge, en Tor-onion-tjeneste, Gemini- og Gopher-servere, krypterede backups og blokering af indtrængen. Da det blev spørgsmålet, om instansen kunne bære onion-tjenesten, var svaret en dags målinger og ikke en større instans: der var hele dagen mindst omkring 310 MB af de 464 til rådighed, swap brugte 2,6 procent, og processoren var 99,7 procent ledig. Maskinen koster mindre om måneden end en frokost, og mail holdes bevidst væk fra den, fordi en mailserver kræver luft, som denne maskine allerede har brugt.

At leje betyder også at stole på udbyderens kopi, indtil noget efterprøvet afløser tilliden. Alt, hvad virksomheden har, lå på én cloud-instans, og dens udbyder-snapshot var hele gendannelsespositionen: i samme konto som maskinen, krypteret af ingen her og aldrig brugt til en gendannelse. Nu sender en systemd-timer et krypteret, dedupliceret restic-snapshot til lager hos en anden udbyder over SFTP, beskærer det og tjekker dets integritet, og en dead man’s switch pinges kun ved succes. Én gang om måneden henter en øvelse en kendt fil tilbage og sammenligner den, så det, der testes, er en gendannelse.

Hvor det går galt

Clouds svigter sjældnere end vanerne omkring dem, og de almindelige problemer er langsomme, stille og dyre.

Regningen vokser, mens produktet har samme størrelse. Ressourcer hober sig op: en testserver, der kører videre efter testen, en disk, der faktureres efter at dens maskine er slettet, snapshots, der gemmes for evigt. At flytte data ud af en udbyder eller mellem dens regioner måles også, så logs og backups, der sendes over de grænser, koster ved hver kopi. Mærk hver ressource med en ejer og et formål, opsæt en budgetalarm, og læs regningen linje for linje én gang om måneden.

Kapaciteten dimensioneres til en dag, der aldrig kommer. Maskinstørrelser vælges én gang, ved opstarten, ud fra et gæt om det værste tilfælde, og gættet overlever dem, der lavede det. Mål, hvad et system bruger i en normal uge og i en travl uge, dimensionér efter det med en margin, og lad autoskaleringen skrumpe lige så villigt, som den vokser.

Udbyderens snapshot behandles som backuppen. Det ligger i samme konto, bag de samme loginoplysninger og hos det samme firma som maskinen, det beskytter, så et stjålet login eller en suspenderet konto tager serveren og dens eneste kopi på én gang. En rigtig backup ligger under andre loginoplysninger, helst hos en anden udbyder, krypteret med en nøgle, som den udbyder aldrig har haft, og den gendannes efter en fast plan.

Sikkerheden bliver, hvor standardindstillingerne efterlod den. De typiske åbninger er en firewallregel, der lukker SSH ind fra hele internettet, en langtlevende adgangsnøgle i en udviklers dotfiles, en administratorkonto brugt til hverdagsarbejde og en lagerbucket gjort offentlig til en enkelt demo. Giv den mindste adgang, der løser opgaven, foretræk kortlivede loginoplysninger, kræv en ekstra faktor ved hvert menneskeligt login, og hold konfigurationen i kode, så en ændring af den bliver gennemgået.

At flytte væk viser sig at kræve en omskrivning. Hver proprietær kø, funktionsplatform og databasedialekt binder koden lidt fastere til én udbyder. Hold kernen på åbne grænseflader, hvor det er billigt, for eksempel PostgreSQL, containere og almindelige virtuelle maskiner, og skriv udgangsprisen for hver proprietær tjeneste ned, når den tages i brug.

Læs mere

Ordliste