Met de groei van enterprise workloads op public-cloudplatformen als Amazon Web Services (AWS) of Microsoft Azure wordt ook het vraagstuk cloud-operations steeds actueler. Sommige CIO’s brengen het beheer onder in hun bestaande (soms uitbestede) IT-organisatie. Andere CIO’s starten bewust een cloudcenter of excellence (CCoE). Maar wat is nu een CCoE eigenlijk? En hoe zet je dit succesvol neer? Edwin van Nuil en Jeroen Jacobs hebben meerdere CCoE-implementaties uitgevoerd en delen hun ervaringen en lessons learned.

Het beheren van een cloudplatform als AWS is niet te vergelijken met het beheer van een private datacenterstack. Dergelijke platformen vereisen andere competenties en kennen een andere dynamiek. Het runnen van cloud-operations als traditionele IT-operations is helaas nog steeds een veelgemaakte fout.

CloudOps wordt dan vaak in de bestaande organisatie ‘erbij gedaan’. Gevolg: traditionele ITIL-processen, meerdere afdelingen en manueel beheer van het cloudplatform. Cloudpractices als beheer via infra-as-code en gebruik van cloud-nativediensten worden achterwege gelaten. Hierdoor worden de voordelen die de public cloud enablet gemist en komt de beheersbaarheid sterk onder druk te staan.

Beheer moet anders

Cloud-platformbeheer dient anders te worden georganiseerd dan het beheer van een datacenterstack. Dit komt omdat public cloud vanuit een andere filosofie is neergezet. Een belangrijk voorbeeld hiervan is de focus op de softwareontwikkelaar alsook het feit dat een cloudplatform softwaregebaseerd is.

Softwaredevelopers en infra-engineers werken in de cloud dan ook intens samen. Geen fysieke hardware en integratie-uitdagingen meer tussen netwerk, compute en storageteams, maar één platform waarin alles integraal werkt en via code gemanaged en geautomatiseerd kan worden.

Figuur 1. Van traditioneel beheer naar CCoE

Ook worden kant-en-klare applicatiebouwstenen aangereikt als managed databases en message-queues. Tot slot is het pay-per-use-gedachtegoed een belangrijk aspect. Waar voorheen budgetcycli de financiën in control hielden, drijft nu de engineer direct de kosten. Voordeel daarentegen is dat investeringen in nieuwe technologie tot op de milliseconde kunnen worden verrekend, wat de innovatie drijft. Deze aspecten vereisen een integraal team en een andere aanpak van beheer.

Kenmerken van CloudOps-teams

Een CCoE heeft een aantal specifieke kenmerken. Vanuit het DevOps-gedachtegoed is er een sterke business/applicatiefocus en is het team agile georganiseerd. Het team werkt bij voorkeur ook in sprintcycli voor de planbare werkzaamheden en streeft door middel van automation naar zoveel mogelijk stabiliteit, planbaarheid en voorspelbare activiteiten.

Een zo goed als lege incident-queue zien we dan ook als een key-succesfactor. Verstoringen zijn immers uitzondering en zijn direct urgent en worden opgepakt, of worden planbaar. De teamsamenstelling van een CCoE is multidisciplinair en niet te groot, vijf tot tien man maximaal – het liefst een mix van business, architectuur, security, infra en applicatieontwikkelaars. Aangezien het cloudplatform via infra-as-code wordt gemanaged, vereist de operationele skillset over het algemeen meer een developersmindset dan een infrabeheermindset. Belangrijk voor succes is de teamleden hierop te selecteren.

Cloud center of excellence vanuit functioneel perspectief

Ook vanuit functioneel perspectief is het aan te raden om CloudOps anders op te zetten dan het traditionele ITIL-beheermodel. Dit wil niet zeggen dat er bijvoorbeeld geen incidentmanagement plaatsvindt, maar een en ander dient te gebeuren vanuit een DevOps-gedachtegoed. Om de functionele scope van een CCoE weer te geven, kan het CloudOps-framework dienen. Dit model is ontstaan uit inzichten uit het Cloud Adoption Framework van Amazon Web Services, concepten uit het DevOps-gedachtegoed aangevuld met eigen implementatie-ervaringen uit de praktijk.

Het CloudOps-framework is opgebouwd vanuit een business/applicatiefocus en een operationele focus. Binnen die gebieden zijn CCoE-functies benoemd die hieronder worden toegelicht. Het is belangrijk om deze functies als kerncompetentie onder te brengen in het CCoE.

Een veelgemaakte fout is het runnen van cloud operations als traditionele IT

In de operationele laag beginnen we met serviceprovisioning wat het uitleveren en wijzigen van cloudservices (resources) betreft. Anders dan bij traditionele IT worden diensten niet via een grafische interface (console) bij elkaar geklikt, maar in code gedefinieerd in een template. Deze templates worden via code deployment pipelines en source code repositories gemanaged en geprovisioned.

De tweede functie is daily support wat betreft de operationele ondersteuning aan afnemers van de cloudservices. Denk aan het oplossen van incidenten en het verwerken van kleine verzoeken en vragen. Hoewel dit klassieke ITIL-processen lijken, houden we dit lean en mean, met het doel alles binnen één team op te lossen.

Figuur 2. CloudOps framework

Continuously monitoring betreft het monitoren op performance en resiliency van de workload op het cloudplatform. Hierbij geen traditionele monitoringschermen met kleurtjes, maar vooral slimme alerts die een self-healingactie starten of de engineer van dienst een bericht sturen om te acteren. Een ander deel van deze CCoE-functie is het logmanagement. Cloudservices genereren veel logs en metadata. Hier de juiste informatie uit halen en op acteren behoort ook tot de scope.

