Utvikleropplevelse på SPEED

SPEED — Service Platform (for) Ensuring Efficient Delivery

I løpet av de 3 siste årene har vi sammen med Møller Digital etablert en golden path skyplattform, under navnet SPEED. Skyplattformen sin oppgave er å tilby et sikkert, stabilt og robust miljø for applikasjonene vi utvikler. Det er kun et lite team, cloud-teamet, som sørger for utvikling, vedlikehold og kontinuerlig forbedringer av plattformen til glede for mange utviklingsteam. Og plattformen tilbyr nå kjøretidsmiljø for godt over 100 applikasjoner.

Plattformen er bygget opp ved hjelp av Azure Kubernetes Services (AKS), Argo CD, GitHub og utstrakt bruk av Terraform. Viktige prinsipper fra start har vært å automatisere oppsettet av plattformen, samt å kunne tilby høy grad av selvbetjening for de ulike applikasjonsteamene.

SPEED tilbyr rett og slett en solid motorvei der applikasjonene kan kjøre trygt. Ansvarsfordelingen mellom cloud-teamet og applikasjonsteamene er som følger:

• Cloud-teamet: sikrer at motorveien til enhver tid skal være trygg, sikker, effektiv og oppdatert.
• Applikasjonsteamene: har helhetlig ansvar for applikasjonen (bilen om du vil) som kjører på motorveien. Det betyr utvikling, overvåkning og vedlikehold av applikasjonen ➡️ you build it — you run it.

Hvordan komme i gang?

Ethvert applikasjonsteam kan opprette applikasjoner selv, konfigurere sikkerheten og rulle ut til alle miljøer. Det første vi trenger å gjøre er å definere et team som skal jobbe med løsningen. Som alt annet; det skal defineres i Terraform.

Vi blir møtt med et sett med repositories som er pinned når vi logger inn på GitHub. Dette er repoer som eies av cloud-teamet, men hvor hvem som helst kan gjøre endringer for så å sende inn en pull-request.

Repoet cloud-teams er der vi starter. Vi kloner ned repoet og finner frem til mappen som heter Teams. Det eneste vi trenger å gjøre er å legge inn en enkel yaml-fil som forteller hvilken plattformfunksjonalitet vi ønsker å gi teamet, samt hvilke personer som er medlemmer av teamet

description: Eksempel på Team definisjon
members:
  - teamMedlem1@eksempel.no
  - teamMedlem2@eksempel.no
  - teamMedlem3@eksempel.no
  - teamMedlem4@eksempel.no
contacts:
  - type: slack
    name: Team support channel
    contact: #team-eksempel-support
notifications:
  team_slack_channel: "#team-new-car-sales-devs"
argocd:
  enabled: true
datadog:
  enabled: true
github:
  enabled: true
miro:
  enabled: true
slack:
  enabled: true
terraform_cloud:
  enabled: true

Kort oppsummert så vil denne beskrivelsen fortelle plattformen at et nytt team skal opprettes med tilgang til ArgoCD, Datadog, GitHub, Miro, Slack og Terraform. Filen sjekkes inn på en egen branch i repoet cloud-teams før man lager en pull request til cloud-teamet og sender den til cloud-teamet på Slack. I løpet av kort tid blir den godkjent og dermed har man et nytt team med rettighetene på plass for å faktisk kunne opprette selve applikasjonen. Ingen manuelle klikk, alt i kildekontroll og enkelt.

Dette betyr også at onboarding av teammedlemmer blir utrolig smidig og i prinsippet trenger vi bare å legge til epostadressen til ny bruker og dermed får denne brukeren umiddelbart riktige rettigheter til:

• ArgoCD
• Datadog
• GitHub: med tilgang til repoer eiet av teamet
• Miro
• Slack: pålogging og automatisk medlem av nødvendige kanaler
• Terraform Cloud: innlogging og tilgang til det som er teamet sitt

Ved offboarding av et teammedlem er det like enkelt; fjern epostadressen til brukeren og alle rettigheter fjernes for den brukeren.

Opprette en ny applikasjon

Når teamet er på plass, står teamet fritt til å lage applikasjoner. Å starte en ny applikasjon er ofte forbundet med å sette opp en del ting før utviklingen faktisk kan begynne. Igjen starter vi med et av de pinned repoene, denne gangen det som heter cloud-applications. En “cloud-application” er konseptet som samler en eller flere applikasjoner. Det betyr at vi kan rulle ut flere applikasjoner (frontend, API, worker, database ++) i samme “cloud-application”. Definisjonen i cloud-applications beskriver hva du trenger av repoer, hvilke docker-images som vil publiseres og om man skal rulle ut automatisk til de ulike miljøene. Under er et forenklet eksempel som viser hvordan beskrivelsen av en “cloud-application” kan se ut.

