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.
@AD
klopt dat een eigen omgeving optuigen dwingende redenen moet hebben. Kleine nuance is dat zijn uiteraard ook wel weer te realiseren zijn in tal van schalen en complexiteit wat direct weer invoed heeft op de prijs.
@Jan, Lastig om er een aantal werknemers op te plakken. Sourcingstrategie moet vanzelfsprekend leidend zijn. Wel durf ik te zeggen dat ik private cloud platformen tot op heden bij de grote bedrijven tegen ben gekomen en dan praten we over minimaal enkele duizenden medewerkers.
@Ewout,
Kunnen shoppen, maar duidelijk binnen gekaderd aanbod. Voor IaaS/PaaS zijn dit niet eindgebruikers (tenzij je over een software bedrijf of dergelijks praat) maar veelal applicatie owners, developers of eigen IT verantwoordelijke.
en ook hier, van uw vraagt wij draaien naar “gekanaliseerd” kunnen shoppen is ook al weer een hele stap.
Jeroen, geweldige interactie en dank voor je antwoorden op mijn vragen! Een aantal jaren geleden vroeg ik of de Azure Fabric Controller, of het Azure OS ook zelf geïnstalleerd kon worden op eigen hardware. Het antwoord wat ik toen kreeg is dat ze dat gedaan hadden voor Fujitsu, maar dat het er voorlopig niet zou komen… Nu zeg je Windows Azure Pack (wanneer gaan ze dat Microsoft Azure Pack noemen? 🙂 ).
Ik kende deze smaak helemaal niet! Geweldig, en ben me meteen aan het inlezen. Het klinkt als een vrij frontale aanval op OpenStack en in ieder geval een goede zet van Microsoft.
Reza, in mijn laatste artikel schreef ik al over dat cloud computing een vaardigheid is, wat Jeroen schrijft is daar een prima voorbeeld van hoe een organisatie zelf cloud computing realiseert.
Ik heb geen enkel bezwaar tegen het realiseren van een eigen intern cloud platform waarbij het bedrijf gewoon eigenaar is van al het ijzer. Uiteraard heeft dat wel impact op je capex opex verhaal en mis je bepaalde voordelen van IT simpel maken en doe je zelf ook alle beveiliging en updates. Voor een groot bedrijf is dit echt wel een goede propositie. Ook zal later als je publieke diensten wil omarmen er eigenlijk weinig veranderen aangezien je intern ook al gewend bent om te denken in API’s en webservices.
Het enige gevaar wat ik zie is dat je een laag met complexiteit toevoegt (je cloud os), maar dat de mensen zelf traditioneel tegen virtuele servers aan blijven kijken met dito beheer. En op dat moment verlies je veel van de voordelen.
Stel een groot bedrijf moet zijn capaciteit bijschakelen. In theorie is dat een rack bijplaatsen, de hypervisors en Cloud OS installeren (zodat deze aware is van nieuw ijzer) en BAM, je kunt verder. Hiermee maak je dus je IT infrastructuur schaalbaar en kom je in een mindset van standaardiseren.
Ik kan me dus goed vinden in Jeroen zijn reactie en uiteraard zijn er ook wel tegens te verzinnen en is het meer dan alleen een stukje techniek, de (IT) organisatie moet ook mee willen en kunnen.
@Felix
Ben ik een scepticus als ik door ervaringen wat wijzer geworden ben?
Ik heb jaren geleden geleerd dat organisaties doelen en bedrijfsmiddelen hebben maar ik krijg steeds vaker het idee dat dit omgedraaid is. Misschien komt dit wel doordat gedacht wordt dat als je een hamer hebt ook direct een timmerman bent. Nu blijkt dat de spijkers ook nog weleens krom geslagen worden komt er langzaam weer steeds meer aandacht voor de oude discipline van informatie- en beveiligingsmanagement, wat dus best lastig is als je geen zicht (CM) meer hebt op je bedrijfsmiddelen door hypes als BYOD en DIY.
CIA principe is trouwens gewoon ook een model hierin dat als basis dient voor governance framewerken zoals CSA matrix (CCM) en ISO-IEC 27017/18. Betreffende de opmerking om beheer te normaliseren (commoditizen) verwijs ik met name naar initiatieven van dit soort organisaties. Vertrouwen is goed maar controle is beter want over de integriteit van de keten valt nog wel wat te vragen terwijl het auditen ervan dus steeds lastiger wordt. Zie wat dat betreft een oude presentatie:
http://docbox.etsi.org/workshop/2012/201201_SECURITYWORKSHOP/3_INTERNATIONAL_STANDARDIZATION/EMC_CSA_POHLMANN.pdf
Dat SAP-er-de-flap de ACM nu externe klokkenluiders nodig heeft om corruptie en fraude binnen de overheid op te sporen geeft wel aan dat je exception- en exemption management hebt. Auteur heeft het over shoppen binnen een gekaderd aanbod waarbij ik alleen maar de vraag stel wie dat aanbod dan kadert want soms is het antwoord op de waarom gewoon een daarom. En ik geloof best wel in Cloud principes maar om heel anderen reden dan Henri want centralisatie van data is niet veel anders dan de beweging die we eerder al zagen met centrale fileservers in PC netwerken.
“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.” – Albert Einstein.