Vi har valgt å benytte Amazon Web Services (AWS) som sky-leverandør. Dette har vi hatt meget gode erfaringer med. AWS er den desidert største av aktørene på det globale markedet. De har lengst fartstid, og er av Gartner rangert som den beste leverandøren i begge dimensjoner på sin «Magic Quadrant for Cloud Infrastructure as a service». Og det for 8. året på rad. Vår erfaring er at AWS gir oss meget høy grad av fleksibilitet. Ting kan løses og designes på mange ulike måter. Nye tjenester og forbedringer på eksisterende lanseres kontinuerlig, og det er en utfordring bare å kunne følge med på alle utvidelser slik at vi kan optimalisere driften ytterligere. Foreløpig er det kun nye systemer vi har valgt å legge ut i skyen. Disse er designet fra starten av med tanke på å utnytte sky-teknologien på best mulig måte.
Valget av sky-leverandør er allikevel ikke det mest kritiske, sålenge en velger en av de tre ledende aktørene – Amazon AWS, Microsoft Azure, eller Google Cloud. Multi-sky løsninger er også i vinden om dagen, men det krever ytterliggere investeringer som må veies for og imot.
Høyere grad av automatisering
Sky-teknologien gjør det enklere å automatisere flere av de repeterende utviklings- og driftsaktivitetene enn tidligere. Man snakker for eksempel om Infrastruktur-som-Kode. Med det mener man at det er mulig å kode alt oppsett og konfigurasjon av servere, nettverk, sikkerhetssoner, brannmurer, last-balanserere, databaser, og all annen infrastruktur man behøver for å kjøre applikasjoner i produksjon. Vi valgte å investere endel tid og krefter for å gjøre dette riktig fra starten av. Beskrivelse og oppsett av hvert miljø blir lagret i kildekode-systemet på lik linje med applikasjonskode. Vi oppnår full kontroll på alle endringer i miljøet og hvem som gjort dem. Med ett blir det mulig å opprette identiske miljøer etter behov. Vi kommer tilbake til noen av fordelene med dette etterhvert.
Parallellt med å automatisere bygging av infrastrukturen, vil man også hel-automatisere bygging, testing, release, og deploying av alle tjenester og applikasjoner. Produksjonssetting hos oss skjer nå ved å oppdatere en tekst-fil i kildekoden med den versjonen av en tjeneste/applikasjon man ønsker i produksjon. Filen sjekkes inn, og deretter fikser systemet resten. Vi produksjonssetter etter behov, ikke ved faste intervaller. Jo oftere jo bedre. Det nye normale er produksjonssettinger flere ganger per dag.
Virtualisering
Vår arkitektur er basert på mikro-tjenester. Hver mikro-tjeneste har hvert sitt veldefinerte ansvarsområde og veldefinerte grensesnitt. En applikasjon kan ofte bestå av flere slike mikro-tjenester. En vesentlig fordel med slike mikro-tjenester er at endringer flyter fortere igjennom og at risikoen ved produksjonssetting blir vesentlig redusert. Man oppgraderer bare den berørte tjenesten. Det fører også til bedre kontroll på hvilke faktiske endringer som gjøres. I tillegg får vi muligheten til å justere ressursbruk for hver mikro-tjeneste individuelt. Tjenester som prosesserer mye datatrafikk skaleres ut, tjenester som er minne-intensive konfigureres med minne-optimaliserte server-instanser, osv.
For å redusere risiko ønsker vi ikke at flere mikro-tjenester kjører på samme server. Er det feil på en tjeneste skal ikke denne forårsake problemer for andre prosesser på samme server. Dette oppnår vi med virtualisering. Vi får fullstendig isolerte virtuelle servere som ikke kan påvirke andre deler i den underliggende server-parken. Slik virtualisering er en av kjerne-egenskapene til sky-leverandører. Å måtte ta ned en virtuell server, for eksempel, får ingen andre konsekvenser enn at denne ene instansen av en enkelt tjeneste blir terminert. Vi bygger docker-images av alle våre tjenester, og kjører disse i AWS sin container-tjeneste.
Virtualisering av servere er dessuten helt nødvendig for å oppnå skalerbare løsninger, mer om det siden.
Sikkerhet
Sikkerhet er noe som gjennomsyrer alle deler av en utviklings- og driftsprosess. La oss derfor begrense det til noen få konkrete områder hvor sky-baserte løsninger kan medføre økt sikkerhet:
Sikring av fysiske datasentre er kanskje det mest grunnleggende. Amazon beskriver selv sin håndtering av dette i et eget white paper. Heldigvis er det ikke lenger naturlig at de mest kritiske serverne plasseres på it-sjefens kontor. Samme white paper beskriver dessuten andre viktige sikkerhets-aspekter ved Amazon sin sky-løsning, som isolering av virtuelle servere.
Vi opererer med flere separate miljøer i skyen. Slik som byggemiljø, utviklingsmiljø, testmiljø, og produksjonsmiljø. Logger, statistikk, og alarmer blir automatisk sendt direkte til et eget miljø separat fra produksjonsmiljøet. Behovet for å logge på det enkelte miljø faller dermed bort med all automatiseringen. Det betyr for eksempel at vi ikke behøver egne brukere med skrive-rettigheter til produksjon. Angrepsflaten for potensiell hacking blir som følge av dette betydelig redusert. At all konfigurasjon er automatisert betyr også at risikoen for menneskelige feil reduseres kraftig.
Det var produksjonsmiljøet under ett. Hva så med tilgangen til hver enkelt applikasjon og tjeneste? Noen tjenester vi opererer med er serverless, dvs vi har ikke lengre noen server å forholde oss til. Kun kode-funksjoner som deployes rett i AWS. Angrepsflaten blir også deretter.
De fleste tjenestene våre er derimot bygget for å kjøre i containere. Disse blir bygget som ferdige images i vårt byggmiljø, og er i praksis ikke editerbare. Imaget inneholder kun de operativsystem prosesser og andre prosesser som er nødvendige for å kjøre den enkelte mikro-tjeneste. Eventuelle endringer krever bygging og deploying av nye images. Da vi aldri skal logge oss på den enkelte instansen for å hente ut informasjon eller gjøre endringer, har vi heller ikke åpnet for SSH tilgang. I praksis er eneste veien inn til en tjeneste via dets veldefinerte grensesnitt, API. Disse API’ene krever alle autentisering og autorisering. Trafikken er kryptert med SSL/TLS, og som en ekstra sikkerhet har vi lagt på roterende nøkler på meldingsinnholdet.
Forøvrig har kryptering blitt veldig mye enklere å ta i bruk etter sky-leverandørenes inntog. Det er ikke lenger utopi, men vanlig praksis å kunne kryptere alt, alltid. Vi logger i tillegg all bruk av krypteringsnøkler.
Sikkerhet går også på evnen til å reagere raskt idet man blir kjent med nye sårbarheter i systemet. Fordi vi nå kan og gjennomfører flere oppgraderinger av systemene hver eneste dag, vil feil og sårbarheter også kunne håndteres umidddelbart.
Økt leveransehastighet
Med leveransehastighet mener vi her tiden det tar fra et behov oppstår til denne endringen er ferdig laget og satt i produksjon. Behovet kan f.eks. være ny funksjonalitet i en eksisterende applikasjon, eller en helt ny applikasjon. Tradisjonelt går det med mye kalendertid i forbindelse med overleveringer fra et steg til det neste i et utviklingsløp. Sky-teknologi gjør veien til å ekte DEVOPS team mye lettere. Ett enkelt team er ansvarlig for alt fra design til drift og forvaltning for sine tjenester.
Endringer i infrastruktur utføres umiddelbart ved behov. Trenger vi mer minne til en applikasjon, endrer vi konfigurasjonen, og ruller ut applikasjonen på nye servere i løpet av minutter. Trenger vi en ny åpning i brannmuren, endrer vi konfigurasjonen, og porten er tilgjengelig på sekunder. Denne type smidighet sørger for besparelser på flerfoldige dager.
AWS er ikke bare «Infrastructure-as-a-service», den er også en «Platform-as-a-service». Amazon har utviklet en rekke med plattform-tjenester som de drifter selv, og er skalerbare, dynamiske, tilgjengelige, sikre, og pålitelige. Vi benytter disse der vi kan, pris tatt i beregning. Å slippe å sette opp databaser samt drifte disse selv, for eksempel, er meget tidsbesparende. Å slippe å lage en ny autentiseringsløsning for web-applikasjoner med alt det man behøver av mail/sms-utsendelser, glemt passord-funksjonalitet, med mye mer, er et annet eksempel. Ved å gjenbruke tilgjengelige tjenester der det er fornuftig, så blir tiden det tar å utvikle nye løsninger kortere.
Pålitelighet
AWS opererer med helt vanvittige oppetider og pålitelighet på sine globale tjenester. F.eks. datalagrings-tjenesten S3 som har en SLA på 99.999999999% mot tap av en enkelt datafil. Ved å benytte slike grunnleggende tjenester gjør vi også våre egne løsninger mer pålitelige.
Alle våre systemer er fysisk lokalisert i EU. Dette er hovedsakelig av juridiske årsaker. Systemene våre kjører parallellt i tre ulike fysisk separerte datahaller, med lik fordeling av ressursene. Går en av datahallene ned pga brann, oversvømmelse, ekstreme strømbrudd eller tilsvarende, så vil fortsatt systemene våre være operative. Kapasitet som ble benyttet i det feilede anlegget blir automatisk lagt til og fordelt mellom to de gjenstående. Et slikt scenario er dog ytterst sjeldent. Et mer sannsynlig scenario er av mindre omfang, disk-kræsj på en enkelt server for eksempel. Vi har last-balanserere som automatisk oppdager den feilede noden, og systemene vil starte opp en annen tilsvarende med identisk oppsett som den forrige. Dette er ikke merkbart for brukerne. Vi designer systemene med tanke på at enkelt-instanser kan gå ned når som helst. Ved å nettopp designe for feil, gjør vi systemene mer stabile. Både de kjørende prosessene, men også disker blir replikerte på tvers av datahallene.
En annen fordel med dette designet er at vi slipper nedetid ved oppgraderinger av systemene. Hvilket igjen gjør at vi kan oppgradere oftere. Dette forutsetter at to versjoner av systemet kan sameksistere i et begrenset tidsrom (som er typisk mindre enn ett minutt). Hvilket kan løses ved å designe for nettopp dette. Det samme skjer ved f.eks. sikkerhetspatching av operativsystemene.
Vi benytter databaser driftet av Amazon. Alle er konfigurert til å ta reglmessig backup. Amazon sine databaser har også støtte for noe man kaller point-in-time recovery. Her har vi mulighet å tilbakestille databasen til et hvilket som helst tidspunkt fra nå og 35 dager tilbake i dag, med en presisjon på ett sekund.
Skalerbarhet
Våre skaleringsbehov er knyttet til innsamling, prosessering, og formidling av sensordata. Sensordata utgjør data-volumet. Trafikken er relativt stabilt, og øker lineært – jo flere sensorer desto mer data. Allikevel har vi noen regelmessige og noen uregelmessige perioder hvor vi må håndtere vesentlig større data-mengder. Uregelmessige f.eks. dersom ett eller flere systemer lengre opp i verdi-kjeden først har vært nede, og så skal ta igjen det tapte.
Å sørge for å dimensjonere systemene sine riktig for faktisk bruk kan være utfordrende. Har vi for få eller ikke kraftige nok servere, klarer vi ikke ta unna trafikken. Systemet stopper opp. Det er krise. Har vi for mange eller for mye ledig kapasitet på serverne, betaler vi derimot for mye for ting vi ikke benytter. Ingen av delene er ønskelig. Med sky-teknologi har vi mulighet for elastisitet. Vi slipper å gjette på hva som trengs av fremtidig kapasitet. I stedet konfigureres systemene slikt at de justerer ressurs-kapasiteten dynamisk etter faktisk last/trafikk. Går trafikken opp, kan systemene automatisk øke kapasiteten. Går trafikken ned, kan systemene redusere kapasitet.
AWS sine globale tjenester er designet for ekstrem ytelse. Her betaler vi bare for det vi faktisk benytter til enhver tid. Deretter følger behov for skalering på våre egne tjenester. Som i praksis vil være å skalere ut/inn ved å øke eller redusere antall instanser av hver tjeneste. Dette kan hel-automatiseres. Tilslutt er det skalering av disker og databaser. Disse er det vanskeligere å få automatisert helt ut, men det er fortsatt mulig å skalere både opp og ut etter behov på samme måte som andre endringer i infrastrukturen.
Lavere driftskostnader
Amazon opererer med et spot-marked på sine virtuelle servere. Dette er i tillegg til vanlig salgspris som går på reservert kapasitet og bruk. Kontinuerlig legger Amazon til flere og nye servere i sine datahaller. For å kunne utnytte ledig kapasitet har de derfor lansert spot-prising, som i snitt har ligget på en tiendel av vanlig server-pris. Her byr man på tilgjengelige server-instanser og får dedikert en instans så lenge prisen på denne ikke overstiger budet. Dette evalueres hver time, året rundt. Det er altså ingen garanti for at vi får bruke akkurat denne ene virtuelle serveren mer enn en time. Typisk anbefales det å benytte spot-instanser til jobber som kjøres innimellom og ikke behøver konstant oppetid. Vi har derimot valgt å kjøre tilnærmet alle våre applikasjoner på spot-instanser. Med det reduserer vi server-kostnadene med ca 90%. For å kompensere for risikoen med at spot-instanser ikke lengre blir tilgjengelig, fordeler vi risikoen utover flere dimensjoner. Hver server-type har sin egen pris (AWS opererer med over 70 forskjellige server-spesifikasjoner man kan velge imellom, basert på modell, type og størrelse på cpu, minne, io, osv). I tillegg varierer prisene mellom de ulike datahallene. Applikasjonene våre kan kjøre på mange av de ulike server-typene, og har man en stor nok fordeling basert på disse to parameterne, er risikoen for ikke å få tilslag på samtlige minimal. Spot-priser vil heller aldri bli høyere enn vanlige priser. Dermed kan vi by på spot-instanser til samme pris som for vanlige instanser, uten at vi må betale mer enn det den faktisk koster. Det hender at enkelte instanser termineres, men dette er systemene våre designet for. Auto-skaleringen vil slå til, nye instanser starter opp og i praksis flytter applikasjonene over på disse. Dette er en hel-automatisk prosess og ikke merkbart for hverken oss eller brukerne.
Andre kost-reduserende tiltak er resultatet av alle de aspektene vi har omtalt til nå. Mest mulig automatisering, elastiske prismodeller, og økt leveransehastighet. Raskere tilbakemeldinger grunnet raskere leveranser hjelper oss i å unngå for mye arbeid med funksjoner og systemer som ikke gir reell verdi.
It-bransjen er bygget på dårlige metaforer
La oss avslutte med det etymologiske, og bruken av sky-metaforen som assosiasjon til internett, virtualiseringsbølgen, og eksterne massive datahaller. Det er lett å være skeptisk for det ukjente, noe som var opprinnelsen til bruken av sky som metafor. Vi påstår derimot at egenskapene ved en sky-løsning er udelt positive: de er ofte sikrere, mer pålitelig, har bedre kontroll, og er mer tilgjengelig enn tradisjonelle software-løsninger.