Cloud?… Let’s go Public!… En dan?

Behalve startups en andere jonge organisaties, nemen nu ook grotere bedrijven steeds vaker de beslissing om een publieke cloud in te zetten voor bedrijfskritische taken. Wat zijn de – mogelijk onverwachte – uitdagingen en keuzes waarvoor de verantwoordelijken komen te staan?

Acceptatiefase aangebroken
Na de gebruikelijke marktreactie van angst en wantrouwen, is de acceptatiefase duidelijk aangebroken: het openbare, publieke cloud (‘Public cloud’) heeft haar bestaansrecht in de ICT-mix van kleine én grote organisaties bewezen. Wat ik tekenend vond, was dat Amazon (dat ook clouddiensten levert) in het derde kwartaal van 2013 een nettogroei van de omzet meldde van 24 procent ten opzichte van dezelfde periode in het voorgaande jaar. Ook zie ik onder mijn zakelijke en privérelaties een duidelijke toename in het gebruik van de publieke cloud – en vermoed daarbij dat veel lezers die ervaring met mij zullen delen. De publieke cloud is duidelijk niet meer alleen het domein van de (software)ontwikkelaar en wordt vaker ingezet als drager van kritieke applicaties en datasets.

Bestaansrecht op basis van praktische voordelen
Voor ontwikkelaars en ‘early adopters’ speelt vooral prijs een hoofdrol. Zeker op kleinere schaal, biedt de publieke cloud tegen lage (of in ieder geval acceptabele) kosten verschillende mogelijkheden die voorheen onbetaalbaar waren. Een goed voorbeeld is het geografisch verspreiden van data en applicaties over meerdere continenten, zoals Amazon dat bijvoorbeeld doet.

De publieke cloud trekt ook grotere organisaties aan, bijvoorbeeld als het gaat om test/ontwikkel-omgevingen waarbij het natuurlijk loont om – voor heel korte tijd – virtuele systemen op te tuigen om vervolgens alleen voor dat kortstondig gebruik te betalen. Ook het pijlsnel kunnen opschalen bij ‘gebleken succes’ van een nieuw initiatief is een belangrijke drijfveer (al zijn er vormen van groei die we beter met een eigen, ongedeelde infrastructuur zouden faciliteren).

Een teken aan de wand is dat grotere bedrijven steeds belangrijker – soms zelfs bedrijfskritieke – applicaties aan de publieke cloud toevertrouwen. Zo hebben onder meer Unilever, Nokia en Vodafone verschillende belangrijke activiteiten op Amazon ondergebracht. Ik beperk mij in dit stuk daarom tot de grotere organisatie die overweegt om een belangrijke applicatie aan een publieke clouddienst toe te vertrouwen.

De keuze voor infrastructuur: Publieke cloud of Private, Managed Hosting, Colocatie, …?
Hoewel het onderwerp van de kostprijs in elke keuze meeweegt, mag het niet het primaire criterium zijn. Ook zou men de keuze niet op één hoofdcriterium zoals ‘veiligheid’ of ‘shared of dedicated’ moeten baseren…

Ik ben stellig van mening dat het altijd de bedrijfsbehoeften zijn die de criteria bepalen, waarna men die gaat invullen met de daartoe best geëigende diensten en concepten (ongeacht het type infrastructuur).

Een voorbeeld: een forse, traditionele organisaties heeft de interne IT op een even ‘traditionele wijze’ ingericht (SysOps, gedacht vanuit de ICT-kant van de zaak). De uitgebreide processen doorlopen vele afdelingen en dát staat haaks op de cloud (die door de inherente flexibiliteit en buigzaamheid juist uitnodigt tot DevOps, waarbij de business en de ICT de koppen bij elkaar steken). Het heeft voor dit bedrijf natuurlijk weinig zin om de snelle implementatie van een virtuele omgeving in de publieke cloud als hoofdcriterium te nemen; de interne organisatie kan hier intern namelijk nog niet mee overweg [1].

Het ‘Doe Het Zelf’-karakter van de Publieke cloud
We denken naar mijn idee te snel dat de Publieke cloud een ‘klik-en-klaar’-oplossing zou zijn. Nadat u de dienst heeft besteld, zal uw organisatie namelijk nog heel veel taken moeten verrichten:

• Eerst om de virtuele infrastructuur eenmalig in te richten (configuratie) en aansluitend veelal te integreren met bestaande, vaak lokaal opgestelde data en applicaties. Dit wordt gevolgd door tests en daaruit volgende aanpassingen;
• Daarna om haar steeds in de pas te houden met de bedrijfsprocessen en technische ontwikkelingen zoals nieuwe releases – precies zoals men een lokale infrastructuur door interne beheerders of een beheerpartner zou laten beheren;
• Belangrijker nog: nu we in toenemende mate kritieke applicaties in de publieke cloud brengen, moeten we dus ook hun beschikbaarheid en performantie gaan monitoren – en dit in veel gevallen zelfs 24×7.