Cost capacity & control is de plannende en bewakende functie gericht op de kosten en servicelimits van een cloudplatform. De pay-per-usegedachte geeft de engineer direct de macht om de kosten te maken. Inzicht en goede controls hierop zijn essentieel. Automation zit wat ons betreft over de business en operationele functies heen en is in een CCoE een continu proces dat wordt gedreven door de CCoE-leden zelf. Dagelijkse beheertaken automatiseren maar ook zaken die de applicatie/business ondersteunen.

Securitymanagement is key en zeker op de public cloud. Met zaken als shared responsibility en een grote variëteit aan diensten, is het essentieel te snappen waar het de verantwoordelijkheid van de afnemer van de clouddienst betreft. Daar waar op private stacks de security veelal generiek op bijvoorbeeld de netwerk laag is geregeld, is dit op public cloud iets wat ook zeker per applicatie geregeld wordt.

Zoals elk team gaat het CCoE door fases van euforie en tegenslag

De activiteiten in de toplaag van het model zijn tactischer van aard. Business-demand is actief binnen de organisatie op zoek naar cloud-opportunity’s en het vertalen van businessuitdagingen naar oplossingen op het cloudplatform. Architecture patterns richt zich op het verzamelen en definiëren van cloudpractices en standaarden binnen de organisatie.

Met de bouwstenen op de cloud, kunnen applicatieteams alle kanten op. Uniformiteit en best practices zijn belangrijk om het beheer consistent en efficiënt te houden. De laatste functie is projectsupport dat zich richt op participeren in applicatie en businessprojecten om cloudkennis effectief in te zetten en een succesvolle overgang naar support in het CCoE te realiseren.

Deze functies/competenties omvatten de kern van een CCoE. We blijven het bewust functies noemen en geen processen.

Split tussen applicatieteams en het CCoE

Alhoewel applicatie en infra op een cloudplatform integraal is, richt het CCoE zich veelal op de generieke kennis en platformactiviteiten. Applicatieteams maken vervolgens gebruik van de cloudservices geleverd door het CCoE. Omtrent de demarcatie van CCoE en applicatieteams hanteren we vaak onderstaand model (zie figuur 3, in dit voorbeeld gevuld met de AWS-servicecategorieën).

Figuur 3. Demarcatie CCoE en applicatieteams

De donkere vlakken onderin zijn generiek en worden in de meeste gevallen volledig door het CCoE gemanaged. De lichte vlakken zijn qua kennis wel gecoverd in het CCoE maar worden in de uitvoering door de applicatieteams zelf ingericht en beheerd.

Virtuele servers (compute) en managed databases zijn twee diensten die we eruit willen lichten. In veel CCoE wordt server-OS-management als added value geleverd op de IaaS-computeservices. Dit wordt dan wel conform cloudprincipes geleverd zoals bijvoorbeeld volledig geautomatiseerde patching. Toch is de demarcatie, zelfs binnen één organisatie, niet altijd uniform. Applicatieteams die zelf software ontwikkelen, hebben immers andere behoeften dan standaard commerciële software.

Succesfactoren bij implementatie

Het implementeren van een CCoE is niet eenvoudig maar de volgende factoren dragen positief bij. Het initiëren van het CCoE start idealiter bij het begin van cloudadoptie. Initieel als projectteam, maar zodra de eerste applicaties runnen ook echt met een operations-mindset. Vaak start het projectteam deels met interne medewerkers en deels met externe cloudconsultants.

Doel is dat de interne medewerkers hands-on een snelle leercurve doormaken en uiteindelijk de rol van de externe consultants overbodig maken. Een ander belangrijk aspect is de positie in de organisatie. Het team moet zichtbaar en identificeerbaar zijn en afhankelijk van de fase waarin de cloudadoptie zich bevindt, is strategische versus operationele plaatsing in de organisatiestructuur een belangrijke afweging.

Een ander punt is dedication. We raden altijd aan om met een klein team te starten omdat code-based infra managen voor de meeste engineers buiten de comfortzone ligt. Dit vereist veel aandacht en hands-on-begeleiding, want met alleen trainingen kom je er niet. Ook is een klein team sneller op elkaar ingespeeld en gaan software en infradisciplines elkaar versterken. Wanneer echter na enige tijd het CCoE een groot en ervaren team begint te worden, is het raadzaam om te herevalueren om de business- en ops-functies apart verder te laten schalen.

Tot slot willen we nog meegeven dat het opzetten van een cloudcenter of excellence gepaard gaat met ‘fail fast, learn fast’. Zoals elk team gaat het door fases van euforie en tegenslag en haalt ook niet ieder teamlid vanzelfsprekend de gewenste eindstreep. Start daarom vroegtijdig voordat de grote workloads op de cloud gaan draaien en zoek en deel zeker ervaringen met andere organisaties binnen of buiten de sector.


Interne shared responsibility

Een bekend model van Amazon Web Services is het shared-responsibilitymodel waarmee verantwoordelijkheden tussen cloudprovider en afnemer worden weergegeven. In feite geldt een vergelijkbaar shared-responsibility-model ook tussen applicatieteams en het CCoE. Vanuit applicatieperspectief is de applicatiemanager altijd end-to-end verantwoordelijk voor de applicatie op aspecten als bijvoorbeeld security, kosten en applicatieconsistente back-up. Desalniettemin kijkt het CCoE ook generiek naar deze aspecten en bieden ze kant-en-klare bouwstenen aan.

Door Jeroen Jacobs (jeroen@oblcc.com), cloudconsultant & projectleider en Edwin van Nuil (edwin@oblcc.com), managing director bij Oblivion Cloud Control B.V.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter