Krystallklart ❄️

Morten Kartevoll

Bak de fleste effektive systemer ligger det et lag av automatisering, og det gjelder også våre interne løsninger i Snøkam. Ett av disse systemene er en løsning for å automatisere innhenting og visualisering av OKR-metrikker.

Men hva er egentlig OKR og hvorfor bruker vi det? OKR (Objectives and Key Results) er et rammeverk for mål- og resultatstyring som hjelper organisasjoner med å sette ambisiøse mål og måle fremdrift gjennom tydelige nøkkelresultater. Metoden skaper fokus, transparens og smidighet, men for å lykkes kreves oppdatert og pålitelig data. Nøkkelordet her er 

da vi raskt så at det tok unødvendig lang tid å oppdatere alle Key Resultene våre manuelt.

For en integrasjonsutvikler kan dette fremstå som en drøm om sømløs datainflytelse, eller et mareritt fylt med fragmenterte API-er, kompleks autentisering og unødvendig webscraping, og ikke minst elendig dokumentasjon. I denne artikkelen ser vi på hvordan automatisering av datainnhenting kan forenkle arbeidet med OKR-er. Men lønner det seg alltid å automatisere slike prosesser? 

Resultatet av vår automatisering kan du se her: 

Dette vil såklart variere utrolig mye etter hvilke system selskapet du jobber i bruker, men vi har ihvertfall over tid koblet oss mot et bredt spekter av systemer:

 - Hvor alle oppgaver gjør har er lagret

Valget av integrasjon styres i stor grad av hvilke Key Results vi måler. Når vi kan gjenbruke eksisterende dataflyt utnytter vi det! For eksempel gjennom NuGet-pakker vi allerede har utviklet, som Sanity-pakken vår. Dette gir oss betydelige tidsbesparelser og reduserer samtidig risikoen for teknisk gjeld. Over tid forventer vi også at antall systemer vi henter data fra vil stabilisere seg, med andre ord vil forhåpentligvis mengde jobb med tanke på selve integrasjonen mot nye systemer konvergere mot et stabilt tall.

En av de viktigste erfaringene våre er hvor varierende API-kvalitet kan være.

: PowerOffice, Salesforce og Jira – veldokumenterte, konsistente, og fleksible API-er som gjør integrasjon og feilhåndtering relativt rett frem.

: Medium og LinkedIn – komplekse tilgangskontroller, fragmentert dokumentasjon og hyppige endringer.

Det var faktisk API-frustrasjonen med Medium som gjorde at vi valgte å bygge vår egen bloggløsning. Da fikk vi også full kontroll på dataflyt, autentisering og struktur. Når du har utviklere som møter opp på mandag og sier «jeg bygde en bloggløsning i helga», blir det lett å kaste dårlige API-er langt, langt bort.

For enklere behov gikk vi like gjerne for 

 en pragmatisk løsning når API-ene bremser mer enn de hjelper.

Fra API-rant til litt mer konkret om OKR oppsettet vårt. Hvilke deler av vårt internsystem innebærer løsningen? I de forrige episodene har vi sett mer på veldig sentrale deler av systemet, mens dette er en mer konkret implementasjon. Under ser du hvilke deler av systemet som blir involvert, pluss det kommer en mer konkret tegning litt senere.

For hver Key Result beregnes status kontinuerlig opp mot mål definert i januar.

Hver oppdatering lagres som et historisk datapunkt, slik at vi kan visualisere progresjon gjennom året.

Persistens skjer i Sanity, via en custom NuGet-klient som gjenbrukes på tvers av prosjekter.

Under er databaseskjemaet vårt representert, hvor en kan se Objectiven som har flere Key Results som inneholder flere data points.

Forklaring/dypere beskrivelse av selve Objectiven

Forklaring/dypere beskrivelse av Key Resulten

 om eksisterende pakker ikke finnes som støtter hva vi gjør

 på toppen av Sanity, slik at hele organisasjonen får innsikt i sanntid (så ofte vi setter frekvensen på CRON jobben). Dette er også tilgjengelig på vår nettside!

Eliminering av manuelt arbeid! Systemet gjør jobben mens vi fokuserer på verdiskaping. Innhenting av data + kalkulering kan ta lengre tid enn en tror.

Gjenbrukbare integrasjoner via NuGet-pakker (kan brukes andre plasser også)

Skalerbart: flere datapunkter kan hentes uten ekstra manuelt overhead.

