Datacenter exit, Enter the Public Cloud

Strategische adoptie van public clouddiensten staat voor geen enkele CIO meer ter discussie. Echter wanneer uw organisatie weer voor het vraagstuk staat, de vijf jaarlijkse grote herinvestering te doen in het corporate datacenter, wat is dan wijsheid? Wanneer is gaan voor 100% cloud en een Datacenter exit haalbaar? En wat zijn nu interessante workloads voor de public cloud? Edwin van Nuil en Jeroen Jacobs brengen in dit artikel hun, vanuit 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 hun drijfveren achter de all-in public cloud aanpak bekend. Voor hen is public cloud het instrument op in te kunnen spelen op het “ever-changing financial service landscape”. Inmiddels zijn er ook vergelijkbare cases van andere enterprises en hebben wij zelf een aantal organisaties in hun datacenter exit naar Amazon Web Services mogen transformeren. Toch moet datacenter exit niet een doel op zich zijn als daar geen heldere cloud-businessdrivers aan ten grondslag liggen.  

HELDERE CLOUD DRIVERS

Het strategisch stellen van richtinggevende drijfveren voor public cloud adoptie is key. Grofweg zien we enterprises twee primaire argumenten aangrijpen voor adoptie van public cloudplatformen. De eerste reden is kostenbesparing, danwel kostenflexibiliteit. De andere is innovatie en snelheid van innovatie. Security/Compliancy verbetering wordt soms nog als bijkomende driver genoemd en bij SaaS diensten specifiek komt 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 wat praktisch door transitie naar public cloud wordt opgelost. Bijvoorbeeld wanneer u op korte termijn gedwongen wordt het huidige datacenter of te verlaten of een IT-ontvlechting te doen omdat een organisatie onderdeel is verkocht.

CLOUD BASED IT LANDSCHAP

Nadat de clouddrijfveren helder zijn, kan een vertaling worden gemaakt naar het beoogde landschap. Centraal hierbij staat welke IT-platformen de applicatiefunctionaliteit en applicatiehosting moeten gaan ondersteunen. In figuur 1 schetsen we ons beeld op het IT-Cloudlandschap voor een gemiddelde Enterprise.  Rechts in de figuur projecteren we de SaaS applicaties als Office365, Gsuite, Salesforce maar ook sector specifieke SaaS oplossingen. Al jaren transformeren softwareleveranciers naar een SaaS model en ook meeste organisaties adopteren SaaS bij vervangingsinvestering indien voorhanden. Deze SaaS applicaties worden, nu al, vaak door de SaaS providers gehost op de grote publieke cloudplatformen als Amazon Web Services of Google, wat in de figuur de onderlaag is.

Figure 1 - Cloud gebaseerd IT Landschap

Figure 1 - Cloud gebaseerd IT Landschap

Links in het plaatje staan de specifieke applicatieworkloads, zowel Custom hosted als Custom developed applications. Hiermee bedoelen we ook standaardapplicaties die specifiek voor uw organisatie worden gehost in een afgeschermde omgeving. Vooral eigen ontwikkelde applicaties zullen meer en meer gebruik maken van PaaS services. Custom hosted zullen in de praktijk vaak nog de legacy applicaties zijn. In het midden hebben we bovenin de userinterface welke bij voorkeur Web & API/APP enabled is. Daaronder Identity-as-a-Service waarbij secure access, single-sign-on en accountprovisioning naar SaaS services gecontroleerd plaatsvindt. Het cloud identityplatform wordt ook de toekomstige primaire identity repository voor de organisatie.

Tot slot voorzien wij nog een dataintegratielaag die we Integration-as-a-service noemen. Tussen SaaS services loopt dit via APIs 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.

In de weergave 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 kunt u gaan projecteren welke applicatiefunctionaliteit waar onder te gaan brengen op korte en op middellange termijn. Dit noemen we application mapping. 

APPLICATION MAPPING

Een datacentervervangingsinvestering kan een enorme versnelling brengen in de transformatiebeweging naar public cloud, echter adviseren we (ook bij een full datacenter exit) toch per applicatie de afweging te maken. De mapping vanuit de applicatie start ook de discussie over welke cloud(s) wenselijk zijn in het landschap en waar opgeschoond of verSaaSed kan worden. Een door ons veel gehanteerd model hierbij zijn de cloudmigratiestrategieën die Amazon Web Services en Gartner 6R-model noemen. Dit model pakt  de kern met migratieopties die er zijn te weten:

  • Retain: Het behouden van de applicatie in huidige vorm op het huidige platform. Dit zien we vooral voor komen als de applicatie on-premise moet blijven.

  • Retire: Het uitfaseren van de applicatie. Veelal applicaties die eigenlijk nauwelijks nog gebruikt werden en alleen nog voor raadpleging aanstonden. 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 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 software code passend bij de cloud-native uitgangspunten.

  • Repurchase: Opnieuw aanschaffen van de softwarefunctionaliteit. In de cloudtransitie betreft dit vervangen voor SaaS alternatieven.

Zowel vanuit de cloudbusinessdrivers, de applicatieroadmap en architectuur, als 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 cloudtransitie plan gemaakt. 

IDEALE WORKLOAD VOOR CLOUD

Public cloud platformen kunnen praktisch alle hedendaagse applicaties hosten (als lift en shift), echter benut de ene applicatie beter de voordelen van public cloud dan de andere. Onder mogelijke first movers vallen ondermeer 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-use modellen 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 welke uw 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 backup als archiefstorage bieden public cloud platformen zeer scherp geprijsde en highly durable storage waarbij ook nog appliances meegeleverd worden om te integreren in het bestaande datacenter. Tot slot in de quick-wins zijn scriptservers. 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 cloudnative 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. Ook applicaties die voordeel hebben van de global precense van een cloudplatform zijn interessant. De grote publieke providers stellen enterprises in staat om in regios 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 latency performance worden verbeterd. 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 bijvoorbeeld 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 kostenvergelijk echt naar TCO te kijken. In Figuur 2 geven we een voorzet welke datacenter kostenelementen (Groen) wegvallen in de IaaS prijs. Ook is 20% 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 op een functioneel gebied zoals bijvoorbeeld een backupoplossing of VDI-omgeving.

Figure 2 - IaaS TCO cost elements (Groene vlakken vallen weg in de IaaS prijs bij public Cloudproviders)

Figure 2 - IaaS TCO cost elements (Groene vlakken vallen weg in de IaaS prijs bij public Cloudproviders)

DATACENTERLESS IN DE PRAKTIJK

Na meerder datacenter exits gerealiseerd te hebben kunnen we stellen dat zelfs met een lift en shift aanpak de businesscase rond te krijgen is. Rightsizing en kleine voor de hand liggende improvements meenemen, wordt hierbij wel geadviseerd. Voor kleinere organisaties is het een datacenter exit een aanzienlijk eenvoudigere en meer voor de hand liggende stap dan voor grote enterprises. Zeker in enterprise context benadrukken we dat er echt van uit applicatieperspectief de afweging gemaakt dient te worden. Het blijft vervolgens een periodiek process om vanuit de applicatie-architectuur 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 beheer van traditionele datacenter stacks. In CIO Magazine #2-18 schreven we reeds onze visie hierop in het artikel omtrent Cloud Center of Excellence.

Edwin van Nuil is Managing Director bij Oblivion Cloud Control, Jeroen Jacobs is Cloud Consultant & Project Manager by Oblivion Cloud Control

(Dit artikel is eerder verschenen in CIO Magazine in Maart 2018)

Edwin van Nuil