description: "Beskrivelse av eksempel applikasjon"
team: "eksempel-team"

repositories:
  "eksempel-api":
    reviewers: 1
    github:
      enable_docker_credentials: true
      enable_datadog_credentials: true

  "eksempel-frontend":
    reviewers: 1
    github:
      enable_docker_credentials: true

argo_cd:
  enabled: true

github:
  enabled: true

images:
  eksempel-frontend:
    auto_update_envs: ["dev"]

  eksempel-api:
    auto_update_envs: ["dev"]

Resultatet av kjøringen (terraform apply) for denne beskrivelsen er at teamet får:

• En Azure subscription for hvert miljø som tilbys (dev, test, stage, prod)
• Repositories på GitHub med rettigheter basert på team-definisjonen og med navn definert i filen over (eksempel-api, eksempel-frontend)
• Oppsett i ArgoCD. Hele beskrivelsen av oppsettet i ArgoCD for hver cloud-app er definert og automatisk satt opp i et eget repo som heter {navnet på cloud-appen}-argocd
• Oppsett i Terraform Cloud. Dette benyttes for å provisjonere infrastruktur som ikke direkte er knyttet til Kubernetes. Eksempler på slik infrastruktur kan være databaser, keyvault etc, litt avhengig av hvilke krav vi har til applikasjonen. For å provisjonere dette må vi skrive terraform-kode i repoet som har fått navn {navnet på cloud-appen}-infrastructure

Under vises eksempel på repoene som automatisk blir provisjonert opp for hver cloud-app man velger å opprette.

I løpet av minutter, og ved hjelp av lite kode, har man altså etablert et team med riktige tilganger. Repositories for å starte å kode, oppsett for å kunne rulle ut applikasjonen til Kubernetes og Azure subscriptions for videre å kunne provisjonere infrastruktur utover standard Kubernetes er opprettet og klart til bruk. Vi kan trygt si at vi er raskt up-to-SPEED med å starte utviklingen. Alt automatisert og dokumentert gjennom kode sjekket inn på GitHub, selvbetjent fra teamet som skal gjøre det, men samtidig sentralt satt opp og administrert av et lite cloud-team. Oppsettet skalerer godt og gjør at teamene selv i stor grad eier hva som settes opp for sin egen applikasjon. Cloud-teamet muliggjør altså at teamene kan jobbe effektivt under strukturerte forhold, uten å miste fart.

Tjenester i Azure

I tillegg til å kjøre applikasjoner i Kubernetes er det også lagt opp til at vi kan provisjonere andre tjenester i Azure. Her kan det være snakk om database, keyvault, service bus etc. Å sette opp disse tjenestene riktig og ikke minst sikkert for alle team og applikasjoner kan fort være en krevende oppgave. Et annet poeng er også at det ikke vil skalere godt om man ikke finner en måte å distribuere oppsettet ut til teamene.

Ved å lage moduler i Terraform kan cloud-teamet konfigurere oppsett av nettverk, private endepunkter, databaser, keyvault etc som er tilgjengelig for teamene. Det er enkelt å ta det i bruk og gjøres direkte i *-infrastructure — repoet til hver “cloud-application” . Det gir oss mulighet til å provisjonere opp infrastruktur i høy hastighet. I Terraform Cloud kan teammedlemmer logge inn og se på modulene som er definert av cloud-teamet samt lese dokumentasjon om hvordan man skal ta det i bruk. For eksempel hvis vi ønsker en database til en applikasjon så vil vi kunne benytte denne modulen;

Koden for å provisjonere opp en databaseserver i teamet i Terraform blir noe slikt:

module "example_postgresql_flexible_server" {
  source = "app.terraform.io/mollerdigital/postgresql-flexible-server/mollerdigital"
  version                           = "3.1.0"
  solution                          = "example"
  resource_group_name               = azurerm_resource_group.this.name
  location                          = azurerm_resource_group.this.location
  delegated_subnet_id               = data.azurerm_subnet.postgresql.id
  postgresql_sku_name               = "GP_Standard_D2ds_v4"
  postgresql_version                = "14"
  postgresql_storage_mb             = 32768
  postgresql_password_auth_enabled  = true
  postgresql_administrator_login    = "psqldbadmin"
  postgresql_administrator_password = random_password.psqldbadmin.result
  app                               = var.app
  env                               = var.env
  tags                              = local.tags
  zone                              = local.availability_zones[var.env]
  high_availability = {
    "enabled"                 = true,
    "mode"                    = "SameZone"
    standby_availability_zone = local.availability_zones[var.env]
  }
}

