Denne uken snakker vi med Anders Liland, Software Engineer i Cloud Platform-teamet til Oda, om hvordan de drifter systemene.
Oda er Norges ledende dagligvarehandel på nett og Norges første enhjørningsbedrift. Rent praktisk har bedriften et lager på Lørenskog, og produkt- og teknologiteam som utvikler tjenestene i Nydalen i Oslo.
Liland forteller at de har fokus på å bygge interne verktøy i forbindelse med vekst. Blant annet mot Helsinki og Berlin. De har til og med sitt eget arbeidsrammeverk på tvers av organisasjonen, som de kaller Flow.
#2. Anders, hvor driftes det dere bygger i dag fra? 🕵️
Oda kjører i dag sine tjenester på en blanding av Google Cloud Platform og on-premise.
Vi er inne i en prosess nå hvor vi gradvis flytter tjenestene våre til skyen, og kun én litt kjeklete tjeneste gjenstår — den kontrollerer nemlig samlebånd og roboter, og er litt ekstra sårbar for latens og andre nettverksutfordringer.
Tjenestene våre kjører i containere som orkestreres av Google Kubernetes Engine. Ettersom Oda for det meste har standardisert på Python som backendspråk og PostgreSQL som database kan vi standardisere mye av hvordan vi utvikler, bygger og deployer tjenestene våre.
#3. Hvordan håndterer dere deploy til serverene? 📦
Cloud Platform-teamet sitt mål den neste perioden er å forbedre prosessene og verktøyene for kontinuerlig integrasjon og distribusjon.
Gjennom mange år med drift på on-prem-servere har deploy blitt gjort med et script kjørt lokalt på hver enkelt utvikler sin maskin. Gikk maskinen tom for strøm midt i en deploy så måtte en rulle tilbake for å prøve på nytt.
Slik takla Kolonial.no korona-trykket
I et mindre team fungerte dette overraskende greit veldig lenge. Med det store antallet utviklere vi har ansatt og det raskt økende antall tjenester vi lager fungerer ikke dette like godt, og det siste året har vi derfor prøvd oss frem med forskjellige verktøy og tilnærminger.
Vi gjorde et forsøk på GitOpsrammeverk med verktøyet ArgoCD. Dette valgte vi til slutt å fjerne ettersom det håndterte ulike miljøer dårlig (prod, staging, dev) og gav utviklere lite innsikt i hva som faktisk skjedde. For eksempel var det vanskelig å enkelt se når og hvorfor en databasemigrasjon feilet.
#4. Hva bruker dere til å holde oversikt over drift? 🪟
Vi bruker Datadog som hovedverktøy for observerbarhet, hvor vi aggregerer alle logger, traces og metrics.
Dette gir utviklere mulighet til å feilsøke og å sette opp alarmer.
Vi setter opp alarmer for for ressursbruk, endepunktstesting, anomali i trafikkmønstre, og så videre. Hvis en alarm trigges så varsles en Slack-kanal til teamet som eier tjenesten.
Er det en alvorlig feil utenfor arbeidstid ringes vakttelefonen automatisk.
Til on-call-rotasjoner, vakttelefon og incidents bruker vi Pagerduty. Hver avdeling har sin egen vaktordning, som bidrar til en god kultur der teamene som utvikler tjenestene eier sine egne tjenester og føler det på kroppen når det går galt. Dette gir en god feedback-mekanisme som lar oss konvergere mot mer stabile systemer over tid.
#5. Hvordan håndterer dere caching? 💾
Vi har egne Redis-instanser for de tjenestene våre som trenger caching. Dette gjelder typisk nettbutikken og deler av de interne systemene vi har på lageret og i distribusjonen.
#6. Hva bruker dere til domener/DNS? 🏡
Vi bruker Google Cloud Platform sin Cloud DNS tjeneste for nesten alle våre domener, som lar oss enkelt definere DNSsertifikatene som kode.
Vi har satt opp noen interne sertifikater med wildcard-subdomener som vi kan kjøre interne tjenester på.
I kombinasjon med cert-manager i Kubernetes-klustrene trenger utviklerene bare å legge til 2 linjer i ingressen for å få et gyldig domene med et automatisk generert TLS sertifikat.
#7. Hva bruker du mest tid på i hverdagen i forhold til drift? 🌞
I forbindelse med flytteoperasjonen til skyen går mye tid med til å definere eierskap og sette riktige tilganger.
I skyen er det mye enklere for utviklere å ta i bruk nye ressurser, og da er det enda viktigere enn før at de har et forhold til eierskap, kostnader og driftsrutiner for tjenestene sine.
«Vi følger prinsippet om “minste tilgang”.»
Vi følger også prinsippet om “minste tilgang”, som betyr at ingen skal ha tilgang til mer enn akkurat det de trenger. Dette øker sikkerheten betydelig og hjelper utviklere fra å gjøre unødvendige feil, som å slette ressurser de ikke eier.
Mye tid går også til feilsøking av nye problemer som oppstår ved å gå over til å kjøre tjenester som kortlevde containere i stedet for virtuelle maskiner som lever evig. Den ene nginx-serveren som vi nylig tok ned hadde for eksempel en sammenhengende kjøretid på 1514 dager, altså litt over 4 år.
#8. Hva er du mest fornøyd med å ha gjennomført i forbindelse med drift det siste året? 🤟
Vi har laget et internt verktøy ved navn Jaleo for å automatisk kunne lage monitorer hos flere ulike tjenester, med gode standardverdier som vi enkelt kan putte på alle våre applikasjoner.
Dette gir oss tidlig varsel om noen av tjenestene ikke oppfører seg som de skal. Typisk kan dette være containere som bruker for mye CPU eller minne, endepunkter som ikke svarer, eller unormale trafikkmønstre.
Med Jaleo slipper hver enkelt tjeneste å sette opp alarmer selv — som reduserer tidsbruk og ikke minst muligheter for feil. Denne typen automasjon prøver vi å få til i alle deler av driften, hvor vi vil tilrettelegge for at utviklerne skal falle i “The Pit of Success”. Det blir litt som å ha gjerder på bowlingbanen: som utvikler skal du uansett slå ned noen pinner og ha stor sannsynlighet for strike, selv på første kastet.
«Det er ekstremt viktig at vi har gode tester og integrasjonsmiljøer.»
#9. Er det noe som skiller deres driftebehov fra andres? 🥕
Vi er for øyeblikket en relativt liten organisasjon med store vekstplaner. En stor utfordring de neste årene blir å klare å skalere våre interne verktøy slik at produktiviteten til våre utviklere ikke stagnerer.
Utviklerteamene må i større grad ta ansvar for drift og stabilitet i sine egne tjenester, støttet opp av et sentralt cloud platform-team som utvikler verktøy og rutiner. Vi er i det hele tatt sårbare for nedetid på lageret vårt.
Hvis maskiner og utstyr som trengs for å plukke varer slutter å fungere vil hele lageret raskt stoppe opp. Det er derfor ekstremt viktig at vi har gode tester og integrasjonsmiljøer som oppdager feil tidlig.
Slik bygger norske utviklere API-er
Dette blir naturligvis ekstra viktig når antall lagre mangedobles gjennom de neste årene. Dermed er vi avhengige av deployment-verktøy som enkelt, raskt og automatisk ruller tilbake feil som stopper varehuset.
Hybridinfrastrukturen med en skyplattform og et solid fysisk fotavtrykk byr også på mange interessante utfordringer, særlig knyttet til hvordan vi knytter de to sammen. Siden vi tror vi vil måtte endre oss fort også de kommende årene har vi for eksempel besluttet å drifte også de fysiske nettverkene selv.
#10. Hva har du lyst til å teste/bytte ut fremover, og hvorfor? 🚄
Vi holder på å teste ut Pulumi og CDKTF for infrastruktur-som-kode.
Begge to støtter tradisjonelle programmeringsspråk som Python, som gir oss muligheten til å bruke mer avansert logikk og å unngå mye repetisjon i koden.
Ettersom Oda har standardisert på Python internt gjør det også infrastruktur og Kubernetes-manifester mer tilgjengelige og forståelige for utviklerne, siden de slipper å lære egne domene-spesifikke språk for dette.
Med den store veksten i antall utviklere vi står overfor ser vi oss også nødt til å lage en utviklerplatform. Dette skal være første møtepunkt for utviklerne, hvor de skal finne all informasjon om tjenestene, logging, distribusjon og dokumentasjon. Vi vil også lage såkalte Golden Paths - stjålet fra våre naboer i Spotify - som helt enkelt er et sett med oppskrifter på hvordan vi anbefaler at ting bør gjøres.
Skal et team for eksempel lage en ny webapplikasjon kan de enkelt følge en Golden Path og veldig enkelt få standardiserte nettverk, DNS, tester, monitorering, Kubernetesmanifester og GCP-ressurser automatisk opprettet, slik at de selv kan fokusere på produktet sitt.
#11. Hva skulle du ønske utviklere og kolleger ble flinkere på? 💡
Dokumentasjon!
