Bij vele bedrijven is de vraag naar cloud-oplossingen erg actueel. Vaak wordt de vraag belegd bij de IT afdeling in combinatie met de DevOps teams. Maar wat nou als er vele diverse DevOps teams zijn die het zelf moeten uitvogelen, als IT het al druk genoeg heeft met hun werkzaamheden, en als cloud-kennis nog niet goed geborgd is in de teams. Welkom bij de Cloud Center of Excellence (CCoE).

WAT IS HET CCOE?

Het CCoE is een team van cloud-engineers en architecten die het bedrijf helpen om in een korte tijd stabiele en beheersbare cloud-oplossingen te realiseren. Het is een centraal punt van kennis en kunde, een balans tussen snelheid en stabiliteit, maar nog belangrijker: een helpende hand. De developers zullen naast het ontwerpen en bouwen van de applicatie, ook zelf deployen en de klant ondersteunen. Geen tussenkomst van IT afdeling met ITIL-processen en tickets.

Het CCoE zal het cloud-platform aanbieden, en vervolgens is de developer in-control. Ze zullen ook zelf verantwoordelijk worden voor security en service management. Het CCoE zal op deze vlakken ondersteuning bieden, maar niet de man-in-the-middle zijn waar ze op moeten wachten. Het CCoE zal de focus verschuiven van een sterke afhankelijkheid van de IT afdeling, naar meer autonomie bij de DevOps teams.

Meestal begint een CCoE als single-cloud provider (bijvoorbeeld op Azure, AWS of GCP), maar kan op den duur best uitgroeien naar een multi-cloud provider.

CCEO model

Soms wordt de term Cloud Based Service Provider (CBSP) gebruikt voor een vergelijkbare constructie als het CCoE.

het begint met een visie..

Een CCoE begint met een visie. Dit zal variëren per CCoE, maar zal neerkomen op: Maximaliseer autonomie en slagvaardigheid voor de DevOps teams.

Het CCoE helpt DevOps teams door het aanbieden van een betrouwbaar cloud platform, zodat ze snel en betrouwbaar cloud applicaties kunnen bouwen, met het minimaliseren van risico’s. Dit doen ze niet zoals een klassieke IT afdeling, maar meer als service provider. De DevOps teams zijn zelf in beheer van hun cloud omgeving.

Voorbeelden

Stel een DevOps team wil een web-applicatie naar de Azure cloud brengen. Ze hebben de kennis dat dit een App-Service zal worden die ze met Azure DevOps en Release pipelines deployen. Het CCoE zal vervolgens helpen met adviseren van een App Service Environment (voor Virtual Network isolatie), een Private Build Agent aanbieden die daarbij nodig is, en de Private DNS en Application Gateway inrichten.

Of stel een DevOps team wil in Azure een Kubernetes cluster gebruiken. Ze zijn bekend met “kubectl” en kunnen ook een load-balancer als ingress controller aanmaken. Het CCoE zal vervolgens helpen met het daadwerkelijk aanmaken aangezien een AKS cluster een Virtual Network subnet claimt waar vervolgens geen VM’s meer op gedeployed kunnen worden. Tevens adviseren ze in de IP-ranges en helpen ze om firewall changes uit te voeren.

Hoe bouw je een ccoe?

Het komt er op neer dat je zelf een team gaat samenstellen binnen jouw organisatie, dat waarschijnlijk een combinatie is van interne medewerkers aangevuld met externe specialisten.

Microsoft (voor de Azure cloud) kan hier hulp in bieden met richtlijnen (link) en resources (cloud engineers en architecten). Maar er zijn ook andere partners en cloud providers die je hier mee kunnen helpen.

Niet ieder CCoE is hetzelfde. Net zoals je Scrum naar eigen hand kunt toepassen, geldt dat ook voor CCoE. Er zijn algemene richtlijnen, die ooit zijn bedacht door Stephen Orban, maar daar kun je gerust naar eigen inzicht van afwijken. Hier volgt een opzet zoals die bij mijn opdrachtgever opgezet is, en ook geadviseerd door Microsoft.

