Vet du hvilken by som har sin egen digitaliserings-etat? Jo, det er Oslo det!
I 2020 ble de etablert, og har over 110 ansatte som bygger digitale innbyggerløsninger for fremtiden. Oslo er ingen liten kommune, og det kan neppe være en enkel jobb å drifte et system av tjenester Oslobeboere er avhengig av.
Derfor tok vi en prat med Gitanjali Sachdeva (32), Tech Lead i Proaktive Meldinger-teamet, som har ansvar for alle viktige meldinger som sendes til innbyggerne. For eksempel når du flytter til kommunen og trenger oversikt over viktige tjenester.
#1. Gitanjali, hvor driftes det dere bygger i dag fra? 🕵️
Foreløpig kjører Origo sine tjenester på en blanding av Amazon Web Services (AWS) og on-premise.
Vi holder på med å flytte tjenestene våre fra on-premise til skyen og er veldig opptatt av å gjøre grundige risiko- og sårbarhetsanalyser (ROS).
Vi jobber mye med innbyggernes behov, og håndtering av personopplysninger som kan være sensitive mtp. Schrems II og GDPR.
Slik leverer Sanity 3 milliarder spørringer i måneden
De fleste tjenesteområder i Origo bruker Amazon Elastic Kubernetes Service (Amazon EKS) for å hoste applikasjoner. Origo har et eget kjøremiljø team som har laget okctl (Oslo Kommune Control) som gir enhver tjenesteområde mulighet til å bygge sitt eget fullverdige produksjonsmiljø i skyen. Vi i Proaktive meldinger utvikler tjenester med Serverless rammeverket som kjøres i AWS Lambda. Vi har også en del infrastruktur som lages med terraform.
#2. Hvordan håndterer dere deploy til serverene? 📦
Det er veldig viktig å ha fokus på kontinuerlig integrasjon og leveranse.
I Origo prøver vi å tenke ‘minimum viable product’ (MVP) når vi utvikler nye tjenester. Koden som ikke er i produksjon gir null verdi.
Vi bruker Github Actions (GA) for å deploye alle applikasjonene våre til AWS. GA gir oss stor fleksibilitet til å konfigurere deployment workflows, samtidig som det er relativt enkelt å sette opp og komme i gang med.
Tidligere har vi brukt Argo CD og Helm for applikasjonene som kjørte på Amazon EKS. Det var før vi valgte å gå for en helt serverless-plattform.
#3. Hva bruker dere til å holde oversikt over drift? 🪟
Vi bruker Amazon CloudWatch for å monitorere logger og metrikker for alle applikasjonene våre, samt endepunkter.
Vi har et CloudWatch dashboard per serverless applikasjon/prosjekt som viser metrikker og alarmer tilknyttet den applikasjonen.
Slik drifter de Oda (tidligere Kolonial.no)
Det er satt opp alarmer for ressursbruk, helsesjekk, anomali i trafikkmønstre, og så videre. Alle våre alarmer er knyttet til ett felles Amazon Simple Notification Service (SNS) topic.
#4. Hvordan håndteres caching? 💾
For våre Front-end applikasjoner bruker vi CloudFront sin innebygde caching mekanisme. Dette er ganske standard når man bruker CloudFront.
Når det gjelder våre API Gateways så bruker ikke vi noe caching. Dette fordi de fleste applikasjonene skal treffe en lambda i bakgrunnen.
Det samme gjelder flere av våre åpne endepunkter. Vi kunne kanskje implementert caching på noen tjenester hvor vi ikke er avhengige av å treffe noe lambda (eller noe annet bak API Gateway-ene), men disse API endepunktene er beskyttet bak autentisering og har så lite trafikk at vi ikke ser det som nødvendig foreløpig.
#5. Hva bruker dere til domener/DNS? 🏡
Vi har satt opp flere hosted-zones i AWS ved hjelp av terraform, og deretter har vi satt opp domenet vårt til å peke på nameserveren for vår hosted-zone. Dette gjør at vi da har full kontroll over dette domenet og alle sub-domener.
For å sette opp nye subdomener må disse legges inn i Route53 slik at subdomenet peker på tjenesten vi ønsker. Noen er satt opp ved hjelp av AWS CloudFormation. Domene til API Gateway-ene i AWS blir satt opp ved å bruke serverless-domain-manager plugin for å lage en Route53 record og CloudFront(-lite) til API Gateway-en.
Slik hostes Dagbladet.no
#6. Hva bruker du mest tid på i hverdagen i forhold til drift? 🌞
Vi har automatisert det meste av driftsoppgaver. Infrastructure as Code (IaC) hjelper oss å spare masse tid med forvaltning av infrastruktur i skyen.
Alarmer og overvåking bidrar til tidsbesparelser på feilsøking og korrigering. Av og til kommer det noen falske alarmer som vi må undersøke (for eksempel når en bot prøver å finne svakheter i systemet ved å nå endepunkter som ikke finnes).
I tillegg bruker vi en del tid på å skrive dokumentasjon om tekniske løsninger vi lager og de valgene som tas underveis. Vi legger stor vekt på kompetansedeling som betyr at dokumentasjon er en viktig del av alt vi jobber med.
#7. Hva er du mest fornøyd med å ha gjennomført i forbindelse med drift det siste året? 🤟
I løpet av det siste året har vi bygget plattformen i skyen og flyttet tjenester fra on-premise til AWS. Vi har erstattet store monolittiske applikasjoner hostet på on-premise med små lambda-funksjoner som har gjort hele prosessen smidigere.
I forbindelse med migrering til skyen har vi skapt gode utviklingsprosesser og rutiner for overvåkning av alle våre applikasjoner i skyen. Dette har ført til økt tillit til våre tjenester, og vi kan stole på at de oppfører seg som forventet.
Slik hoster de VG.no
#8. Er det noe som skiller deres driftebehov fra andres? 🥕
Proaktive meldinger plattform (som består av flere små applikasjoner) har ekstremt variabel last som skiller den fra applikasjoner som må være oppe hele tiden.
Applikasjonene våre brukes bare når en melding (i form av sms eller e-post) skal sendes til innbyggere.
Applikasjonene våre ligger ledig ca. 98% av tiden, noe som gjør at det blir ulønnsomt å ha store Amazon EC2 noder for å ta unna lasten når den kommer. Vi er avhengige av rask skalering når vi skal sende meldinger. Derfor har vi valgt lambda-funksjoner som kjøres ved behov.
#9. Hva har du lyst til å teste/bytte ut fremover, og hvorfor? 🚄
For tiden fokuserer vi på migrering av alt fra on-premise til skyen, da dette vil gjøre plattformen vår mindre kompleks. Det skal bidra til en mindre teknologistack som er lettere å vedlikeholde og oppdatere.
I overgangsfasen prøver vi å gjøre ting på best mulig måte. Det vi savner er automatiserte integrasjonstester for lambda-funksjoner (som ligger bak autentisering) i AWS. I dag har vi automatiserte unit tester og en god del manuell testing. Vi vurderer behov for et testmiljø hvor vi kan kjøre slike automatiserte tester som tester hele plattformen oftere.
I tillegg har vi mye fokus på å bytte ut arbeidsverktøy som ikke er effektive nok. Noen av dem står bak VPN som gjør det vanskelig.
#10. Hva skulle du ønske utviklere og kolleger ble flinkere på? 💡
Bli enda bedre på kvalitetssikring av tekniske løsninger vi lager.
Utviklere kan også bli flinkere til å oppdatere dokumentasjon med en gang man har gjort noen vesentlige kodeendringer.
