Veel organisaties waar ik over de vloer kom, zitten volop in de cloudtransitie. Bijna allemaal hebben ze een saas (software-as-a-service)-tenzij-beleid. Tegelijkertijd bestaat er de worsteling met het fenomeen vendor lock-in. Hoe zit dat nu precies?
Het hoogst haalbare in cloudcomputing is saas. Heerlijk. Geen onderhoud aan applicaties, geen technisch beheer, gewoon applicatiefunctionaliteit afnemen als water uit de kraan. Maar wel commodity en weinig onderscheidend. Daarna komt als runner-up platform-a-as-a-service (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.
Infrastructure-as-a-service (iaas) is het laatste redmiddel. Iaas komt met name kijken als applicaties niet gemakkelijk om te turnen zijn in paas of saas maar nog wel belangrijk zijn. Helaas wordt hier vaak wel mee begonnen, omdat het zo lekker gemakkelijk over te zetten is en misschien toch wel wat operationeel voordeel oplevert.
Waarde creëren
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 4GL-programmeertaal, misschien in combinatie met wat specifieke bibliotheken met herbruikbare functionaliteit. Dat was goed te porteren. Omdat op de meeste besturingssystemen wel een compiler of interpreter beschikbaar was en óf de broncode van die libraries beschikbaar was óf de library ook geporteerd was naar de andere omgevingen.
Tegenwoordig is dat een stuk lastiger. Elke cloudleverancier heeft eigen frameworks en paas-bouwblokken, die totaal niet compatible zijn met de technologie van andere cloudleveranciers. 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.
Stickyness versus time-to-market
Wat de cloudprovider zo mooi ‘stickiness’ noemt is toch wel een eufemisme voor wat je voor een cloudconsument gewoon vendor lock-in heet. 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 paasprovider 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 veel waard!
We zien nu dat er 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 virtuaal machine, maar toch. Onderhoud en beheer doe je dus helemaal zelf. Time-to-market met containers is te vergelijken met traditioneel software ontwikkelen met een 3GL, 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 de requirements op dit gebied.