Afhankelijk van het type cloud dat men kiest, is de benodigde mate van zelfredzaamheid groter en daarin loopt de IaaS-variant natuurlijk voorop; men bedient daarbij zelfstandig ook de virtuele infrastructuur, de besturingssystemen applicaties en databases. Kortom; met het inkopen van een publieke cloud bent u er nog niet. Die conclusie brengt me op het volgende onderwerp:

Inpassen van de Publieke Cloud in bestaande processen, technologieën en toolsets

Interactie met het platform
Om een Publieke cloud goed te bedienen, hebben de beheerders veel kennis nodig van de toolset die de leverancier aanreikt (en daarbij: van de werking van het platform in de praktijk).

Veel publieke clouds bieden zowel een webinterface als de mogelijkheid om acties via een Application Programming Interface (API) in te zetten. De webinterface en de daar achtergelegen functionaliteit is voor de meeste beheerders vaak een nieuw kennisgebied.

Integratie met uw bestaande applicaties en toolsets via de API kan stuiten op uitdagingen bij het aanleggen van de onderlinge ‘link’. Natuurlijk moeten API en applicatie met elkaar overweg kunnen, maar het tot stand brengen van de onderlinge communicatie is daarmee nog niet vanzelfsprekend.

Nieuwe tools
Ik heb van heel dichtbij mogen meemaken wat er allemaal bij komt kijken om een Pulieke Cloud-dienst naadloos te integreren met een bestaande organisatie en haar ICT. Ik kan u wel verklappen dat er onverwacht veel aanvullende tools in huis moesten komen (en bestaande tools aangepast) om dát te bereiken! De gevolgen voor Asset Management en monitoring/messaging zullen geen grote verrassing voor u zijn, maar ook de interne bestel- en inkoopprocedures ondergingen flinke aanpassingen.

De Publieke cloud maakt het niet alleen noodzakelijk om vele technische handelingen op een andere manier te verrichten om het maximale uit de cloud te halen… Ook diverse bedrijfsprocessen moesten worden aangepast (iets dat resulteerde in aanpassingen in bestaande voorzieningen en het uitrollen van nieuwe tools en applicaties).

Nieuwe mogelijkheden door een nieuwe technologie of nieuw concept
De Publieke cloud brengt vele nieuwe mogelijkheden en grotendeels komen deze direct voort uit een technologie of concept waarmee de bestaande organisatie nog niet vertrouwd is. Wie bijvoorbeeld voor de Publieke Cloud kiest omwille van de mogelijkheid er enorme databases mee online te zetten, zal zich mogelijk eerst grondig moeten verdiepen in de onderliggende technologieën.

Ik zal dit met een voorbeeld onderbouwen. Kleinere organisaties kunnen hun data en applicaties vaak prima in de cloud zetten met behulp van de bestaande, voorgebakken modules. De grotere organisatie stelt echter meestal aanvullende eisen, waardoor de standaardmodules niet meer voldoen en directere controle over de virtuele infrastructuur nodig wordt. De organisatie heeft dan baat bij een IaaS-oplossing.

Dát betekent echter dat de organisatie zich concepten en technologieën eigen moet maken om de cloud met maximaal effect in te kunnen zetten. In dit voorbeeld ziet de organisatie de voordelen van een NoSQL-database zoals MongoDB (die zich prima thuis voelt in de cloud), maar de beheerders moeten die technologie dan wel feilloos onder de knie krijgen.

Daar komen vrijwel altijd aanvullende kennisgebieden bij. In dit voorbeeld denk ik aan extra technologieën (bijvoorbeeld om backups te kunnen maken van de zeer grote database) en extra concepten (hier: ‘sharding’ en Mongo-clustering dat beduidend afwijkt van traditionele clustering). Dit tezamen kan voor veel interne ICT-organisaties weleens een flinke drempel opwerpen.

Overwegingen bij de wijze van implementatie en beheer
In een aantal gevallen kunnen we een vraagteken zetten bij het inzetten van uw interne ICT-krachten voor dergelijke onderwerpen. De taken die wegvallen als u een Publieke Cloud-dienst bestelt, zijn vooral van infrastructurele aard (hardware, besturingssysteem, etc.). Het inhoudelijke beheer van data en applicaties blijft in veel cloudmodellen echter gewoon bestaan en daar bovenop komen nog de nieuwe, leverancier-specifieke onderwerpen om de cloud deugdelijk te bedienen.

Maar ook hier geldt, dat uw eigen organisatie is die primair zal moeten bepalen wat de ‘juiste’ wijze van implementatie en beheer! Grofweg zijn er drie invalshoeken:…

1) De bestaande operationele ICT-organisatie inzetten

De voordelen spreken voor zich; u heeft een bestaande organisatie en begint dus niet vanaf nul. U gaat daarin wél de nieuwe technologieën moeten inpassen als ook de nieuwe toolsets, processen en de ‘cloud-mindset’. Of dit een werkbaar model is, hangt sterk af van uw type organisatie en haar omvang, de beschikbaarheid van kennis, de mate waarin de organisatie haar traditionele, SysOps-gedreven werkwijze zal kunnen omvormen in een DevOps-gestuurde aanpak, enzovoort.

