Het probleem met SaaS is dat bedrijven best honderd verschillende applicaties willen gebruiken, maar dat ze niet de databases en datacenters van die honderd leveranciers ieder jaar willen controleren. SaaS schaalt dus niet! Wel technisch, maar niet organisatorisch. Na een paar applicaties daalt, zoals Gartner recent aangaf, het enthousiasme. Eigenlijk wil je SaaS (software) en IaaS (infrastructuur) ontkoppelen, zodat je in een soort Cloud AppStore SaaS-applicaties kunt kiezen en die draaien bij door jou gekozen en geaudite IaaS-leveranciers. Lijkt ver gegrepen, maar de eerste cloudaanbieders volgens dit nieuwe broker-model zijn al live en maken de cloud meer beheer(s)baar.
Nu cloudaanbieders de zorgen rond beveiliging en regelgeving beginnen te adresseren, verschuift de aandacht in rap tempo naar de gevaren van lock-in en mogelijkheden om dit te voorkomen. Gedurende de Europese vakantieperiode waren er enige interessante ontwikkelingen en aankondigingen op dit gebied. Zo kondigde Microsoft aan dat het Azure beschikbaar gaat maken als PaaS-platform voor een aantal grote IaaS-aanbieders, terwijl Rackspace samen met Nasa zijn OpenStack-platform inbracht in de open source-community.
Niet dat ik denk dat de aankondiging van Microsoft is ingegeven door een diep verlangen om lock-in te voorkomen, het heeft ongetwijfeld meer te maken met de in Redmond gekoesterde wens om het marktaandeel van hun PaaS-platform snel te vergroten. Maar het leidt er wel toe dat Azure-klanten straks de keuze krijgen uit een aantal leveranciers voor de onderliggende infrastructuurdiensten (IaaS). Deze ontkoppeling van de SaaS- en PaaS-laag van de onderliggende infrastructuur (IaaS)-lagen is (zoals eerder beschreven in mijn blog ‘Vendor lock-in and Cloud Computing‘) een belangrijke randvoorwaarde om de bijna inherente lock-in van cloudoplossingen te adresseren.
Tegelijk schaarden Nasa en Rackspace zich achter een open source-platform voor private clouds, genaamd OpenStack. Natuurlijk spelen commerciële motieven hier net zo goed een rol als bij Microsoft. Ervan uitgaande dat Rackspace verwacht dat veel private clouds in de nabije toekomst extra capaciteit zullen inkopen bij openbare clouds (cloudbursting), dan is het voor Rackspace zonder meer gunstig als die private clouds op dezelfde architectuur zijn gestoeld als RacKSpace's publieke cloud. Nasa wordt waarschijnlijk meer gemotiveerd door het cloudstimuleringsprogramma van de Amerikaanse overheid en de daarmee verwachte financieringsbronnen. Hierbij streeft de Amerikaanse overheid expliciet naar ‘het sneller beschikbaar maken van standaarden voor cloud computing'.
De investeringen van de Amerikaanse overheid in cloud computing kunnen worden beschouwd als een hedendaags stimuleringspakket voor de bedrijfstak. Naar mijn mening kunnen de huidige inspanningen van onder andere Nasa net zo belangrijk zijn voor cloud computing als de defensiebudgetten die ten tijde van de koude oorlog waren voor de ontwikkeling van computernetwerken en het Apollo-project voor de technologische vooruitgang in het algemeen.
Als de geschiedenis zich herhaalt, is het waarschijnlijk dat eerst ‘industriestandaarden' zullen leiden tot een ‘plug-compatibele' cloudmarkt, alvorens een cloudmarkt met werkelijk open standaarden zal ontstaan. Omdat Nasa, anders dan bij het maanlandingsprogramma, nu geen decennium de tijd heeft, is het begrijpelijk dat zij het initiatief van Rackspace zien als een manier om sneller tot werkbare cloudstandaarden te komen. Op dit moment open cloudstandaarden opstellen zou overigens net zo lastig zijn als het opstellen van een standaard voor 3D-televisie ten tijde van de zwart/wit-uitzending van de eerste maandlandingen. Met ander woorden, het is gewoon nog te vroeg om te bepalen welke cloudstandaarden zullen gaan winnen, dus ook eindgebruikers doen er goed aan hun keuze zo lang mogelijk uit te stellen.
Een ontkoppelde cloud
Het idee dat lock-in voorkomen kan worden door de keuze voor applicatie (SaaS)- en platform (PaaS)-leveranciers los te koppelen van de onderliggende keuzes voor infrastructuur (IaaS)-aanbieders, klinkt overigens voor veel cloudevangelisten als vloeken in de kerk. Zij redeneren dat als je controle wilt hebben over onderliggende lagen je niet moet beginnen aan cloud computing, want het idee achter cloud computing is nu juist dat iemand anders zich bekommert om de onderliggende lagen. Een redenering die in mijn ogen evenveel hout snijdt als wanneer je geen kleding wilt die door minderjarige kinderen is gemaakt, je een naaimachine moet kopen om je eigen kleding te maken.
Wel is het belangrijk om een voorstelling te maken hoe een dergelijk ontkoppelde cloud er in de praktijk uit zou zien. Gelukkig is een eerste praktijkvoorbeeld van een dergelijk ontkoppelde cloud al in de praktijk beschikbaar. Het Amerikaanse bedrijf Skygone biedt klanten geografisch informatie (GIS) door GIS-oplossingen van verschillende GIS-softwareleveranciers aan te bieden op een aantal door de klant te kiezen infrastructuurplatformen en leveranciers. Bedrijven die dat soort geografische informatie willen gebruiken – een ingewikkeld en specialistisch gebied waarvoor het de meeste interne ict-afdelingen ontbreekt aan kennis en interesse – kunnen deze informatie nu eenvoudig inkopen zonder zich voor lange termijn te binden aan een softwareleverancier of infrastructuurplatform.
Verscheidene industrie-analisten gaven al vroeg aan dat er voor dit soort van ‘cloudbrokering' een belangrijke rol in de cloudmarkt zou gaan spelen. Helaas horen we de afgelopen maanden – wellicht onder invloed van het betreden van de cloudmarkt door een aantal zelfverklaarde honderd pond gorilla's – weinig analisten meer over dit concept. Jammer, want het adresseert ook het feit dat voor de gemiddelde onderneming ‘SaaS niet schaalt'.
De onschaalbaarheid van SaaS?
Voordat sommige lezers zich nu gaan opwinden; met ‘de onschaalbaarheid van SaaS' bedoel ik niet dat SaaS-applicaties niet in staat zouden zijn om miljoenen gebruikers te bedienen. Dat gebeurt nu al, zij het niet altijd even succesvol en betrouwbaar. Waar ik op doel is dat de gemiddelde onderneming of overheidsinstantie, die doorgaans honderden of zelfs duizenden applicaties gebruikt, zich gewoonweg niet kan veroorloven deze af te nemen van een vergelijkbaar aantal SaaS-leveranciers. De verplichte controle van de infrastructuur en processen van al die leveranciers zou gewoon onhaalbaar zijn, ook al omdat, zoals een toonaangevend analistenbureau onlangs opmerkte, deze verplichte due diligence niet worden vervangen door een SAS70-certificaat. Bijna op hetzelfde moment suggereerde deze analist ook dat het voor veel SaaS-leveranciers zinvol zou zijn samen te werken met IaaS-leveranciers voor de levering van hun diensten en dat de traditionele SaaS-markt wellicht minder sterk zal groeien dan velen aanvankelijk dachten. Drie seperaat gesignaleerde ontwikkelingen, die in mijn ogen echter duidelijk verband met elkaar hebben.
Een betere benadering
Om lock-in te voorkomen streven we ernaar dat ondernemingen applicaties kunnen afnemen van diverse SaaS- en PaaS-leveranciers en deze kunnen implementeren op infrastructuur van door hen zelf geselecteerde en gecontroleerde IaaS-leveranciers. Let wel, dit lijkt niet op de oude manier waarbij een ict-afdeling haar soft- en hardware apart kocht en deze vervolgens zelf moest implementeren en integreren. Een analogie uit de ict-consumentenmarkt maakt het verschil duidelijk:
De oude benadering van ict: Als consument ga je naar een computerwinkel om een softwarepakket te kopen, bijvoorbeeld een kookprogramma. Je maakt een verantwoorde keuze uit de twintig aanbieders (je kiest de doos met de mooiste foto's). Thuis merk je dat de versie van het besturingssysteem, de database of de browser op jouw pc niet wordt ondersteund. Dit probleem los je op (jammer van het weekend), maar het werkt nog steeds niet. Terwijl je advies vraagt bij een buurman, neef of collega, merkt jouw partner fijntjes op dat er de komende maand nog veel afhaalmaaltijden op tafel zullen komen. Na een week of drie heb je het eindelijk aan de praat, alleen printen wil nog niet zo goed lukken. Je hebt veel geleerd over jouw pc, maar weinig over koken. Een maand later koop je een nieuwe pc en tot jouw verbazing werkt het pakket niet meer. Gelukkig krijg je een e-mail van de leverancier met een aanbieding voor een upgrade, die wel op jouw nieuwe pc moet werken. Gezien de kosten van afhaalmaaltijden, besluit je die upgrade maar aan te schaffen.
De nieuwe benadering van ict: Je hebt honger en opent zonder uit jouw stoel te komen de appstore op jouw mobieltje. Je kiest uit de zestig kookapplicaties de meest gedownloade (nadat je wat commentaren van gebruikers hebt gelezen). Je bereidt jouw eerste maaltijd, deze smaakt iets te zout. Je geeft de applicatie de schuld, verwijdert deze en haalt een andere op. Dat smaakt beter. Nu nog beslissen of je de gratis versie wilt gebruiken (met een automatisch afgedrukt boodschappenlijstje voor de supermarktketen die de app sponsort) of liever twintig cent per gebruikt recept betaalt.
Uiteraard is de bedoeling dat de geschetste ontkoppelde cloud werkt zoals in het tweede scenario wordt beschreven. Wellicht is het je ook opgevallen dat het in het eerste voorbeeld vooral ging over technologie en in het tweede over koken. Ook in de hedendaagse bedrijfs-ict gaat het tegenwoordig te weinig over wat het bedrijf doet en meer over technologie. De geschetste aanpak biedt ict de mogelijkheid om van een aanbodgestuurd model, waarbij ict zich gedraagt als een fabrieksmanager die zorgt voor de productie van services, weer te gaan naar een vraaggestuurde ict-organisatie waarin ict het aanbod van allerlei clouddiensten sourced en orchestreerd in een ict-supply chain. Bij voorkeur zonder zich daarbij vast te ketenen aan een leverancier of technologie. Uiteindelijk is het de bedoeling dat we die 20 procent van de functies waarmee ons bedrijf zich echt onderscheidt kunnen leveren, terwijl we de overige 80 procent, die vrijwel gelijk zijn voor elk bedrijf, kunnen inkopen. Dat soort flexibiliteit is de ware belofte van cloud computing en de geschetste ontkoppeling van de diverse cloudlagen is hiervoor een eerste stap.
