Publieke IaaS/PaaS-cloudoplossingen passen niet altijd in de hedendaagse it-sourcing-strategie. Hierdoor overwegen en investeren veel organisaties in een eigen private cloud-platform. Het succesvol neerzetten van een eigen cloud-platform is echtergeen sinecure. In dit artikel zet ik vier essentiële stappen om succesvol naar een company private cloud-platform te bewegen.
1. De sourcingpuzzel – De waarom vraag
Een company private cloud-platform bouwen is geen doel op zich, maar logischerwijs een opvolging vanuit een gefundeerde sourcing-strategie. Hieruit blijkt bijvoorbeeld dat bepaalde applicaties niet optimaal passend zijn op de public cloud maar wel behoefte hebben aan de kenmerken van cloud. Een handige tool om de sourcing-puzzel te ondersteunen is bijvoorbeeld het Smartbuying grid.
Door de concrete aanleiding voor een private cloud platform helder voor ogen te hebben, kunnen keuzes, in termen van functionaliteit, techniek en omvang (ook wel solutiondesign genoemd), gericht gemaakt worden. Het scheelt nogal of de private cloud een noodzakelijke tijdelijke oplossing is voor enkele te migreren legacy applicaties of een doel-platform voor de komende vijf+ jaar wat geschikt moet zijn voor cloud aware apps. Het is belangrijk verder vooruit te kijken om te weten welke high level requirements in de toekomst vereist worden. Sommige keuzes die gemaakt worden hebben immers impact voor jaren. Denk onder meer aan de technologiekeuze van het platform.
2. Start klein – Het invullen van het hoe
Met de sourcing-strategie concreet voor ogen, zijn er direct één of meerdere applicaties aan te wijzen die op het platform moeten gaan landen. Omarm een dergelijke applicatie en start het project met een pilot. Door in een pilot een eindklant als startpunt te nemen, is er direct een sponsor en wordt de platformrealisatie ingezet op concrete praktische toepasbaarheid.
Een van de grote valkuilen bij de realisatie van private cloud platformen is te veel complexiteit ineens en teveel abstractie. Snel een werkend platform in de lucht brengen dat de problemen van vandaag oplost, is een cruciale stap en resulteert in een succesvolle uitrol met een interne olievlekwerking. Na de initiële pilot kan in iteraties applicatie voor applicatie opgepakt worden.
Naast het starten met een gefocuste pilot is ook een functionele focus aanbevelenswaardig. In vrijwel elke organisatie is bij een private cloud-platform behoefte aan basis IaaS-functionaliteit. Zelfs als de sourcing-strategie wijst naar geavanceerde PaaS is basis IaaS uitermate geschikt als startpunt. Het spreekt voor de meeste eindklanten tot de verbeelding en is vaak al een serieuze verbetering ten opzichte van klassieke server provisioning (tip: meet de tijd eens tussen aanvraag van een server en het uitleveren aan de aanvragen). Daarnaast stelt het relatief lage migratie-eisen aan bestaande applicaties en is IaaS in de private cloud wereld redelijk volwassen. PaaS daarentegen is veel minder eenduidig en heeft veel meer impact tot op zelfs code level van de applicaties zelf.
3. Catalogus – Antwoord op wat geleverd gaat worden
Een private cloud vereist een strak samengestelde menukaart c.q. catalogus. Automatisering, self service, schaal-uitnutting, snelheid en uniforme metering vereisen simpelweg een verregaand gestandaardiseerd aanbod. Dit betekent keuzes maken in configuraties die wel en niet worden aangeboden. Denk bijvoorbeeld aan welke besturingssystemen, virtuele server configuraties, additionele software en services worden aangeboden en tegen welke service levels. Vanuit de pilot is een eerste aanzet voor de catalogus gerealiseerd. Bij het onboarden van volgende applicaties ontstaan steeds weer nieuwe inzichten en dienst- en feature-behoeften. Voor ontwikkeling van nieuwe features en diensten is werken in releases (via Scrum) en het opzetten van een release planning aan te bevelen.
Bij het bepalen van de catalogus en de menu items: start ook weer klein. Start met een eerste versie en definieer op basis van input van eindgebruikers de releases voor zowel aangeboden diensten als platform en portal-features. Hier helpt de 80/20-regel. Focus op de gemene deler en spendeer in het begin niet teveel tijd aan de uitzonderingen. Werp later nog eens een kritische blik op de uitzonderingen en meestal blijkt dat een groot deel alsnog binnen de gestandaardiseerde opties past. IaaS/PaaS providers als Azure en Amazon hebben immers ook maar een beperkt aantal opties en veroveren met hun diensten in snel tempo de markt.
Neem ook direct in de eerste catalogus-versies service levels en kpi’s mee en dan vooral die weergeven waar de platform-afnemers vandaag de dag last van ondervinden. Denk aan klassieke pijnpunten als levertijden en flexibiliteit.
4. Platform productmanagement – assembleer
Als de catalogus staat en het platform in een tweede release ontstaat, wordt de productmanagement-rol belangrijk. Het volmaken en onderhouden van de catalogus vereist een strakke productmanagementrol voor het cloud platform. Productmanagement maakt steeds de afweging tussen vraag en gestandaardiseerd aanbod. Dit vereist een omslag in denken in termen van halffabricaten/it-bouwstenen in plaats van ‘u vraagt wij draaien’. Ook hier zijn in de public cloud succesvolle voorbeelden als Netflix. Netflix maakt zich weinig druk om de infrastructurele laag die volledig wordt ingekocht/geassembleerd als dienst bij Amazon en vertrouwt op deze standaard bouwstenen.
Essentieel is, zeker bij zwaar gestandaardiseerde diensten, om in contact te blijven met je klant, te blijven kijken naar nieuwe technische mogelijkheden en inspiratie te putten uit de ontwikkelingen bij de grote public cloud-providers.
Resume
Het optuigen van een company private cloud platform is zeker niet makkelijk. Met deze stappen in het achterhoofd doorloop je een nuttig leerproces voor de organisatie.
Start met een heldere waarom vanuit de sourcing-strategie, sprint door met Scrum naar een snel concrete hoe in een pilot, met wat je biedt gestructureerd en groeienderwijs ’te koop’ in je eigen catalogus. Assembleer van hieruit verder. Kortom: geef je eindgebruiker het gemak van shoppen in jouw it-cloud.
Dag Jeroen, leuk artikel met handvatten en losjes gebaseerd op Simon Sineks boek “Start with why”.
Wel een paar belangrijke vragen in dit kader:
– Wat is (een) private cloud?
– Hoe maak ik dan een private cloud (platform)?
– Hoe realiseer ik zelfbediening in zo’n private cloud?
– Welke applicaties passen niet op een public cloud, maar wel op een private cloud en waarom?
Hi Jeroen,
1- Mooi om gelijk met een dienst van je werkgever binnen te stappen (Smartbuying grid) Maar laten we ons concentreren op je artikel.
2- Bij het lezen van je artikel was het me niet duidelijk of je dat voor je klant (dus de afnemer) hebt geschreven of voor de leverancier! Deze zijn twee verschillende invalshoeken.
Verder kreeg ik het gevoel dat je soms private cloud en outsourcing door elkaar hebt gegooid!
3- Als je het over Cloud als deliverymodel hebt dan zou je aan een aantal voorwaarden moeten voldoen. Een voorbeeld hiervan is je applicaties. Deze moeten cloud-ready zijn. Dus legacy meenemen naar nieuwe deliverymodel lijkt me niet verstandig.
Het lijkt me interessant een artikel van je te lezen over waarom je denkt dat publieke IaaS/PaaS-cloudoplossingen niet altijd in de hedendaagse it-sourcing-strategie passen! Wanneer kan ik als klant naar deze diensten kijken en wanneer niet.
– Private cloud in kader van dit artikel is een voor de organisatie zelf gerealiseerd cloud hosting platform. Dus niet private cloud volgens termen zoals publieke aanbieders die soms hanteren, maar echt een eigen installatie van bijvoorbeeld Microsoft Azure Pack onder eigen architectuur en eigen catalogus.
– Een Private cloud platform realiseer je met een oplossingen zoals bijvoorbeeld Openstack, MS Systemcenter/ Azure pack etc en dan onder eigen architectuur en eigen catalogus aanbod.
– Self Service / portal functionaliteit zitten in veel cloud platform oplossingen (zoals Azure pack) al standaard in. Indien niet, dan is het zelf bouwen tegen de beschikbare API’s aan.
– Applicaties niet geschikt is beter te interpreteren als: niet optimaal voor de public cloud. Vaak kan de applicatie technisch wel in de public cloud, maar is het beter om het op een eigen platform te hosten. Dit bijvoorbeeld omdat:
a) De cloud provider niet voldoet aan het security, compliancy of datalocatie beleid van de organisatie.
b) De kosten op een private cloud goedkoper zijn dan public. Public cloud is zeer interessant als je gebruik kunt maken van schaling en dynamiek. Voor hosten van klassieke applicaties is prijs zeker niet vanzelfsprekend interessanter.
(Overigens bij prijsvergelijking eigen private cloud of klassieke hosting vs publieke cloud is appels met appels vergelijken erg belangrijk en dient zeker niet op VM level maar meer op applicatie TCO worden getoetst)
c) Als de organisatie nog niet klaar is om vol op public cloud in te zetten maar toch een stap in die richting wil zetten.
d) Zeer extreme applicaties zijn in de zin van performance, capaciteit, of technische middelen (Bijvoorbeeld type OS wat niet supported is bij public aanbieders of bepaalde bijzondere interfaces / PLCs etc)
e) …
@Reza
1. 😉 –> Echter serieus een handige onslider om over de sourcing-strategie van je IT te praten.
2. Afnemer –> Organisaties die een eigen cloud platform willen optuigen.
3. Eens, athans, zeker niet mee beginnen… later kijken hoe het alsnog kan al dan niet met beperkte aanpassingen.
Leuk idee om inderdaad eens iets te publiceren als “Wanneer je de cloud vermijden moet.” Ga ik over nadenken.
Jeroen,
Je artikel vond ik matig maar je reactie vind ik ZEER interessant!
Je komt in je 1e reactie met een aantal beweringen waardoor je 250 jaar celstraf van Henri zou krijgen!
– Bij Cloud denk ik aan bevrijd worden van beperkingen (als ik mensen zoals Marco Gianotten mag geloven!), eenvoudig afnemen van diensten die ik niet snel en GOEDKOOP kan krijgen, ontzorgd zijn etc etc
En jij komt met je voorstel om private cloud op te tuigen?
– Henri beweert (als ik me niet vergis Henri) dat investering in eigen ijzer en de benodigdheden geld verspillen is als je dat vergelijkt met het afnemen van Cloud(diensten)
En jij komt met je voorstel om private cloud op te tuigen? (punt b)
– Ik vroeg of je dit artikel voor afnemers of voor leveranciers hebt geschreven. Antwoord: afnemers!
Hoeveel afnemers denk je kennis in huis te hebben van de zaken die je benoemd hebt? Het lijkt me geen juiste doelgroep dus.
– […] punt C: Als de organisatie nog niet klaar is om vol op public cloud in te zetten maar toch een stap in die richting wil zetten […]
Heb je nagedacht over de benodigde investering om dit te realiseren vs investering in je organisatie om die Cloud ready te maken?
De bovenstaande zaken in huis realiseren betekent voor me een investering voor circa komende 5 jaar! Zou dit verstandig zijn in deze tijd van enorme ontwikkelingen en prijsdaling bij aanbieders zoals Microsoft, AWS, Google etc?
Misschien heb je ook gelijk, Cloud is helemaal niet zo voordelig als sommige mensen het beweren!
Als dit waar is dan kan Computable flink aantal Cloud-artikelen op deze site met marketingspraatjes over voordeligheid van cloud, verwijderen 🙂
En nogmaals als dit waar is dan heb jij een groot conflict tussen twee groepen (Cloud Linkse en Rechts partijen) in een keer opgelost!
Je verdient de Nobelprijs voor de vrede 🙂
Je noemt een paar goede voorbeelden waar een private cloud als omgeving op zijn plek kan zijn. Toch bekruipt me weer het gevoel dat je wel heel dwingende redenen moet hebben om je eigen cloud omgeving op te gaan tuigen. De cloud is immers voor een belangrijk deel zo nuttig omdat het je organisatie qua ICT kan ontzorgen? En kun je echt tegen vergelijkbare tarieven (blijven) bieden wat grote aanbieders in de public cloud bieden (zelfs al gebruik je ‘dezelfde spullen’ zoals bij MsAzure Pack)? Mooi onderwerp misschien om nog eens in te gaan op wat nou de belangrijkste voors en tegen zijn binnen een “gefundeerde sourcing-strategie”.
Korte vraag Jeroen.
Vanaf welke schaalgrootte ongeveer (aantal medewerkers) zou je voor een private cloud kiezen wanneer we uitgaan van een weinig dynamische omgeving.
Bezint eer ge begint is een goede practice maar laat ik beginnen met het einde, waarom zouden eindgebruikers moeten kunnen shoppen in de al dan niet eigen IT cloud?
Wordt middel niet tot doel verheven en leidt juist dat niet tot meer complexiteit, hogere kosten en uiteindelijk een lagere productiviteit?
In een eerder opinie ‘De cloud op maat gemaakt’ stelde ik dat er 3 assen zijn: techniek, functionaliteit en beheer. En de eindgebruiker blijkt meestal niet in staat om het beheer te doen terwijl beheer dus het inzicht geeft in de IT die een organisatie op strategisch en operationeel gebied ondersteunt.
Typerende reacties ook weer, hoezo is de cloud goedkoper als je geen weet hebt van wat het nu allemaal precies doet, kost en opbrengt?
Misschien dat een Smartbuilding grid een betere optie is want in de sourcing keuzen mis ik een aantal hedendaagse ontwikkelingen. Beter om eerst het beheer te ‘commoditizen’ want techniek is al jaren vervangbaar en functionaliteit vanuit perspectief van eindgebruikers meestal dus niet kostenverlagend en/of productieverhogend.
‘Men kan evenmin iets goeds voortbrengen door ’t volgen van modellen, als zich voeden met de spijs die ’n ander gegeten heeft.’ – Eduard Douwes Dekker
@Ewout,
Jouw reactie betreffende doel en middel is ook typerend.
Voor jou staat CIA voor Confidentiality, Integrity en Availability. Eisen waaraan een oplossing voor een willekeurig probleem minimaal moet voldoen. Voor believers staat staat CIA voor Cloud, Innovation and Agile. Daar waar de oplossing zou liggen voor ieder willekeurig probleem. Dat geloven ze nu eenmaal.
Believers richten zich alleen op bevestiging van een stelling, maar skeptici als jij proberen steeds gaten te schieten. Maar je weet vast wel wat Einstein ooit zei over ‘doing the same thing and expecting different results’
@Reza,
Eens en voor de duidelijkheid, ik ben ook absoluut voorstander van clouddiensten met alle onzorging, snelheid etc.
Echter ook in alle realiteit zijn er nog organisaties genoeg die daar nog niet klaar voor zijn of zeker niet voor het gehele IT landschap.
Afnemers als doelgroep ja. Dat in house kennis waarschijnlijk tekort schiet is herkenbaar, maar dat wil niet zeggen dat afnemers alles zelf doen. Bouw kan uitbesteed worden en beheer en innovatie ook. Echter blijft wel belangrijk dat keuzes die gemaakt worden hierin blijven aansluiten bij de sourcingstrategie. Waarom zou je dan nog voor een dergelijke oplossing gaan als je alles uitbesteed? Simpel, de meeste argumenten als meer eigen regie of datalocatie etc gaan nog steeds op.
Eens een eigenplatform is zeker niet goedkoop. echter komende vanuit veelal nog klassieke hosting is de tussenstap naar een private platform voor veel organisaties al een enorme winst.
En ja over de prijs van public… daar roep ik ook over vergelijk appels met appels en dat is lastig. klassieke IT kent ook immers enorm veel indirecte en verborgen kosten. Anderzijds zijn er toch regelmatig cases waarbij public cloud niet altijd het voordeligst blijkt te zijn. (zie ook mn publicatie cloud wordt volwassen. https://www.computable.nl/artikel/expertverslag/cloud_computing/5115321/2333364/cloud-wordt-volwassen.html ) – Misschien wordt de onverwachte cloud businesscase mn volgende artikel …