Som alle andre automatiseringer er det ingenting som er digger enn å slippe å gjøre manuell jobb, men heller bare se automatikken gjøre sin magi

Det er dessverre ikke alt som lar seg automatisere, eller som det ikke er verdt det, spesielt når vi ikke helt vet hvordan vi skal løse en KR. 

Høy initial investeringskostnad, spesielt i oppstartsåret.

Nye OKR-er hvert år innebærer omskriving og tilpasning av integrasjoner.

Ikke alt kan eller bør automatiseres. Nøkkelfaktorene er:

: Har vi pålitelige kilder, eller må vi gjette?

: Måler vi ukentlig, eller kun 2–3 ganger i året?

: Er metrikken klart definert (f.eks. «inntekter per måned») eller vag?

Der faktorer er uklare, er det bedre å vente. Automatisering gir bare verdi hvis datakvalitet og kontekst er på plass. Konkrete eksempler fra våre egne KR-er er:

Trivsel skal måles 3 ganger i året og vi skal følge opp (og jobbe for forbedring) 100 % av innspillene/ulempene som kommer inn

Denne kunne i teorien ganske enkelt blitt målt, men når det bare er snakk om 2-5 målinger er det ikke verdt å automatisere. Når det er sagt er nok en slik trivselsundersøkelse noe vi kommer til å fortsette med i årene fremover så det kunne potensielt gått inn som en annen automatikk. But I digress!

Minst 1000 unike brukere i et nytt Snøkam AI-produkt

Dette er også et eksempel på at vi ikke vet hvor dataen skal komme fra. Hadde vi lansert et spill for eksempel kunne vi hentet dette fra plassen vi lanserte det til, men siden det er litt uvisst, ble denne avventet. Mest sannsynlig kan det hentes fra Google Analytics om vi lanserer det direkte på nettsiden vår, og da er det bra at vi allerede har en kobling mot det API-et slik at vi eventuelt kan få raskt opp dataen om vi skulle ønske det.

For selskaper kan gevinsten i starten være relativt liten sammenlignet med manuelt arbeid (15-30 minutter i uka). Men om OKR-ene blir mer komplekse, frekvensen trenger å være hyppigere, eller det rett og slett tar for lang tid å hente + kalkulere resultatene. øker gevinsten av automatiseringen utrolig mye.

Et datagrunnlag som enkelt kan eksponeres eksternt og internt.

Mulighet til å bruke integrasjoner i andre sammenhenger.


Har du ikke automatisert OKR-ene dine ennå, er det på tide å sette i gang. Det er både lærerikt og gøy. Du får jobbe med mange forskjellige API-er, du oppdager hvor variert "best practice" faktisk er i integrasjonsverdenen, og du bygger en plattform som skalerer med selskapet.

Automatisering handler ikke bare om å spare tid, men om å bygge en datadrevet kultur der innsikt er tilgjengelig, presis og kontinuerlig oppdatert. Det er det som gjør at små beslutninger kan tas raskt, og store beslutninger kan tas på riktig grunnlag.

Bak de fleste effektive systemer ligger det et lag av automatisering, og det gjelder også våre interne løsninger i Snøkam. Ett av disse systemene er en løsning for å automatisere innhenting og visualisering av OKR-metrikker.  For en integrasjonsutvikler kan dette fremstå som en drøm om sømløs datainflytelse, eller et mareritt fylt med fragmenterte API-er, kompleks autentisering og unødvendig webscraping, og ikke minst elendig dokumentasjon. Men lønner det seg alltid å automatisere slike prosesser?

Hjertet av internsystemet, Min side, er proppet fullt med masse forskjellige funksjonaliteter som arrangementer, webshop, lønn, aksjer, goder, økonomi, forsikringsdokumenter, info om ansatte osv, osv. Det vil si, funksjonalitetene eksisterer i sine representative microservice-apper, men Min side knytter disse sammen til et felles sted. Dette er en relativt vanlig arkitektur for større systemer da det tillater appene å kjøre for seg selv også utenfor koblingen til Min side. På denne måten kan vi utnytte det beste av to verdener - samle all funksjonalitet til Snøkam-ansatte på ett sted, samtidig som vi kan eksponere de appene vi ønsker også til personer utenfor Snøkam. Fra venstremenyen i skjermbildet så kan vi se at Min side router til veldig mange ressurser - både interne, men også eksterne. Vi skal titte innom noen av de i denne bloggposten, men mange av de er såpass innholdsrike og spennende at vi skal dedikere helt egne poster til dem.


