Strategische adoptie van public-clouddiensten staat voor geen enkele CIO meer ter discussie. Echter wanneer een organisatie weer voor het vraagstuk staat de vijfjaarlijkse grote herinvestering te doen in het corporate datacenter, wat is dan wijsheid? Wanneer is gaan voor 100 procent cloud en een datacenter-exit haalbaar? En wat zijn nu interessante workloads voor de public cloud? Edwin van Nuil en Jeroen Jacobs verwoorden hun vanuit de praktijk opgebouwde visie op dit vraagstuk.

Het periodieke datacenter-herinvesteringsvraagstuk kan vandaag de dag niet meer beantwoord worden zonder zorgvuldig de afweging met public cloud te maken. Recent maakte Barclays Bank in dit kader zijn drijfveren achter de all-in public-cloudaanpak bekend. Voor de bank is public cloud het instrument om in te kunnen spelen op het ‘ever-changing financial service landscape’. Inmiddels zijn er ook vergelijkbare cases van andere enterprises en hebben wijzelf een aantal organisaties bij hun datacenter-exit naar Amazon Web Services mogen transformeren. Toch moet datacenterexit niet een doel op zich zijn als daar geen heldere cloud-business drivers aan ten grondslag liggen.

Heldere cloud drivers

Het strategisch stellen van richtinggevende drijfveren voor adoptie van public cloud is key. Grofweg zien we enterprises twee primaire argumenten aangrijpen voor de adoptie van public-cloudplatformen. De eerste reden is kostenbesparing dan wel kostenflexibiliteit. De andere is innovatie en snelheid van innovatie. Security/compliancy-verbetering wordt soms als bijkomende driver genoemd en specifiek bij SaaS-diensten komt de user experience en inventievere way of working ook nog vaak naar boven. Toch kan de afweging soms ook wat minder strategisch zijn en betreft het gewoon een operationeel of acuut probleem dat praktisch wordt opgelost door transitie naar public cloud. Bijvoorbeeld wanneer een organisatie gedwongen wordt op korte termijn het datacenter te verlaten of een IT-ontvlechting te doen omdat een organisatieonderdeel is verkocht.

Cloud-based IT-landschap

In figuur 1 (Cloudgebaseerd IT-landschap) staan links de specifieke applicatieworkloads, zowel custom hosted als custom developed applications. Hiermee bedoelen we ook standaardapplicaties die specifiek voor een organisatie worden gehost in een afgeschermde omgeving. Vooral eigen ontwikkelde applicaties zullen meer en meer gebruikmaken van PaaS-services. Custom hosted zullen in de praktijk vaak nog de legacy-applicaties zijn.

Figuur 1. Cloudgebaseerd IT-landschap

In het midden hebben we bovenin de user interface die bij voorkeur web- en api/app-enabled is. Daaronder identity as a service waarbij secure access, single sign-on en account provisioning naar SaaS-services gecontroleerd plaatsvindt. Het cloud-identityplatform wordt ook de toekomstige primaire identity repository voor de organisatie.

Tot slot voorzien wij nog een data-integratielaag die we integration as a service noemen. Tussen SaaS-services loopt dit via api’s, en met/naar custom hosted applications kan dit nog deels met traditionele protocollen zijn. De integraties zien wij vooral serverless gerealiseerd (AWS Lambda, Google Functions) of met oplossingen die prebuild integraties of integratie hub-services aanbieden.

“Het is aan te raden per applicatie de afweging te maken”

In de weergave van figuur 1 is de traditionele datacenter-stack niet weergegeven, maar uiteraard zouden we die links ernaast kunnen positioneren in de periode dat we over een hybride cloud spreken. Gebaseerd op deze landschapsplaat kan men gaan projecteren welke applicatiefunctionaliteit waar onder te gaan brengen op de korte en de middellange termijn. Dit noemen we application mapping.

Application mapping

Een datacenter-vervangingsinvestering kan een enorme versnelling brengen in de transformatiebeweging naar public cloud. Toch is het aan te raden (zelfs bij een full datacenter-exit) per applicatie de afweging te maken. De mapping vanuit de applicatie start ook de discussie over welke cloud(s) wenselijk is/zijn in het landschap en waar opgeschoond of ‘ver-SaaS’t’ kan worden. De cloud-migratiestrategieën die Amazon Web Services en Gartner 6R-model noemen, zijn hierbij een door ons veel gehanteerd model. Dit model pakt de kern met migratieopties die er zijn, te weten:

Retain

Het behouden van de applicatie in de huidige vorm op het huidige platform. Dit zien we vooral voorkomen als de applicatie on-premise moet blijven.

Retire

Het uitfaseren van de applicatie. Gaat veelal om applicaties die eigenlijk nauwelijks nog gebruikt worden en alleen nog voor raadpleging aanstaan. De data archiveren (op de cloud) is vaak voldoende.

Rehost

Het letterlijk overbrengen naar een ander public-cloud-hostingplatform. Dit komt neer op het ‘lift en shift’ migreren naar IaaS, soms met een managed database of managed fileshares als dienst. Bij een snelle datacenter-exit is dit de snelste route.

Replatform

Is het daadwerkelijk vervangen van componenten. Bijvoorbeeld MySQL vervangen voor AWS-Aurora.

Refactor

Komt alleen voor bij eigen ontwikkelde software. Dit betreft het herontwikkelen met nieuwe softwarecode passend bij de cloud-native uitgangspunten.

