Leveranciersafhankelijkheid (vendor lock-in)
De situatie waarin overstappen naar een andere leverancier zo duur, traag of contractueel geblokkeerd is dat je in de praktijk niet weg kunt, wat het contract ook zegt dat je mag.
Lock-in is de stille manier waarop soevereiniteit verloren gaat, door een opeenstapeling van gemakken die verharden tot beperkingen.
Lock-in komt zelden binnen als een keuze. Het stapelt zich op. Hier een managed service, daar een propriëtair formaat, een control plane waar je je runbooks omheen bouwt, en op een dag zou vertrekken meer kosten dan blijven, dus blijf je. Dat is het mechanisme, en daarom kan een workload die niet kan verhuizen niet echt jouw eigendom zijn.
Het heeft meerdere gezichten: propriëtaire diensten zonder open equivalent, dataformaten die alleen de leverancier kan lezen, leverancierspecifieke API’s die door je code heen geweven zijn, identiteit en secrets die aan de control plane van de leverancier vastzitten, vaardigheden en tooling die uitgaan van één leverancier en commerciële voorwaarden zoals egress-kosten of minimumafnames. Elk daarvan is een overstapkost, en de totale overstapkost is de echte maat voor lock-in.
De verdediging is om het vermogen om te vertrekken op te bouwen vóórdat je het nodig hebt. Portabiliteit, open formaten en een uitvoerbare exitclausule zijn de drie hefbomen die overstappen een echte optie houden.
Veelgemaakte misvattingen
We zitten niet vast, we kunnen onze data exporteren wanneer we maar willen.
Data-export is maar één dimensie. Propriëtaire API's, managed services zonder equivalent, identiteit die aan de leverancier vastzit en egress-kosten kunnen elk het vertrek veranderen in een heel project.
Open source betekent geen lock-in.
Je kunt vastzitten aan een specifieke managed distributie, een control plane of een operationeel model, zelfs als de broncode open is. Lock-in is een eigenschap van het hele systeem, en een open licentie beslecht dat niet.