Teamet eier provisjoneringen av databaseserveren, databasen, monitorering og annet som følger med det å ha en database. Cloud-teamet på sin side er trygge på at provisjoneringen har skjedd helt etter det oppsettet som er ønskelig med tanke på sikkerhet og nettverk.

Monitorering

Ved siden av alt annet som blir automatisk satt opp som en del av det å lage en ny applikasjon, blir det også klargjort for monitorering og logging gjennom bruk av Datadog. Datadog er et ekstremt kraftig verktøy som hjelper oss å holde kontroll selv når ting går fort. Cloud-teamet sørger for at det er mulig å spore hvordan hver pod i Kubernetes har det til enhver tid mtp ytelse og ressursbruk. I tillegg er det også mulig å sette opp svært imponerende sporing av hva som skjer i applikasjonen gjennom Modern Application Performance Monitoring (APM). Det gjør at vi kan følge kall fra start til slutt i applikasjonen, gjennom ulike tjenestelag, databaser og nettverkskall.

Når vi opplever feil er det essensielt å raskt kunne bremse opp for finne ut hvor, hvorfor og kanskje hvordan feilen oppstod. Datadog tilbyr sporing som gir oss fullstendig oversikt over hva som skjer når det oppstår feil og presenterer det oversiktlig, brutt ned til hvert kall og hver tjeneste som benyttes i kallet.

Ved hjelp av en Terraform provider til Datadog konfigurerer applikasjonsteamene hvilke varslinger som Datadog automatisk sender til teamet dersom noe går galt i applikasjonen. For eksempel gjennom en melding til dedikert Slack-kanal.

Oppsett av slike varslinger er noe teamet selv legger i repoet som heter *infrastructure og dermed er dette også noe som er i versjonskontroll, eies av teamet og samtidig er standardisert mellom teamene.

SPEED tilbyr noen standardiserte varslinger som teamene kan benytte seg av. For eksempel kan vi abonnere på hendelser når Terraform kjøres. Dersom det feiler eller krever noe fra noen i teamet blir det varslet om dette i Slack-kanalen til teamet. Eksempelet under viser hvordan teamet tar i bruk en slik varsling;

module "speed-monitors" {
  source  = "app.terraform.io/mollerdigital/speed-monitors/mollerdigital"
  version = "0.2.1"
  app     = var.app
  env     = var.env
  team    = var.team
  terraform_cloud = {
    enabled       = true
    slack_channel = "#carsales-notifications"
    tags          = []
  }
}

Med repositories, Azure-tjenester, logging og monitorering er det meste tilrettelagt for at teamene skal kunne komme raskt i gang med å utvikle applikasjoner på en standardisert måte. Samtidig har hvert team enormt mye frihet til å velge hvordan de utvikler applikasjonen.

Kontinuerlig forbedring av plattformen

Vi har et veldig godt samarbeid med cloud-teamet. Funksjonaliteten og modulene som er bygget i Terraform har blitt til etter hvert som vi har identifisert behov i utviklingen av plattformen. Dette er smidig. Men å etablere en plattform av denne typen er ingen enkel oppgave, det koster både tid, penger og folk som vet hva de gjør. Plattformen er et digitalt produkt og krever kontinuerlig vedlikehold og forbedring. Nøkkelen er å klare å skalere plattformen til alle utviklingsteamene gjennom standardisering og selvbetjening uten å måtte skalere cloud-teamet. Det er viktig å få frem at det ikke tok 3 år før noen kunne ta i bruk plattformen. Det gikk relativt raskt å få opp noe å starte med, og cloud-teamet forbedrer og automatiserer fortløpende de delene av plattformen som blir mest brukt.

En slik plattform gjør at det er en standard for oppsett og konfigurasjon av applikasjoner i skyen. Det er med på å sikre en lik utvikleropplevelse på tvers av alle team. Vi oppnår økt effektivitet. Det går raskt å både opprette nye applikasjoner og å ta ned eksisterende applikasjoner, og ikke minst åpner det for innovasjon og kontinuerlig leveranser når motorveien til enhver tid er nyasfaltert og klar til bruk.

Alle medaljer har en bakside og det er nødvendig å gjøre vurderingen av når behovet er stort nok til å kunne forsvare både tids- og pengebruk på investeringen det er å etablere en slik plattform. Som det meste innenfor vår bransjen er svaret på dette: it depends.

Vi har hvertfall hatt stor suksess med vår plattform. Vi er strålende fornøyd og kan trygt si at vi har en fantastisk utvikleropplevelse på SPEED — og det har virkelig akselerert utviklingen vår.