2) Nieuw, aanvullend Cloud-team opzetten

Hoewel deze optie zeer kostenintensief is, omzeilt u verschillende uitdagingen die uit het voorgaande scenario volgden. Het introduceert echter nieuwe uitdagingen – te beginnen met de tijd die het zal kosten voordat alles goed op de rit staat. Zou een ‘snelle implementatie’ een hoofdcriterium zijn dan is dit scenario natuurlijk geen optie.

Een groot voordeel is dat de bestaande ICT-afdeling zich niet in vele bochten moet wringen om zowel de bestaande infrastructuren te beheren én de cloud erbij te nemen – of zich per direct de cloud-mindset eigen te moeten maken. Vooral de grotere traditionele organisatie (die zich deze optie bovendien eerder kan veroorloven), kan hierin weleens een groot voordeel zien.

Het oprichten van zo’n aanvullend team klinkt alleen eenvoudiger dan het in de praktijk is. U moet de juiste mensen vinden en ze daarna in huis weten te houden. Ook moet u rekening houden met de vertragingen die nu eenmaal volgen uit het opbouwen en inwerken van een nieuw team.

Wat ikzelf als het grootste bezwaar zie, is dat in de ‘cloudhoek’ van ICT de ontwikkelingen elkaar in rap tempo opvolgen. Uw cloudteam moet dat kunnen bijbenen en soms zult u het team, als direct gevolg van zo’n ontwikkeling, zelfs moeten uitbreiden met nieuwe specialisten.

Het zal duidelijk zijn dat geen van de twee scenario’s mij erg bekoort. Dat ligt anders met het hierna volgende alternatief.

3) Extern beleggen van Cloud-implementatie en -beheer

Om met de potentiële nadelen te beginnen: het extern beleggen van de cloudimplementatie- en beheerdiensten verschilt niet fundamenteel van andere vormen van uitbesteden. Als men een dienst inkoopt, zal men de algemene aansturing bijvoorbeeld nog steeds in eigen hand moeten houden, vooraf heel wat sluitende afspraken moeten maken over de verdeling van taken  en verantwoordelijkheden en de geleverde waarde voortdurend moeten afzetten tegen de overeengekomen waarde.

De voordelen zijn deels dezelfde als die van andere uitbesteedde diensten (zoals het afwentelen van risico’s en investeringen en het behalen van de voordelen van schaalgrootte). Specifiek rond het extern laten beheren van cloudplatformen, zie ik bovendien duidelijke aanvullende voordelen.

• Vooral voor de traditionele grotere organisatie geldt, dat een de specialist sneller kan schakelen dan de eigen ICT-afdeling. Deels ‘lift u mee’ op de bestaande, eenvoudige en daarom korte procedures van de  beheerpartner;
• Het specialisme van de externe partij maakt het mogelijk (maar niet per definitie) dat zij goed in staat zal zijn om het aspect van ‘Continuous Development’ te helpen invullen. Onbekommerd door allerlei randtaken, geniet de specialist vaak veel vrijheden die de interne ICT-krachten moeten missen;
• Een specialistische partner is er beter op ingericht om de snelle technologische ontwikkelingen in het eigen vakgebied bij te houden. Door de grotere schaal waarop zo’n partner deze kennis inzet, is hij namelijk in staat om veel meer personen in dienst te houden dan een interne ICT-afdeling dat kan (en zo de kennis veilig te stellen);
• Om dezelfde redenen kan de specialist zich hogere investeringen in tools en kennis veroorloven. Het gaat hier immers om de kerncompetentie van zijn organisatie;
• Partijen die dergelijke diensten leveren, stellen hun propositie vanzelfsprekend af op die van het cloudmodel waarop hun diensten betrekking hebben:

– U zou beslist geen beheerdiensten willen bestellen met een minimale contractduur van drie jaar, als de eigenlijke clouddienst per onmiddellijk opzegbaar is,

– Om dezelfde reden verwacht u van de clouddienstverlener dat ook zijn afrekenmodel een ‘Pay-as-you-Go’-karakter kent (flexibel opschalen en terugschalen, betalen voor een dienst voor zolang de virtuele resource ook echt bestaat, …).

Net zoals u voor traditionele, extern gehoste resources gewoon de nodige kennis als service inkoopt, zou men serieus kunnen overwegen om ook deze specifieke configuratie- en beheerdiensten als dienst af te nemen.

Tot besluit
Het zijn bijzonder interessante tijden waarin we leven. Technologie, bedrijfsvoering en de mens maken sinds de industrialisatie een stormachtige, zelfversterkende ontwikkeling door. Ik ben alvast benieuwd wat de nabije toekomst brengen zal. Wat vindt u? Ik sta open voor uw reacties…

[1] In een later artikel kom ik hier op terug: er zijn diverse oplossingen denkbaar om ook dergelijke organisaties de voordelen van de publieke cloud te brengen.