Episode 2: Min side

C# er et programmeringsspråk utviklet av Microsoft, og brukes til å bygge alt fra små applikasjoner til store og komplekse systemer. Det kombinerer kraften fra tradisjonelle språk med moderne funksjoner som gjør koden ryddig, trygg og enkel å vedlikeholde.
Hos Snøkam bruker vi C# sammen med .NET-plattformen for å lage stabile og sikre løsninger som tåler vekst og endringer over tid. Språket gir oss høy ytelse, god struktur og mange verktøy som gjør utviklingen både effektiv og pålitelig.
Vi velger C# når vi ønsker å bygge robuste løsninger for bedrifter som trenger kvalitet, sikkerhet og langsiktig verdi i sine digitale systemer.

Backend

Azure er Microsoft sin skyplattform, som lar oss bygge, lagre og drifte digitale løsninger uten behov for egne servere. Plattformen gir tilgang til et stort økosystem av tjenester – alt fra databaser, maskinlæring og sikkerhet til automatisering og analyse.
Hos Snøkam bruker vi Azure for å bygge fleksible, trygge og skalerbare løsninger som kan vokse i takt med kundens behov. Skyplattformen gjør det enkelt å kombinere ulike teknologier, automatisere oppgaver og levere stabile systemer med høy ytelse.
Fordi Azure er tett integrert med verktøy mange allerede bruker fra Microsoft, som .NET og Office 365, kan vi utvikle helhetlige løsninger som fungerer sømløst på tvers av både utvikling, drift og brukeropplevelse.

Cloud

Azure

Episode 3: OKR automatisering

Morten Jansrud

, vår helt nye bloggserie der vi åpner opp for hvordan Snøkam drives fra innsiden. Hos oss er teknologien selve grunnmuren i selskapet, og mesteparten av manuelt arbeid er automatisert – faktisk i den grad at vi ikke trenger noen fast ansatte som jobber med interne prosesser på fulltid.

Nå lanserer vi bloggserien Krystallklart, hvor vi for første gang åpner dørene og viser frem hvordan dette teknologiske maskineriet faktisk fungerer. I stedet for en overfladisk “se hva vi kan gjøre”-tilnærming, vil vi i hver artikkel ta deg med bak kulissene og forklare hvorfor systemene er bygget slik de er, hvilke utfordringer som ble løst underveis, og hvilke teknologiske valg som har formet helheten. Håpet er at du, etter å ha fulgt serien, sitter igjen med et detaljert innblikk i hvordan Snøkam kan drives med et minimum av repeterende arbeid – og samtidig levere maksimalt for ansatte.

For å forstå den fulle bredden av alt som foregår, er det greit å vite hva som faktisk ligger i bunn. Snøkam-systemet består av en rekke ulike løsninger – fra arrangementer og blogg, til mer avanserte funksjoner som lønnsberegning og automatisering av OKR-er. 

Her er et bilde av vår innovative lønnsutbetaling i Bitcoin. Om du ikke har fått det med deg: 

I den første artikkelen vil du få en svært overordnet introduksjon til systemet, hva det består av, hvordan komponentene henger sammen, og hvilken grunnleggende teknologi som gjør det mulig.

Vi tror at åpenhet og deling av kunnskap er sunt, både for oss selv og for alle som er interessert i å bygge eller forbedre egne systemer. Kanskje vil du hente inspirasjon til hvordan du selv kan automatisere din bedrifts interne rutiner, eller kanskje du bare er nysgjerrig på hvordan det er mulig å drive et relativt omfattende selskap med minimal manuell oppfølging. Uansett gleder vi oss til å dele reisen, utfordringene og det som har fungert bra, og vi er sikre på at du vil komme tettere på hvordan Snøkam virkelig fungerer i kulissene – helt 

Velkommen til Krystallklart, vår helt nye bloggserie der vi åpner opp for hvordan Snøkam drives fra innsiden. Hos oss er teknologien selve grunnmuren, og mesteparten av prosessene er automatisert – faktisk i den grad at vi ikke trenger noen fast ansatte som jobber med interne systemer på fulltid. Hensikten med denne serien er å vise hvordan vi har klart å bygge opp et helhetlig økosystem av verktøy, integrasjoner og arbeidsflyter som løser hverdagslige utfordringer mer effektivt og innovativt.

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. 