Repurchase

Opnieuw aanschaffen van de softwarefunctionaliteit. In de cloudtransitie betreft dit vervangen door SaaS-alternatieven.

Zowel vanuit de cloudbusinessdrivers, de applicatieroadmap en de architectuur als vanuit het financieel perspectief, wordt elke applicatie zorgvuldig tegen de opties aangehouden en de gewenste to-be-situatie besloten. Wanneer de totale inventarisatie is gedaan, is de basis voor het cloudtransitieplan gemaakt.

Ideale workload voor cloud

Public-cloudplatformen kunnen praktisch alle hedendaagse applicaties hosten (als lift en shift), de ene applicatie benut echter beter de voordelen van public cloud dan de andere. Onder mogelijke first movers vallen onder meer vaak sandbox en training of tijdelijke omgevingen. Traditioneel staan die omgevingen dag en nacht aan. Op public cloud kunnen deze systemen snel en eenvoudig met scheduling uitgezet worden buiten kantooruren. In pay-per-usemodellen levert dit enorme kostenvoordelen op.

Een andere quick win zijn publieke corporate webapplicaties/websites. Public cloud is uitermate geschikt om websites te hosten en biedt dan ook out-of-the-box allerlei interessante add-ons zoals loadbalancing, anti-DDoS of Content Delivery Network die een webapplicatie aanzienlijk kunnen verbeteren. Bovendien zien veel organisaties het ook als een securitywinst niet meer in de eigen DMZ te hosten.

Een derde interessante usecase is cloud gebruiken als storage-extensie. Zowel voor back-up als archiefstorage bieden public-cloudplatformen zeer scherp geprijsde en highly durable storage waarbij ook nog appliances meegeleverd worden om te integreren in het bestaande datacenter. Tot slot zijn scriptservers ook quick wins. Met relatief kleine aanpassingen kunnen simpele platform-automationscripts vaak serverless gerealiseerd worden.

Buiten de quick wins zijn vooral workloads interessant die echt voordeel halen uit de specifieke eigenschappen van de cloud. Dit hoeven niet direct full cloud-native designed apps te zijn, maar kan al simpelweg een databaseomgeving zijn die als PaaS-dienst afgenomen wordt of high available wordt gemaakt door de HA-failover feature aan te zetten.

“Zelfs met een lift- en-shiftaanpak is de businesscase rond te krijgen”

Ook applicaties die voordeel hebben van de global presence van een cloudplatform zijn interessant. De grote publieke providers stellen enterprises in staat om in regio’s over de gehele wereld applicaties te deployen. Applicaties die primair in Azië gebruikt worden, hoeven bijvoorbeeld niet meer in het corporate datacenter in Europa te draaien en daarmee kan de latency worden teruggebracht. Schaalbare piek- en batch-workloads zijn interessant.

Schaalbaar kan al werken voor veel applicaties die achter een load balancer zitten. Cloudplatformen zijn met die gedachten gebouwd. Tot slot hebben we de categorie waar echt native features van het platform kunnen worden ingezet. Denk hierbij niet alleen aan big data, analitycs of IoT-workloads, maar ook aan vervanging van bestaande, zelf te beheren oplossingen voor managed VDI of AppStream-functionaliteit.

Datacenter-exit of niet?

De vraag datacenter-exit of niet, moet initieel worden beantwoord vanuit de clouddrivers. Als de drijfveer puur innovatie is, wordt datacenter-exit een minder relevante afweging. Als de afweging kostenbesparing is, dan is het maken van de rekensom de moeite waard. Wel is het belangrijk in de kostenvergelijking echt naar de TCO te kijken.

In figuur 2 geven we een voorzet welke datacenterkostenelementen (groen) wegvallen in de IaaS-prijs. Ook is 20 procent rightsizing van de bestaande servercapaciteit niet onrealistisch en een besparing die meegenomen kan worden. Lukt een full exit niet, kijk dan of er in ieder geval geclusterd kan worden. Een specifieke datacenter-netwerkzone uitfaseren bespaart naast serverkosten ook netwerkapparatuur en beheer. Of richt je op een functioneel gebied zoals bijvoorbeeld een back-upoplossing of VDI-omgeving.

Figuur 2. IaaS TCO cost elements (groene vlakken vallen weg in de IaaS-prijs bij public-cloud providers)

Datacenterless in de praktijk

Na meerdere datacenterexits gerealiseerd te hebben kunnen we stellen dat zelfs met een lift-en-shiftaanpak de businesscase rond te krijgen is. Rightsizing en het meenemen van kleine voor de hand liggende verbeteringen wordt hierbij wel geadviseerd. Voor kleinere organisaties is een datacenter-exit een aanzienlijk eenvoudiger en meer voor de hand liggende stap dan voor grote ondernemingen. Zeker in enterprise-context benadrukken we dat er echt vanuit applicatieperspectief de afweging gemaakt dient te worden.

Het blijft vervolgens een periodiek proces om vanuit de applicatiearchitectuur naar het cloudplatform te blijven optimaliseren. Tot slot willen we nog benadrukken dat het beheer van een cloudplatform via infrastructure as code andere skills vraagt dan het beheer van traditionele datacenterstacks. Eerder schreven we reeds onze visie hierop in een stuk over het cloud center of excellence.

Edwin van Nuil is managing director en Jeroen Jacobs is cloudconsultant & projectmanager bij Oblivion Cloud Control.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter