- De fleste steder sier de at "Vi er ikke Netflix. Vi trenger ikke å gjøre det du leser om på blogger, det handler bare om selskaper som trenger massiv skalering", sier arkitekt Hans Løken i Boitano, nå utleid hos Ladeklar, til kode24.
- Men her skal vi tenke sånn. Og det er dritkult.
Løken har det tekniske ansvaret for å få det norske selskapet Ladeklar ut i verden, med nytt navn og potensielt noen nye nuller bak antall brukere.
Da gjelder det å satse på teknologi som skalerer.
Easee satser på AWS, åpner Oslo-kontor og trenger 150 nye folk
Én million parkeringsplasser
Ladeklar er et norsk selskap som lar borettslag og bedrifter bygge store ladeanlegg. De er mellomparten, som blant annet sørger for finansieringen, håndverkere til å faktisk gjøre jobben, videre drift av anlegget og tjenestene brukerne trenger for å faktisk få lada bilen sin.
Selskapet har holdt på i to år, med finansiering fra de store strømaktørene BKK og Hafslund, og de har gått fra å være et par utviklere til rundt 15 i dag.
Nå skal det nemlig satses i Europa; først og fremst Tyskland og Sverige, og navnet byttes fra Ladeklar til internasjonale Elaway.
«Jeg vil si at jeg er ganske imponert over Netlify foreløpig.»
- Vi har vært litt i MVP-modus. Vi skulle validere et behov, og det har vi gjort: Vi har tilrettelagt for ladepunkter for 30.000 parkeringsplasser, og gått fra 4,5 millioner i omsetning til 20 millioner kroner i år, sier produktutvikler Nikolai Toverud til kode24.
Målet nå er ladepunkter for én million parkeringsplasser, potensielt bli en del av smartgrid-systemer nedover i Europa og utvide
Fra Django til .NET
Deler av stacken til Ladeklar, eller Elaway, bærer preg av MVP-perioden selskapet har vært inne i. Og mye av jobben til Løken er å få stacken over til skalerbare plattformer de kan leve lenge med.
- Jeg har hørt rykter og sett spor av Django, Python og Kubernetes på backenden. Nå kjører vi i hovedsak i Azure med .NET, forteller Løken.
Alt du må vite om .NET 6: - Litt kronglete historikk
Frontenden går fra å være skrevet i kun JavaScript til å bruke React-rammeverket. Og der det i dag må dyttes ny kode til repoet om de vil oppdatere informasjonen på nettsidene sine, jobbes det nå med å få inn det norske CMS-et Sanity for å oppdatere innhold. Og alt kjøres ut gjennom GitHub og Netlify.
- Hvor skalerbart er Netlify?
- Jeg har ikke gravd meg så mye ned i det ennå, men jeg vil si at jeg er ganske imponert over Netlify foreløpig. Det sparer deg for mye devopsing på frontend, svarer Løken, som tror de beholder tjenesten også framover.
Distribuert system
- Min største bekymring for skalering er coupling, sier Løken.
- Om man for eksempel sier at "disse to tingene må oppdateres samtidig", også bindes de sammen i en eller annen SQL-database, som er berykta for å ikke skalere så bra.
«Min største bekymring for skalering er coupling.»
Løkens løsning er å bygge meldingsbaserte distribuerte systemer. Kort fortalt: Alt som skjer gjennom tjenesten baseres på meldinger, som hendelsen "lag ny bruker", som legger seg i en kø og løses asynkront. Det betyr blant annet at om én del av løsningen feiler, trenger ikke alt gå i stå.
Rent teknisk kan det for eksempel løses med Azure Service Bus, som Løken snuser på, og competing consumers-mønsteret, for spesielt interesserte.
Et slikt distribuert system løses gjerne med mikrotjenester, og arkitekten vil også bygge opp selve utviklingsavdelingen til Ladeklar/Elaway basert på dette tankegodset.
Autonome team
- Målet er å ha autonome team, hvor det ikke er en sjef som setter kravene, men de som faktisk bygger funksjonen og kjenner brukerne og vet hva som kreves. Optimalt fungerer feedbackloopen sånn at de som kan fikse problemet også er de som først får vite om det, forteller Løken, som er opptatt av domenedrevet design.
- Og i et meldingsbasert system er det viktigste hvordan man snakker sammen, ikke detaljene i hvert team. Så hvert team kan gjerne ha sin egen database, sine egne kommunikasjonsformer. Jeg tror på riktig verktøy til jobben.
Derfor valgte de Sanity, Next.js og Netlify
- Og er .NET riktig verktøy til jobben, når målet er skalering?
- Det var nok litt tilfeldig at .NET ble valgt før jeg kom inn, men man bør ha en god grunn til å komme med en helt ny stack. Og selv om det er klart at man kan skrive C#, som er språket vi hovedsak bruker i .NET, på måter som ikke er bra for skalering, lar alle språk og teknologier deg gjøre dumme ting, svarer Løken.
- Forutsetningene for å lage skalerbare ting er ikke noe dårligere med .NET enn andre ting. Det viktigste er dessuten ikke det tekniske i seg selv, men at du finner folk som kan det.