Episode 1: Under panseret – en overordnet titt på Snøkams tekniske landskap

TypeScript er et programmeringsspråk som bygger videre på JavaScript – språket som brukes til å lage det meste av det du ser og klikker på i en nettleser. Forskjellen er at TypeScript hjelper utviklere med å skrive mer strukturert og pålitelig kode, ved å fange opp feil før de skjer.
Vi bruker TypeScript fordi det gjør det enklere å bygge stabile løsninger som er lette å vedlikeholde og utvikle videre over tid.

Frontend

Typescript

React er et verktøy vi bruker for å bygge moderne nettsider som føles raske og levende. Det hjelper oss å sette sammen små deler av et design til hele løsninger – litt som byggeklosser.
Vi bruker React fordi det gjør det enklere å lage brukervennlige og fleksible nettsider som er lette å videreutvikle når behovene endrer seg.

React

Krystallklart: Et innblikk i teknologien som driver Snøkam

Arvid Mildner

Den bästa förklaringen får man nog om man läser direkt från den 

 men jag ska försöka ge min egna kortfattade version.
MCP-protokollet är ett standardiserat sätt för en MCP-kompatibel AI Agent (till exempel chatten i Cursor eller Claude) att hämta in extra kontext från en extern server, istället för att gissa sig fram baserat på vad den har lärt sig under träningen av modellen.

Rent konkret ger du då LLM-agenten en möjlighet att ställa flera frågor på egen hand till det här externa systemet, utan att behöva involvera dig. För att kunna erbjuda den här informationen måste du implementera en MCP server, som alltså implementerar det här protokollet. Några MCP servrar stödjer bara "läsning", medans andra faktiskt också stödjer skrivning och alltså kan göra saker som att lägga till ny information i en databas, skicka iväg ett meddelande på Slack eller vad som helst egentligen. 

Idag ska vi bara fokusera på MCP servrar som bara stödjer läsning (read-only).


När gör MCP servern mer skada än nytta?

Ett vanligt misstag när du först börjar använda MCP servrar är att du bara sätter igång allihopa. Beroende på vilken MCP server du använder, kan du plötsligt ha fyllt upp stora delar av kontext-fönstret med massa information om verktyg med mera som bara stjäl av den dyrbara men begränsade kontexten som agenten har tillgänglig. Resultatet blir då tvärt emot det du försökte, då din agent skulle bli bättre men faktiskt blev sämre.

 har det här problemet är den som Hashicorp har 

 för terraforms dokumentation. Den har andra funktioner, men jag är mest intresserad av hur de har klarat å packa in all dokumentation om alla möjliga resurser utan att fullständigt spränga min agents kontext. Detta var extra intressant då jag själv har tänkt lite på hur man kan tillgängliggjöra dokumentation på ett effektivt sätt. En naiv tillnärmning hade varit att bara dumpa absolut all information i en väldigt tråkig men LLM-kompatibel markdown sida, lite som vi gjort på 

standarden). Detta gör dock att vi snabbt hamnar i den fallgruvan där vi bara fyller hela agentens kontekst med onödig information som inte är precis det den behöver. Men Hashicorp har gjort något smartare, och det är det vi ska se lite närmare på i den här bloggposten.

För att kunna inspektera en MCP server, så är det smart att använda 

. Det här verktyget ger dig ett GUI som gör det lätt att se hur en MCP server presenterar sig för en potentiell klient. Du kan starta programmet såhär:

När den kör, kan vi också skriva in kommandona som ska till för att koppla sig till terraforms MCP server:



Nu ser vi alltså vad en LLM-agent ser när den kopplar sig till.

Så vad är det som gör terraforms MCP server så effektiv?

Först och främst så ser vi att den exponerar ett "verktyg" eller "tool" som heter 


Om vi ser lite närmare på verktygets beskrivelse, så kan vi läsa

This tool retrieves a list of potential documents based on the 'service_slug' and 'provider_document_type' provided.You MUST call this function before 'get_provider_details' to obtain a valid tfprovider-compatible 'provider_doc_id'.Use the most relevant single word as the search query for 'service_slug', if unsure about the 'service_slug', use the 'provider_name' for its value.When selecting the best match, consider the following: - Title similarity to the query - Category relevanceReturn the selected 'provider_doc_id' and explain your choice.If there are multiple good matches, mention this but proceed with the most relevant one.

