Nee.
Zo. Dat was mijn kortste blogpost ooit. Wellicht iets te kort zelfs. En een beetje te kort: zoals alles in het leven hangt het antwoord af van de context.
Mijn professionele carrière begon zo’n 3 decennia geleden. In die tijd heb ik de industrie enorm zien veranderen. Veel van de dingen waar we ons in mijn begin tijd druk om maakten zijn niet relevant meer en vervangen door andere onderwerpen. Deze zijn uiteraard over een paar jaar ook niet relevant meer.
Maar een onderwerp blijft iedere keer terug komen: Vendor Lock In. De angst om door bepaalde keuzes te maken vast te zitten aan een leverancier. Of vast: het kan veel tijd en geld kosten om te wisselen van leverancier.
Dit is iets wat je op veel plekken terugziet, niet alleen in de IT. Op de meest onverwachte plekken kom je dit wel tegen. Een voorbeeld: mijn vrouw had een mooie pen gekregen. Je kent het wel: zo’n veel te dure pen die je vervolgens niet durft te gebruiken omdat iemand anders hem even “leent”.
Wat blijkt nu: als je deze wilt vullen, kan er alleen een (dure!) Mont Blanc vulling in. Je geeft dus een hoop geld uit aan een pen, en vervolgens blijf je tot in de lengte van dagen betalen aan Mont Blanc voor de vullingen.
Andere voorbeelden van wat subtielere vormen van vendor lock in zijn de kortingskaarten, spaarsystemen, membership awards en andere zaken die er maar voor zorgen dat je terugkomt bij dezelfde aanbieder. Deze zijn minder ernstig: je hebt nog altijd de keuze om ergens anders heen te gaan, hoewel je dan wat voordelen mis loopt. Bij echte lock in zit je vast een de leverancier, tot je bereid bent om een hoop geld uit te geven om te veranderen. Voor de leverancier is dat natuurlijk prachtig: ze zijn min of meer verzekerd van je klandizie.
Maar wat als deze leverancier stopt met deze dienst? Of erger nog: wat als de leverancier failliet gaat? Wat moet je dan? Dat is voor veel organisaties de reden om bij alles heel voorzichtig te zijn met de keuze van een leverancier.
Reality check
Maar is dat wel een probleem? Hoe erg is het als je met je software keuzes, platform keuzes of tooling keuzes vastzit aan een leverancier?
Het antwoord is natuurlijk: dat ligt er aan. Als je als organisatie volledig afhankelijk ben van de oplossingen die “het bedrijfje van het neefje van de baas” levert, dan heb je wel een probleem. Dit soort oplossingen zijn niet echt toekomst bestendig. Maar als je kiest voor een grote leverancier als partner, dan wegen de voordelen vaak enorm op tegen de eventuele nadelen.
Zoals met alles in ons vak is het verstandig om een risico analyse te houden. Op die manier kunnen we die risico’s kwantificeren en kunnen we een keuze maken op basis van cijfers in plaats van onderbuik gevoelens.
Toen ik begon in mijn eerste baan, hadden we een behoorlijk divers IT landschap. Onze PC’s waren verbonden door een Novell netwerk, onze email server was een Solaris machine (die bij beheer ergens in een kast stond….), onze PC’s draaiden voornamelijk Windows 3.0 en sommigen hadden een Unix machine. De database was natuurlijk Oracle. We hadden van alles wat.
In de loop van de tijd gingen we standaardiseren. We kozen om volledig voor het Microsoft platform te gaan. We installeerden Windows 3.11 For Workgroups op de PC’s, we kregen nieuwe servers met Windows NT 3.5, we kregen een ethernet netwerk, we kozen voor SQL Server als database platform. Het enige waar we afweken was de keuze van onze development tools: we kozen Borland C++ als platform om op te ontwikkelen.
En uiteraard waren er mensen die riepen dat dit heel dom was. Onze vorige oplossing was veel diverser en we hadden de risico’s gespreid. Door all-in te gaan met Microsoft hingen we de toekomst van het bedrijf op aan de toekomst van Microsoft. Ik zal de uitkomst vast verklappen: Microsoft is op het moment van schrijven het op-een-na grootste bedrijf ter wereld, mijn werkgever bestaat al dik 25 jaar niet meer…
Een jaar of 10 later kwam ik in een zelfde soort discussie. Een klant ging helemaal voor Java. Want: dat was platform onafhankelijk. Ze konden alle kanten op. De database was Oracle, maar wel via een ODBC driver (voor degene die dat niet kennen: een abstractie laag op de database zodat je onafhankelijk van de database engine dezelfde queries kon draaien).
Iedereen vond het een geweldige oplossing. Het maakte niet uit wat de toekomst ons zou brengen: wij waren er klaar voor. Java beloofde ons een Write Once, Run Everywhere ervaring en ODBC zorgde ervoor dat we direct konden wisselen van database engine.
Dat hebben we ongeveer 2 maanden volgehouden.
Al gauw merkten we dat Java in zijn pure vorm een hele mooie programmeertaal is, maar dat de taal op zich niet belangrijk is. Het gaat om de frameworks en libraries die je gebruiken gaat.
Dus wat deden we: we importeerden de QT library, maar dan wel de variant voor Windows. Want: die ondersteunde alle GUI elementen die we nodig hadden.
ODBC ging er ook uit. Niet omdat veel ontwikkelaars ODBC al snel SlowDBC noemden (en terecht…) maar omdat we met die tussenlaag niet goed alle features konden gebruiken die Oracle ons bood. Een directe verbinding met Oracle gaf ons de mogelijkheid om onze performance te verbeteren door snellere connectivity en door gebruik te maken van typische Oracle functies.
En zo gingen we langzaam van een open, vendor-neutrale optie over naar een systeem dat met handen en voeten gebonden was aan bepaalde leveranciers.
Microsoft en .net
Een paar jaar later werkte ik fulltime met het framework van Microsoft: .net. En ook hier kreeg ik weer de vraag: moeten we hier mee verder gaan? We zijn met handen en voeten aan Microsoft gebonden.
En ook hier gebeurde hetzelfde: hoewel .Net veel opties biedt om relatief onafhankelijk te werken (niet zo sterk als bij Java, maar toch) kozen we al gauw voor standaardisatie voor het platform, de database, de middleware, de communicatie en alle andere aspecten. .NET biedt weliswaar de mogelijkheid om bijvoorbeeld met ODBC een koppeling met de database te leggen, maar dat heeft absoluut nadelen.
Laten we eerlijk zijn: hoe vaak wisselt jouw organisatie van database leverancier? Hoe belangrijk is het om de systemen vandaag op Oracle te draaien en morgen naar SQL Server te moeten gaan? De meeste bedrijven (lees: alle) draaien al jaren op hetzelfde platform. Die willen niet over. Dus waarom zou je je in allerlei bochten wringen om die switch mogelijk te maken?
Microsoft Azure
Vandaag de dag krijg ik nog steeds exact dezelfde vragen van mijn klanten. Moeten we kiezen voor AWS, Google Cloud of voor Azure? Of leggen we ons dan vast aan een leverancier?
Mijn voorkeur mag duidelijk zijn. Ik werk al 30 jaar met Microsoft technologie (ik heb Borland C++ al heel lang geleden gedag gezegd) en dat is de omgeving die ik ken en waar ik mijn weg in kan vinden. Maar heb ik dan iets tegen AWS? Raad ik Google Cloud af? Nee, natuurlijk niet. Azure en AWS ontlopen elkaar niet zo heel veel. De ene is beter in de ene feature, de ander in de ander. Google Cloud loopt wel iets achter maar kan heel goed passen bij jouw eisen en wensen.
Ik zeg mijn klanten altijd: maak een wensen lijstje en kies daar de juiste provider bij. En als je wensen niet helemaal passen bij wat die aanbieder heeft, pas dan als het mogelijk is je wensen aan. Cloud aanbiedingen veranderen continue en wellicht is een andere oplossing beter dan wat je eerst dacht. Maar: wees niet bang voor Vendor Lock in van een bedrijf als Amazon, Google of Microsoft. Deze bedrijven blijven voorlopig wel actief. Microsoft Azure is enorm open en als je graag alles op Linux wilt, dan kan dat (welke Linux? Let op: ook hier is lock-in een risico). Vendor Lock-in is een term die veel mensen gebruiken maar de risico’s hier zijn minimaal ten opzichte van de winst als je kiest voor standaardisatie.
Nou ja, behalve als je gaat voor het neefje van de baas. Die optie is iets wat je wellicht goed moet heroverwegen…
Dennis Vroegop 