AWS i 24SevenOffice
av Vegard Berget og Erik Simonsen, Team AWSome
Hvor er vi og hvor skal vi
24SevenOffice er et, i teknologisk sammenheng, gammelt selskap med mye historie. Tradisjonelt har vi, med noen få unntak, brukt datasentre fra norske leverandører til å levere vår egen sky med våre egne tjenester. Vi har selvsagt sett hvordan verden har endret seg det siste tiåret, og vi har eksperimentert med hva utenlandske skytjenester kan gi oss av merverdi. Teknologiske og juridiske problemer har forhindret oss i å ta steget helt ut hos de store amerikanske skytjenestene, selv om vi har sett at disse kan tilføre verdi på en del områder. Det vi ønsker er å fortsette å levere vår egen sky, men at vi overlater utviklingen av noe av de mer grunnleggende tjenestene til større skyleverandører.
Vi har de siste årene kjøpt en del spennende tech-selskaper, noen av disse bruker allerede en skyleverandør, andre har en lignende historie som vår egen. Uansett er det nå et behov for å konsolidere litt rundt teknologi.
Derfor har vi nå bestemt oss for å satse mer på å utnytte mulighetene disse leverandørene gir, og hastigheten man kan få på utviklingsprosesser ved å ta i bruk ny teknologi.
Vi er så heldige at vi nå får muligheten til å tenke helt nytt og sette opp alt fra bunn av, med fokus på skalering og sikkerhet fra første spadetak. Det vil gi utviklerne stort spillerom, og redusere operasjonell kompleksitet samtidig som det vil forenkle prosessen med å integrere nye selskaper.
Dessverre er det fortsatt noen juridiske hindre som gjør at vi ikke kan flytte absolutt alt ut fra norske datasentre, men en del ting kan vi — og bør vi — flytte.
Public Cloud i 2022
Rom ble ikke bygget på en dag, og slik er det også her når vi nå setter i gang storsatsing på AWS. Dessverre kan vi ikke trykke på en knapp og vipps så kjører alle tjenester i AWS. Selv i 2022 er det en større jobb å migrere til sky. En skikkelig satsing på Public Cloud innebærer også at man tar i bruk de mulighetene og tjenestene som finnes der — og da kan man ikke bare lift&shift og håpe på det beste. Skyplattformene i dag er mye større og mer avanserte enn bare for noen år siden. Det er krevende å bygge ut en plattform etter “best practice” og holde dette ved like i et raskt forandrende miljø.
Vårt team sin oppgave er å stå for et fornuftig oppsett av AWS-kontoene, forenkle prosessen med å komme i gang, lage en del fellestjenester og i tillegg være tilgjengelig for diskusjoner rundt fornuftig skyarkitektur.
Valg av skyleverandør — Azure vs AWS vs GCP?
Vi har over tid gjort diverse små forsøk hos forskjellige skyleverandører, men når vi skulle storsatse fant vi det smart å velge en enkelt leverandør. Vår erfaring var at AWS var mer modent enn sine konkurrenter, samt at de har svært gode integrasjonsmuligheter via API’er og flere gode infrastruktur-som-kode-alternativer. Det samme ser vi også hos andre større virksomheter i Norge, deriblant DNB, som også satser stort på AWS. Så når vi måtte velge en leverandør ble det AWS.
Som tidligere nevnt, er vi så heldige at vi har muligheten til å gjøre ting riktig fra start — vi trenger ikke forhaste oss og har heller ingen tidsfrist for når vi skal være “ferdige” med overgangen til AWS. Det er et kontinuerlig løp hvor vi haster oss i et raskt, men forsvarlig tempo. Vi har et eget team som fokuserer på utvikling og drift av AWS, Team AWSome, og hvordan utviklingsteamene best kan ta i bruk AWS og hvordan det gjør hverdagen deres enklest mulig.
En forutsetning for alt dette er at disrupsjonen for eksisterende tjenester blir minimal og vi bestemte oss derfor tidlig for at de første tjenestene som skal i produksjon i AWS er nye tjenester. Slik får vi sikret trygg og god onboarding i utviklingsteamene og vi gir samtidig utviklingsteamene rom og mulighet til å eksperimentere og bli kjent med AWS og miljøet vårt på deres premisser. Samtidig kan vi i Team AWSome fokusere på å få satt opp organisasjonen, onboarde team, samle tilbakemeldinger og være en bistandsyter og ressurs inn mot teamene i overgangen. Ved å være tett på teamene kan vi på et tidlig tidspunkt oppdage eventuelle flaskehalser, utfordringer, problemer eller forbedringsmuligheter. Det gjør oss i stand til å raskt gjøre større og mer drastiske endringer om vi finner det nødvendig.
Vi ønsker at utviklingsteamene selv skal ha mest mulig frihet og mulighet til å ta gode valg. Vi prøver derfor å unngå å legge oss for mye opp i deres tjenester og applikasjoner, men tar heller en mer rådgivende rolle og fungerer mer som en sparringspartner. Det er dog noen kjøreregler av hensyn til sikkerhet og for å sikre god arkitektur.
Hvordan lykkes med Public Cloud i 2022?
Det som gjennomsyrer hele løsningen vi bruker er infrastruktur-som-kode. Dette gjelder både hvert enkelt prosjekt, men vi følger det samme kravet når det kommer til oppsettet av skyplattformen i seg selv. Ingenting gjøres manuelt — opprettelse av kontoer, oppsett av disse, tilgangsstyring, oppsett av DNS m.m. er også definert i IaC — i vårt tilfelle har vi valgt Terraform som kjører via Github Actions for oppsett av plattformen. Dermed kan vi også enkelt bruke Pull Request-reviews for å kvalitetssikre det som publiseres. Utviklingsteamene står fritt til å velge deres foretrukne verktøy, rammeverk og prosess så lenge det er helautomatisert fra GitHub Actions. Dette er en av måtene vi sikrer at utviklingsteamene får eierskap og autonomi ved bruk av AWS.
På toppen av organisasjonshierarkiet har vi en hovedkonto som styrer enkeltpålogging via Single-Sign-On og som inneholder såkalte “Organizational units” — en samling av kontoer som hører sammen.
Ideen her er at vi har dette som en grovinndeling:
Fellestjenester
Her kommer tjenester som går på tvers av alle kontoer til å ligge. Det kan dreie seg om DNS-oppsett, nettverk, logger osv. Disse er relativt statiske og det er sjelden vi legger til kontoer under denne paraplyen.
Sandbox
Her lager vi kontoer for hele team, enkeltpersoner eller enkeltprosjekter slik at man kan eksperimentere helt fritt. Her er det ingen krav om at infrastrukturen må defineres i kode, og man får full tilgang til konsollen. Vi kjører dog overvåkning av budsjetter, slik at vi raskt oppfatter kostbare tjenester som ikke er fjernet eller skrudd av.
Workloads
Her plasserer vi alle prosjekter som skal i produksjon. Hvert prosjekt får sin egen “Organizational unit” under Workloads — og hvert prosjekt får tre kontoer:
Development
For å teste ting. Her har utviklerne tilgang til å logge inn, men utgangspunktet er at alt her også skal komme fra IaC, men om man vil teste endringer eller se på data så kan man det.
Pre-Production
Dette er nest siste steg. Her har ingen utviklere innlogging, det er kun et spesifikt github-repo i et gitt miljø som har tilgang til å publisere hit. Her kan f.eks QA teste ting.
Production
Her legges ting i produksjon. De samme reglene for publisering av kode gjelder her: ingen tilgang for utviklere, kun for et prod-miljø i et spesifikt github-repo har tilgang til å publisere.
Overvåking
I 24SevenOffice bruker vi Datadog til generell overvåking, noe vi helt sikkert kommer tilbake med mer om i et senere blogginnlegg. Relevant for Team AWSome er automatisk oppsett av integrasjon mellom hver AWS-konto og datadog for overføring av logger og målinger. Her gjør vi riktignok en filtrering, og mengden av informasjon som går til Datadog er avhengig av om det er en produksjonskonto eller ikke. Vi har mulighet til å finjustere dette om det f.eks skulle være behov for full logging i en testkonto.
Avslutning
Rom ble som sagt ikke bygget på en dag, og i dette innlegget har vi kun skissert litt rundt våre tanker om bymuren. Målet vårt er at vi tilrettelegger for at teamene skal lage Panteon og Colosseum, mens vi står for bymur og veinett. Planen er å utdype med noen flere detaljer i en senere bloggpost, så om det er noe dere som leser ønsker utdypet så er det bare å si i fra, så kan det hende vi kommer inn på det i neste episode.