Okej, så LLM-agenten förstår nog att det här verktyget ska anropas först. Den har också några parametrar:

 som någon sorts fuzzy-search term som kan användas. Så ett typiskt anrop till den här hade då blivit:

Om vi nu, i MCP Inspector, kör det här verktyget så kan vi förvänta oss något sorts svar. När jag gjorde det, så får vi tillbaka dethär:


Så vi kan se att söket returnerade lite intressant information som LLMn kan använda på nästa fråga, när den då kanske förstår att den skal använda 

, som i sin tur har den här beskrivningen

Nu borde det vara uppenbart för LLM-agenten att den kan anropa det här verktyget i nästa steg, med "providerDocsIDs" som den fick i första anropet i 

 steget. Låt oss anropa det verktyget med 

Nice! Så LLM-agenten fick nu den fullständiga, väldigt precisa dokumentationen som beskriver hur den skall konfigurera ett Azure Storage Account i terraform, precis samma information som vi hittar 

, i den officiella dokumentation för terraform providers/resurser.

Vi kan alltså se exakt hur det här fungerar. Just den här MCP servern är implementerad efter ett  

 mönster. Samtidigt är varje "entitet" i hashicorps dokumentation associerad med ett visst ID. LLM-agenten kan då snabbt kasta bort irrelevant information genom att söka med fuzzy-search, och sen utifrån den konteksten den har från kodbasen du faktiskt jobba i förstå vilken av de returnerade resurserna den skall fortsätta fråga efter. Genom att använda det här mönstret så borde man kunna effektivisera egen dokumentation också.

Om du har någon intern eller extern dokumentation som kan vara användbar för någon utvecklare som använder till exempel Cursor när den skall integrera mot ditt system, så kan detta absolut vara något att investera lite tid i.

Det var allt för den här gången! Om du har några tankar om det här eller har gjort något liknande, tveka inte att höra av dig på hei@snokam.no för att dela tips eller tricks.



Det här är ett djupdyk i implementationsdetaljerna av Hashicorps MCP server och varför den fungerar så bra när man använder den för att skriva terraformkod

Terraform er et verktøy vi bruker for å bygge og styre IT-infrastruktur i skyen på en trygg og effektiv måte. I stedet for å sette opp alt manuelt, beskriver vi infrastrukturen som kode – litt som en oppskrift som forteller hva som skal lages.
Vi bruker Terraform fordi det gjør det enklere å holde oversikt, unngå feil og gjenskape oppsett på tvers av prosjekter og miljøer.

Terraform

(Large Language Model) er en type kunstig intelligens som kan forstå, generere og jobbe med tekst på en måte som ligner på hvordan mennesker skriver og snakker. Den brukes til alt fra chatboter og automatiserte tekstanalyser til å hjelpe utviklere med å skrive kode.
Hos Snøkam bruker vi LLM-er for å utforske hvordan AI kan gjøre arbeidet vårt smartere og mer effektivt – enten det handler om å automatisere oppgaver, hente ut innsikt fra store mengder informasjon eller bygge helt nye løsninger drevet av språkforståelse.
Store språkmodeller er i rask utvikling og gir oss muligheten til å kombinere teknisk presisjon med kreativitet – slik at vi kan levere mer intuitive og fremtidsrettede digitale tjenester.

Kunstig Intelligens

Hur man skapar en bra MCP server för dokumentationssidor

Håkon Grøtte

Kotlin

Java

Spring Boot

Docker

Kubernetes

Elasticsearch

GraphQL

Anine Harto

Python

Data Plattform

Spark

Databricks

Deltalake

Golang

Elisabeth Karud

Kristoffer Finckenhagen

.NET

Next.js

Splunk

Sikkerhet

Marianne Melhoos

Angular

Oda Scheen Kiese

Bicep

Simen Johnsrud

Vegard Saga

Øystein Lasson

Håkon Gjertsen Norbye

Embedded

ESP32

Rust

Silje Øvstetun

Her deler vi erfaringer vi har gjort oss med {{tagTitle}} i prosjekter og i hverdagen vår som utviklere.

Vi du vite mer om hvordan vi bruker {{tagTitle}} i Snøkam?

Våre utviklere med erfaring i {{tagTitle}}

