Vendor locking har blitt en slags moralsk panikk i utviklingsmiljøer. Ikke bind dere til Azure. Ikke bruk noe for tett knyttet til Microsoft. Ikke gjør dere avhengige av én leverandør. Det høres alltid klokt ut. Det høres ansvarlig ut. Men veldig ofte er det bare innøvde faglige reflekser, gjentatt så mange ganger at ingen lenger stopper opp og tenker etter.

Jeg sier ikke at vendor locking ikke finnes. Det gjør det. Jeg sier heller ikke at det aldri er farlig. Men utviklere snakker altfor ofte om vendor locking som om alle teknologivalg har samme risiko. Som om det å bruke .NET, hoste i AWS eller utvikle på Linux er omtrent det samme som å låse en hel virksomhet til et ERP-system eller en SaaS-plattform ingen klarer å komme seg bort fra. Det er jo åpenbart ikke det samme.

Jeg har selv møtt utviklere som nærmest advarer meg mot at vi bruker Windows, Azure eller .NET, som om det i seg selv forklarer hvorfor et prosjekt vil gå galt. Min erfaring er det motsatte. Prosjekter går sjelden dårlig fordi man valgte feil skyplattform. De går dårlig fordi vi misforstår problemet, bygger for mye og gjør en dårligere jobb enn vi liker å innrømme.

Vi later som vi står friere enn vi gjør

Nesten all programvareutvikling innebærer bindinger. Velger du språk, plattform, database, pipeline eller sky, så velger du også hva som blir lett og hva som blir dyrt senere. Det finnes ikke et magisk punkt der du er helt fri. Det finnes bare ulike typer bindinger med ulik kostnad.

Likevel bruker mange team enormt mye tid på å late som de ikke har vendor locking. De pakker inn skytjenester bak egne abstraksjoner, lager generiske lag for lagring og meldingskøer, og bygger interfaces over alt fordi det ser pent ut i et arkitekturdiagram. Men hvis hele løsningen kjører i Azure, teamet ditt kan Azure og driften er bygget rundt Azure, da er du låst i praksis. Et ekstra lag med kode endrer ikke det særlig mye.

Jeg har vært i prosjekter der vi brukte tid og penger på å lage «agnostiske» pipelines og IaC oppsett for abstrahere bort vendor locking vi aldri faktisk kom til å fjerne. Ikke fordi det var et reelt behov, men fordi det føltes riktig. Når jeg ser tilbake på det, fremstår mye av det som meningsløst arbeid.

Tredjepartsverktøy gjør deg ikke nødvendigvis fri

Det kanskje rareste i hele diskusjonen er troen på at tredjepartsverktøy automatisk gjør deg mer uavhengig. Det er ofte bare vendor locking i penere innpakning. Du flytter ikke nødvendigvis risikoen. Du flytter bare bindingen.

I stedet for å bruke en godt integrert tjeneste fra Microsoft, AWS eller Google, tar man inn et produkt med sitt eget API, sin egen roadmap og sin egen supportrisiko. Og veldig ofte er dette verktøyet tett koblet til de samme skyplattformene man later som man holder avstand til.

Da bør man tørre å stille et enkelt spørsmål: Hva er det vi faktisk har oppnådd? Hvis svaret er mer kompleksitet, mer feilsøking og enda en leverandør å bli avhengig av, da er ikke dette strategisk frihet. Det er bare vendor locking med bedre PR.

Ikke all locking er like farlig

Det er her jeg mener mange utviklere roter det til. De snakker om valg av IDE, programmeringsspråk og skyplattform som om det tilhører samme risikokategori som tunge forretningssystemer og kjerne-SaaS. Det gjør det ikke.

Å velge .NET eller Azure er som regel et håndterbart teknologivalg. Å låse hele organisasjonen til et ERP-system, en dataplattform eller en SaaS-løsning som styrer sentrale prosesser, er noe helt annet. Når vi bruker samme ord om begge deler, blir begrepet vendor locking mindre nyttig.

Det viktige er ikke å unngå bindinger

Det viktige er å forstå hvilke bindinger som faktisk er dyre å reversere. Det er en mye mer voksen diskusjon. Ikke spør om dere er helt leverandøruavhengige. Spør hvor vondt det vil gjøre å endre et valg senere, og om det er et valg som faktisk er verdt å holde åpent.

Velg gjerne Azure hvis det gir fart. Velg gjerne .NET hvis teamet er gode på det. Bruk gjerne tredjepartsverktøy hvis de løser et konkret problem. Men vær ærlig om hva dere binder dere til, og slutt å late som teknologisk renhet er et mål i seg selv.

Min påstand er ganske enkel

Mye av det som gjøres for å unngå vendor locking er ikke godt utivklerarbeid. Det er pynt. Det ser bra ut i presentasjoner, men gjør ofte løsningen tyngre, tregere og dyrere å leve med.

Vendor locking er reelt. Men det er ikke automatisk farlig bare fordi du bruker teknologi fra en stor leverandør. Det farlige er bindinger som er så dype og så dyre at du mister reelt handlingsrom. Resten er ofte bare teknologivalg med helt vanlige konsekvenser.

Så ja: Utviklere overdriver faren ved vendor locking. Og i forsøket på å unngå det, ender mange med å bygge langt mer kompleksitet enn problemet de prøver å beskytte seg mot.

Noen ganger er ikke vendor locking det store problemet. Noen ganger er problemet at vi elsker å late som vi er friere enn vi er.