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.
Als ik je artikel zo lees, dan ijkt me dat je juist met IaaS waarde kunt creëren, zonder last te hebben van de Vendor lock-in. Mits je natuurlijk wel let op een goede exit-strategie. Die kan bij de hyperscalers wel eens lastig zijn. Er zijn echter genoeg partijen in de markt die een goede IaaS dienst leveren en daar ook nog wat extra management van de VM en het OS bij leveren.
Bij ‘paashaas’ Gijs komt er geen water uit de kraan om af te wassen maar blauwe smurfen die de afwas voor je doen. En voor elke andere klus verkoopt Gijs je een andere kraan, er is echter maar één afvoerputje. Bij PaaS moet je beginnen bij de exit strategie welke niet alleen om de data portabiliteit gaat omdat je niks aan één emmer hebt als je koud en warm water moet verplaatsen.
begrijp ik het goed ?
met saas en paas vendor lockin as a service of met iaas op somebody elses computer..
en containers hebben uiteindelijk ook infra nodig.
terug bij af.
Toevallig haalde ik dit artikel aan in een reactie, maar verwees nog naar het origineel van Gijs ( https://www.computable.nl/artikel/expertverslag/cloud-computing/6538531/4573232/netapp-verrast-met-bijzondere-cloud-benadering.html#reply6552117 )
Op LinkedIn had ik ook op Gijs zijn artikel gereageerd en omdat ik dus al wat langer met de inhoud bekend ben is het mij gaan dagen wat Gijs bedoeld en hoe ik het zie. Ik zal het hier kort beschrijven.
Veel infrastructuur specialisten of mensen die automatisering doen voor de wat grotere organisaties die ook al wat met cloud doen zien containers als een flexibele vorm van VM’s en dus infrastructuur as a service. Zij zullen de voordelen van containers niet erkennen omdat die er volgens hun niet zijn. De leercurve en toegevoegde complexiteit schrikken veel mensen af om containers te gebruiken. Kubernetes is een tussenlaag die veel dingen voor je kan regelen maar in begin ook lastig is juist te configureren.
Op dit vlak lossen containers geen problemen op, ze zijn onderdeel van het probleem geworden.
Containers en kubernetes hebben een specifieke use case die niet gericht is op de manier waarop huidige automatisering bij bedrijven is ingericht.
In dat licht ben ik het dus wel met Gijs eens.
Maar.
Als jij diensten levert aan diverse bedrijven met een gestandaardiseerd platform en geautomatiseerd oneindig door wil kunnen groeien en een hoge mate van automatisering hebt gerealiseerd. dan lossen containers en kubernetes juist een heel groot probleem op.
Daarnaast en dit lees ik ook in Gijs zijn tekst lenen containers en kubernetes zich heel goed voor microservices, SOA en serverless functies. Dit zijn echter zaken die NAAST een bestaand ERP en legacy producten draaien of een tussenlaag en verlengstuk zijn.
Doordat veel cloud providers nu ook het kubernetes deel aan het “ver-paas-en” zijn vind ik de duiding dat containers IaaS is niet geheel passen. Maar het hangt af van je use case en je definities.
Het klinkt allemaal wat veel jargon, sorry. Dingen moeilijk beschrijven is veel makkelijker dan moeilijke dingen makkelijk beschrijven.Ik duik snel weer mijn container in.
@Henri
Wat is infrastructuur?
Ik stel deze vraag omdat te vaak alleen naar het server-to-server of server-to-client netwerk gekeken wordt welke 5 tot 15 jaar achter loopt op de technologische ontwikkelingen. En containers verplaatsen zich via de bovenkant van de stack, reken dus zelf maar uit hoeveel tijd je nodig hebt als je 20 teraBYTE wilt verplaatsen over een 10 gigaBIT netwerk. Dit is niet dedicated (QoS) waardoor er nog altijd niets boven de bandbreedte van een oude dieselvrachtwagen vol met LTO-7 tapes gaat. Reken zelf maar uit hoe snel je 200 exaaBYTE van Maastricht naar Groningen verplaatst tegen een fractie van de kosten.
Oja, in voorgaande reactie wees ik op de capaciteit van het ‘afvoerputje’ welke om de bussen gaat, nieuwste ontwikkeling daarin is NVMe.