{{tagTitle}} er en sentral del av flere av våre kundeprosjekter. Her ser du noen eksempler på hvordan vi har brukt teknologien i praksis.

{{tagTitle}} - Teknologi i Snøkam

Cloud handler om å bygge og drifte løsninger i skyen – der infrastruktur, lagring og tjenester lever digitalt i stedet for på lokale servere. Det gir fleksibilitet, skalerbarhet og sikkerhet, og gjør det enklere å utvikle, teste og lansere nye løsninger raskt. Cloud-teknologi muliggjør moderne utviklingsprosesser, automatisering og samarbeid på tvers av systemer, og er i dag grunnmuren for det meste av digital innovasjon.

Vipps MobilePay hadde behov for en plattform som kunne forenkle dataflyten mellom produsenter og konsumenter, samtidig som den gjorde vedlikehold enklere og mer effektivt. Den eksisterende infrastrukturen var tungvinn å vedlikeholde og begrenset i skalerbarhet. Dataprodusenter hadde ikke verktøy for rask og enkel deling av data, og datakonsumenter opplevde utfordringer med å finne, forstå og ta i bruk tilgjengelige dataprodukter.

Vi i Snøkam bidro til å bygge en moderne, selvbetjent dataplattform som adresserte Vipps MobilePay sine utfordringer. Gjennom automatisert infrastruktur med Terraform ble implementeringen robust og skalerbar. Tilgangsstyring ble forenklet med Purpose Based Access Control (PBAC), som sikret trygg og målrettet tilgang til data. For dataprodusenter var vi med å utvikle verktøy som muliggjorde rask oppsett av dataintegrasjoner gjennom datakontrakter. For datakonsumenter ble det designet brukervennlige grensesnitt som gjorde det enkelt å forespørre, analysere og bruke data. Automatisering av skjemaendringer og versjonering forenklet vedlikehold og reduserte risikoen for feil.

Den nye plattformen kobler tekniske og ikke-tekniske brukere tettere sammen, noe som legger til rette for smartere datadeling og raskere, datadrevne beslutninger. Vipps MobilePay har nå et solid, skalerbart fundament som støtter videre innovasjon, med en sterkere datakultur på tvers av organisasjonen.

Vipps MobilePay

Vipps MobilePay hadde behov for en plattform som kunne forenkle dataflyten mellom produsenter og konsumenter, samtidig som den gjorde vedlikehold enklere og mer effektivt.

Dataplattform for Vipps MobilePay

 er et norsk teknologiselskap som utvikler og leverer helhetlige løsninger for sikker, smart og bærekraftig sykkelparkering. Selskapet ble etablert med en tydelig visjon: å gjøre det enklere for mennesker å velge sykkel som transportmiddel ved å tilby infrastruktur som er trygg, brukervennlig og tilpasset moderne byliv. Med hovedkontor på Lysaker og virksomhet i både Norge og Sverige, kombinerer Bikeloop skandinavisk design med teknologisk innovasjon for å bygge fremtidens mobilitetsløsninger.

Bikeloop opererer i skjæringspunktet mellom fysisk infrastruktur og digital teknologi. De utvikler og produserer modulbaserte sykkelparkeringssystemer som kan skaleres fra små borettslag til store byutviklingsprosjekter. Kjernen i konseptet er en sømløs integrasjon mellom 

: fysiske parkeringsmoduler som styres gjennom en digital plattform for adgang, administrasjon og innsikt. Gjennom dette oppnår brukere enkel tilgang via app, mens eiere og forvaltere får full oversikt over kapasitet, bruk og vedlikehold.

 innen videreutviklingen og testing av kontrollsystemet med tilkoblede sensorer og backend services til 

, et kompakt, helautomatisk parkeringssystem som utnytter plassen vertikalt og muliggjør trygg lagring av mange sykler på en svært liten flate. HUB'en kombinerer avansert mekanikk med digital kontroll, slik at brukerne får tilgang via app, mens systemet selv håndterer parkering og henting av sykkelen på under et halvt minutt. Løsningen ble utviklet som en del av et bredere initiativ for å redusere bilbruk og fremme bærekraftig transport, og den første HUB'en ble installert på 

BikeLoop

Hos Bikeloop bidro vi i Snøkam innen videreutviklingen og testing av kontrollsystemet med tilkoblede sensorer og backend services til Bikeloop HUB, et kompakt, helautomatisk parkeringssystem for sikker sykkelparkering.

MQTT