Cloud Center of excellence
  • Customer team
    Bestaat uit enkele cloud-solution-architecten die met de klant een intake uitvoeren, een solution-design maken, advies geven, de verantwoordelijkheden afstemmen, en helpen met het bouwen van hun product middels een POC of MVP.
  • Product team
    Bestaat uit enkele cloud-engineers die standaard/gecertificeerde producten maken die door het customer team en de klant gebruikt kunnen worden. Denk aan VM images, Kubernetes clusters, SQL servers en storage accounts die compliant zijn met security en service-management.
  • Platform team
    Bestaat uit enkele cloud-engineers die zorgen voor connectiviteit, IAM (Identity and Access Management), monitoring en beheer (operations).
  • Cloud Architecture
    Bestaat uit enkele enterprise- en security-architecten, die samen met delegaties uit de overige teams de reference-architecture (het beleid) van het CCoE opstelt.
  • Service Management
    Bestaat uit één à twee cloud-architecten die richtlijnen opstellen voor het beheer van het cloud platform, zoals patch management, kosten-beheer, eigenaarschap, cloud-limiet-beheer, kennis overdracht, en inrichting van operations.
  • Security and Risk managment
    Bestaat uit één à twee security-architecten die richtlijnen opstellen voor de security, zoals Identity and Access Management, data-classificatie, en network security.

proces

De diverse DevOps teams met hun cloud-wens, oftewel ‘de klant’, noemen we een workload. Als een nieuwe workload zich aanbied (via mail, wandelgang, ticket-systeem), dan wordt deze ge-onboard, en start het proces van Intake > Ontwerp > Bouw > Run.

Procesweergave van Cloud Center of Excellence

Intake

Als een DevOps team aan de deur klopt omdat ze een cloud-wens hebben, dan zal de Product Owner van het CCoE eerst grofweg inventariseren wat de wensen zijn, toetsen of hun cloud-wens haalbaar en plausibel is, en prioriteren.

Ontwerp

Een cloud solution architect pakt de workload verder op, maakt een afspraak met de klant voor verdere details te bespreken, maakt een cloud solution design, herkent herbruikbare producten en maakt een kostencalculatie. De output wordt met de klant besproken. Hier wordt ook vaak het platform voor de klant klaar gezet (deploy), zoals een resource-group of AKS cluster.

bouw

Tijdens de bouw fase is de klant aan zet. Hij dient de applicatie te bouwen, als die nog niet gebouwd is. De solution architect helpt vaak mee met de CI/CD pipeline voor Infrastructure-as-Code. Soms wordt er een Proof of Concept (PoC) gemaakt, maar vaak gaan we snel door naar het Minimum Viable Product (MVP). Als herbuikbare producten herkend zijn, zal het product team deze nu bouwen.

RUN

Het product (MVP) is gebouwd en getest in een testomgeving. Nadat de klant akkoord is gegaan met de RACI (matrix met verantwoordelijkheden) en een security officer de oplossing heeft geaccordeerd, kan het in productie gezet worden. Vanaf hier stopt de inzet van het customer team, en begint business-as-usual (beheer).

DEMARCATIE (GRENSSCHEIDING)

Een belangrijke term is demarcatie: wie verzorgt wat.Soms denken DevOps teams dat het CCoE hun cloud-wens gaat bouwen. Of dat het CCoE hun VM’s gaat patchen. Hier dient de demarcatie duidelijk gesteld te worden, en zie je het sterke verschil tussen een IT afdeling en CCoE. Je krijgt de agility (wendbaarheid) in eigen handen, maar je dient ook zelf het beheer te doen. Als je bijvoorbeeld een Kubernetes cluster aanvraagt, kun je het vanmiddag al krijgen, maar dien je zelf de upgrades te doen. Dit wordt duidelijk gemaakt met een RACI (zie Wikipedia) waarin duidelijk wordt gemaakt wie welke verantwoordelijkheden draagt.

Belangrijkste take-aways

Marco Vervoort werkzaam bij Team Rockstars IT

Met Marco sparren over het werken met Cceo?