Når vi nå har gitt deg et innblikk i filosofien og drivkraften bak Snøkam, er det på tide å ta det første steget ned i de tekniske detaljene.

Selv om vi ofte omtaler “systemet” som én sammenhengende helhet, består det egentlig av en rekke mindre komponenter som fungerer i samspill med hverandre. Det meste av koden kjører «serverless» i skyen, nærmere bestemt på Azure Functions, noe som lar oss skalere på etterspørsel – og ikke minst holde driftskostnadene på et fornuftig nivå. En av de mange fordelene med en serverless-tilnærming er at vi i praksis ikke trenger å bekymre oss like mye for infrastruktur som tradisjonelle servermiljøer krever: Vi betaler kun for faktisk forbruk, og har ingen unødvendige servere stående på tomgang. Ulempen er at det koster litt oppstartstid når tjenestene spinnes opp, men det er ikke et stort problem for oss.

For å håndtere data på en robust og fleksibel måte, benytter vi oss av Sanity, som i bunn og grunn fungerer som databasen vår. Den samler og strukturerer informasjonen fra de ulike modulene våre, og lar oss enkelt trekke ut og oppdatere data når det trengs. I tillegg til at Sanity håndterer datalagring, har vi også lagt inn en rekke mekanismer for sikkerhet og autentisering. Her spiller Microsoft Entra (tidligere kjent som Azure AD) en sentral rolle for tilgangskontroll – både internt i systemet og for brukere som logger inn på ulike tjenester.

På klientsiden har vi valgt Next.js som hovedrammeverk for front-end, og vi hoster dette på Vercel. Grunnen til at vi landet på Next.js, er at det gir oss både god ytelse og fleksibilitet når vi skal utvikle nye moduler. I tillegg har Next.js et sterkt økosystem og støtte for server-side rendering, noe som også spiller fint på lag med microfrontends. Vi setter sammen ulike “små-apper” for å lage en samlet portal, slik at brukerne våre får én sammenhengende opplevelse – selv om applikasjonen under panseret egentlig består av mange frittstående deler. Tanken er at hver del av løsningen skal kunne utvikles, vedlikeholdes og oppdateres uavhengig av resten.

For kommunikasjonen mellom disse modulene har vi satset på en strategi med automatisk genererte klienter. Det vil si at når vi lager en ny backend, oppdaterer vi samtidig en liten bit kode som beskriver hva funksjonen gjør og hvilke data den trenger. Deretter blir alle klienter (for eksempel Next.js-frontenden eller andre interne prosesser) oppdatert automatisk med de nyeste modellene. Det gjør oss mer effektive i en mikroservice-arkitektur, i stedet for at vi må skrive kode manuelt for hvert kall eller for hver nye endring.

Et annet viktig bindeledd i Snøkam er Azure Service Bus, som sørger for at meldinger flyter sømløst mellom ulike prosesser. Tenk deg for eksempel at registrerte timer skal trigge en prosess i lønnssystemet, eller at en endring i «Min side»-tjenesten skal generere en notifikasjon i Slack. Azure Service Bus lar oss orkestrere slike hendelser uten at vi må lage tunge, tette koblinger mellom hver enkelt modul. Skulle en av modulene ha nedetid eller bli oppdatert, står ikke alt annet stille i mellomtiden – den aktuelle modulen kan bare hente sine meldinger når den er klar igjen, slik at ingen data går tapt.

Alt dette gjør at systemet vårt kan vokse organisk i takt med behovene til Snøkam. Når vi innfører en ny backend i Azure, kobler den bare på de modulene den trenger å snakke med. Og fordi vi tar i bruk microfrontends, kan vi introdusere nye funksjoner i webgrensesnittet uten at brukerne engang merker at det er snakk om en egen applikasjon under panseret. Det handler i bunn og grunn om å bygge videre på idéen vi nevnte i del 1: Helheten skal være sømløs, men bak kulissene er alt bygd opp av mange mindre systemer som lever i takt med hverandre.

En ulempe ved en slik arkitektur er den økte kompleksiteten og overheaden som følger med å koordinere flere uavhengige moduler. Selv om isolasjon gir utviklere frihet til å jobbe separat, innebærer det også at funksjonaliteten ofte må bygges og testes på tvers av flere systemer. Dette kan føre til lengre utviklingssykluser, ettersom integrasjon og kommunikasjon mellom modulene krever nøye planlegging og koordinering. Dessuten kan endringer i én modul utilsiktet påvirke andre deler av systemet.

Dersom du har sett på illustrasjonene av hele arkitekturen – håper vi nå at du har begynt å se mønsteret. Linjene er rett og slett koblinger mellom mikrotjenester, databaser og kjernefunksjoner, mens boksene viser hvert delsystem. Det er når alle disse snakker sammen på en ryddig måte, at vi får en helhetlig plattform som faktisk sparer oss for manuelle oppgaver og støy i hverdagen.

Gjennom de kommende episodene vil vi dykke dypere ned i hver enkelt av disse delene. Du vil få lære mer om hvordan “Min side” er bygd, hvordan vi håndterer lønnsberegning, hvordan Service Bus-oppkoblingene praktisk talt ser ut, og mye mer. Forhåpentligvis vil du også plukke opp noen ideer eller tekniske grep som du kan ta med deg inn i egne prosjekter. Målet med Krystallklart er jo nettopp å dele erfaringene våre – gode som mindre gode – slik at andre kan få innsikt i hvordan man kan bygge et selskap som nærmest “driver seg selv” på mange områder.

Et lite bilde som viser stemningen i Snøkam for øyeblikket 😁

Vi gleder oss til å fortsette ferden i de neste innleggene, der vi skal gå i dybden på flere konkrete funksjoner og tjenester. God lesing videre – og velkommen tilbake til neste del i Krystallklart-serien!