Modbus

Kristian Lough-Grimsgaard

Sikker sykkelparkering for Bikeloop

AWS (Amazon Web Services) er Amazons skyplattform – en samling av hundrevis av tjenester for lagring, databaser, beregning, sikkerhet, maskinlæring og mer. Plattformen gir oss fleksibilitet til å bygge alt fra enkle nettsteder til komplekse, globale systemer.
Hos Snøkam bruker vi AWS for å utvikle og drifte løsninger som krever høy tilgjengelighet, skalerbarhet og sikkerhet. Den store bredden av tjenester gjør at vi kan velge akkurat de byggesteinene som passer best for hvert prosjekt, enten det handler om dataanalyse, integrasjoner eller infrastruktur.
AWS gir oss et solid fundament for moderne skyutvikling, med verktøy som gjør det mulig å eksperimentere, automatisere og vokse – uten å gå på kompromiss med kvalitet eller sikkerhet.

Bicep er et språk utviklet av Microsoft for å definere og administrere infrastruktur i Azure på en enkel og ryddig måte. Det lar oss beskrive hvordan skymiljøet skal se ut – som databaser, nettverk, servere og lagring – ved hjelp av kode i stedet for manuell oppsett.
Hos Snøkam bruker vi Bicep for å sikre at infrastrukturen i Azure er konsistent, versjonskontrollert og lett å gjenskape. Det gjør det enklere å automatisere oppsett av miljøer, redusere feil og bygge løsninger som kan skaleres trygt.
Bicep gir oss en tydelig og effektiv måte å jobbe med 

 i Azure – noe som bidrar til mer stabile, sikre og oversiktlige skyløsninger.

Docker er et verktøy som gjør det enkelt å pakke applikasjoner og alt de trenger for å kjøre, inn i såkalte “containere”. Dette sikrer at løsningen fungerer likt – uansett hvor den kjøres.
Hos Snøkam bruker vi Docker for å bygge, teste og drifte applikasjoner på en mer forutsigbar og effektiv måte. Det lar oss sette opp miljøer raskt, unngå konflikter mellom systemer, og sørge for at applikasjonene våre er enkle å flytte mellom utvikling, test og produksjon.
Docker gir oss en trygg og fleksibel plattform for moderne utvikling, og er en sentral del av måten vi bygger skalerbare, stabile og automatiserte løsninger på.

GCP (Google Cloud Platform) er Googles skyplattform, som gir oss tilgang til verktøy for alt fra datalagring og analyse til maskinlæring og sikker drift. Plattformen lar oss bygge og drifte løsninger uten å måtte tenke på fysisk infrastruktur, og gir høy fleksibilitet og pålitelighet.
Hos Snøkam bruker vi GCP til å utvikle og drifte skalerbare systemer, automatisere prosesser og bygge løsninger som håndterer store datamengder på en trygg måte.
GCP passer spesielt godt når vi jobber med data- og AI-prosjekter, takket være det tette samspillet mellom Google sine egne verktøy og åpne standarder. Det gir oss friheten til å velge teknologier som passer best til hvert enkelt prosjekt – uten å låse oss til én løsning.

Kubernetes er et system som hjelper oss å håndtere og drifte mange applikasjoner samtidig – spesielt når de kjører i skyen. Det sørger for at applikasjoner alltid er tilgjengelige, kan oppdateres uten nedetid og automatisk tilpasser seg når trafikken øker eller reduseres.
Hos Snøkam bruker vi Kubernetes for å bygge stabile og skalerbare løsninger som er enkle å vedlikeholde. Ved å automatisere store deler av driften får vi mer tid til å fokusere på utvikling og innovasjon, samtidig som systemene våre kjører trygt og effektivt.
Kubernetes gir oss fleksibilitet til å kjøre applikasjoner på tvers av ulike skyleverandører, og passer perfekt inn i en moderne utviklingsprosess med kontinuerlig levering og automatisering.

Cloud

Våre utviklere med erfaring i cloud

Cloud i våre prosjekter

Dataplattform for Vipps MobilePay

Sikker sykkelparkering for Bikeloop

Dette skriver vi om cloud

Episode 3: OKR automatisering

Krystallklart: Et innblikk i teknologien som driver Snøkam

Hur man skapar en bra MCP server för dokumentationssidor

Vad är en MCP server?

Vi du vite mer om hvordan vi bruker cloud i Snøkam?