Veel organisaties waar ik kom zitten volop in de cloud transitie. Bijna allemaal hebben ze een SaaS tenzij beleid. Maar tegelijkertijd wordt er geworsteld met het fenomeen vendor lock-in. Hoe zit dat nu precies?
Het hoogst haalbare in cloud computing is SaaS. Heerlijk, geen onderhoud aan applicaties en geen technisch beheer. Maar gewoon applicatie functionaliteit afnemen als water uit de kraan. Maar wel commodity en weinig onderscheidend. Daarna komt als runner up PaaS. Hiermee kun je je onderscheidend vermogen creëren en lekker innoveren. Dingen als kunstmatige intelligentie en slimme bots komen ineens binnen handbereik van kleine en middelgrote organisaties, zonder enorme investeringen vooraf te hoeven doen. IaaS is het laatste redmiddel; dit wordt met name gebruikt als applicaties niet gemakkelijk om te turnen zijn in PaaS of SaaS maar nog wel erg belangrijk zijn. Maar helaas wordt hier vaak wel mee begonnen, omdat het zo lekker gemakkelijk over te zetten is en misschien toch wel wat operationeel voordeel oplevert.
Juist met PaaS kun je de meeste toegevoegde waarde creëren dus. Met name op het vlak van data en integratie is er veel winst te behalen. De ontwikkelingen gaan razendsnel, en je kunt er direct gebruik van maken. Geen lange trajecten om infrastructuur op te tuigen. Gewoon gààn. We hebben het hier natuurlijk gewoon over maatwerk.
En vroeger creëerde je maatwerk in een 3- of 4-gl programmeertaal, misschien in combinatie met wat specifieke bibliotheken met herbruikbare functionaliteit. Dat was goed te porteren. Omdat op de meeste operating systems wel een compiler of interpreter beschikbaar was en òf de source code van die libraries beschikbaar was òf de library ook geporteerd was naar de andere omgevingen.
Tegenwoordig is dat een stuk lastiger. Elke cloud leverancier heeft eigen frameworks en PaaS bouwblokken, die totaal niet compatible zijn met de technologie van andere cloud leveranciers. De frameworks zijn enorm geworden. Groter dan je eigen code. Applicaties en apps worden ontwikkeld deels in code (bijvoorbeeld C#, Java of PHP) en deels met deze steeds groter wordende frameworks. PaaS is eigenlijk gewoon een leverancier specifiek framework. En de verhouding eigen code versus framework verschuift steeds meer richting framework.
Wat de cloud provider zo mooi stickiness noemt is toch wel een eufemisme voor wat je als cloud consument gewoon vendor lock-in noemt. Met SaaS zit je behoorlijk vast. Even migreren is niet zo makkelijk. En aangezien deze SaaS diensten eigenlijk nooit op open standaarden zijn gebaseerd is het ook niet makkelijk te automatiseren. Incompatibele opslagmethoden en procesdefinities en -engines zijn de boosdoener. Op PaaS gebied geldt eigenlijk precies het zelfde. Standaarden als XML, JSON en BPEL zijn leuk, maar weinig overdraagbaar als er een zware, toch wel leverancier specifieke implementatie op leunt; het PaaS framework. Opnieuw ontwikkelen is dus de enige mogelijkheid als je naar een andere PaaS provider wilt verhuizen. Maar tegelijkertijd is de time-to-market van oplossingen gebouwd op PaaS in combinatie met SaaS toch wel het allerkortst. En dat is ook erg veel waard!
We zien nu dat er vaak gepraat en geschreven wordt over containers. Lekker schaalbaar, afzonderlijk uitrolbaar en ook porteerbaar. Containers kunnen gemakkelijk verhuisd worden van AWS naar Azure bijvoorbeeld. En andersom. Echter, het is natuurlijk gewoon IaaS. Je bent zelf verantwoordelijk voor de stack. Een klein stackje vergeleken met een VM, maar toch. Onderhoud en beheer doe je dus helemaal zelf. Time-to-market met containers is te vergelijken met traditioneel software ontwikkelen met een 3-gl, maar dan zeer porteerbaar en schaalbaar uitrollen.
Het blijft een moeilijke afweging: portabiliteit en dus exit strategie versus gebruiksgemak en time-to-market. Per case dus een afweging maken op basis van uw requirements op dit gebied!
