Optimaliseer je private cloud deployment: van legacy naar toekomstvaste IT

In de afgelopen jaren heb ik voornamelijk (semi-)overheidsorganisaties geadviseerd, die qua IT-landschap net zo divers zijn als multinationals. Door afsplitsingen, fusies en andere veranderingen zie ik vaak meerdere generaties van platformen. Dit maakt het beheer van IT-infrastructuren complex en uitdagend. 

In deze blog richt ik me op de deployment in de private cloud: hoe creëren we servers, oftewel 'hosts' (fysiek, virtueel of containers) voor onze applicaties? En hoe houden we deze up-to-date, zelfs als de applicatie in een agile tempo wordt onderhouden en de infrastructuur regelmatig lifecycle-patches nodig heeft? 

Met de recente toename van cyberdreigingen en de noodzaak voor snelle, veilige en efficiënte IT-oplossingen, is het belangrijker dan ooit om onze deployment-strategieën te optimaliseren.

Verschillende soorten tooling

De adviezen in deze blog onderbouw ik met praktijkvoorbeelden uit mijn recente klantopdrachten. Het onderwerp mag duidelijk zijn: we hebben aan de ene kant een mooie applicatie, en aan de andere kant een Virtuele Machine of een Docker container. En de host   moet goedkoop, snel en veilig zowel de laatste applicatieversie als de laatste infra-patches krijgen. Handmatige acties, behalve dan iets van een kwaliteitscheck voor uitrol naar productiesystemen, willen we vermijden. Het gaat om een ‘desired state’ systeem, waar de hosts constant vergeleken worden met de gewenste configuratie en bijgesteld worden waar nodig. Hoe bepaal je je toolset?

De tools die ik ben tegengekomen kun je onderverdelen in 4 categorieën: 

• Klassieke software deployment zoals XLDeploy of de deployment-agent van Azure DevOps. Omdat moderne tools de hele host, infrastructuur én applicatie, dekken is mijn advies deze legacy af te bouwen. (Azure DevOps heeft ook een Continuous Integration-kant, die heeft wél toekomst.)
• Box managers, oftewel de uitrol- (en vaak ook beheer-) tools van een middleware-leverancier. Vaak relatief goedkoop, maar niet echt geschikt voor uitrol van meer complexe .Net- en Java-applicaties of voor Infrastructuur-componenten van een ander merk. Voorbeelden zijn Red Hat Kickstart, Oracle Universal Installer en VMWare templating.
• Generieke Infrastructure-as-Code (IaC) software, zoals Ansible. Ze zijn perfect om een hele host uit te rollen en bij te houden, behalve als er containerised applicaties in beeld zijn. Dit soort tools hebben geen diepe kennis van container/Kubernetes settings.
• Containerspecifieke IaC tools. Je raadt het al: min of meer het spiegelbeeld van de generieke tools. Goed in de details, denk aan de Kubernetes ‘timer’ die efficiënter is voor batchjobs dan de gewone Linux scheduler. Maar op VM-niveau beperkt, en niet in staat updates te maken op externe componenten zoals loadbalancer of queue.

Analyse toekomstvaste Continuous Delivery

Voor deze 4 categorieën van tooling willen we graag de inzetbaarheid in toekomstvaste Continuous Delivery bepalen door een sterkte-zwakte analyse. In die analyse kijken we o.a.  welke functionaliteit de tool heeft op VM-niveau plus bijvoorbeeld aanpassings-calls op loadbalancers en queues, versus wat ie kan binnen de Docker/Openshift/Kubernetes container.

Dit zien we terug in de analyse:

4 belangrijke lessen voor de toekomst

Uit de ervaringen heb ik de volgende adviezen gedistilleerd, veelal met een korte casus erbij.

1. Gebruik een tool vooral in zijn sterke gebied, met zo min mogelijk ‘uitstapjes’

Om een tool te gebruiken waarvoor hij primair bedoeld is, is vanuit architectuur gezien heel wat onderhandelwerk nodig. Veel IT-specialisten zijn fervent fan van hun specialismetool waarbij het spreekwoord ‘voor wie goed is met een hamer, lijkt elk object een spijker’ veelal opgaat. We gaan dus niet geforceerd een generiek IaC-tool ook inzetten voor instellingen binnen een container, tenzij het echt om slechts enkele procenten van het werkveld gaat en een ‘uitstapje naar vreemd terrein' uit te leggen is. Maar let wel, dit kan botsen met advies 3 en dan is het een kwestie van het afwegen van voor- en nadelen.

2. Elk (deel van een) host staat onder controle van maximaal een enkele tool

Net als bij advies 1 draait dit om het afbakenen van verantwoordelijkheden en het organisch laten groeien van een tool-‘domein’. Bij een klant was bijvoorbeeld de hele Java-middenlaag samen met Linux onder beheer van de box manager voor de Java-server. Echter, tijdens de installatie van applicaties werden sommige instellingen regelmatig aangepast door de generieke IaC-toolset die de applicatie uitrolde. Dit leidde ertoe dat na elke middleware-patch de box manager deze instellingen weer overschreef. Hierdoor weigerde de applicatie dienst en moest er een nieuwe box manager-deploy worden uitgevoerd.

De oplossing was om duidelijke grenzen te stellen: middleware-instellingen die gerelateerd waren aan de applicatie werden in een aparte file geplaatst, die in het ‘classpath’ de standaardinstellingen verving.

3. Kies voor maximaal twee van de drie mogelijke toolsoorten

Dit advies gaat alleen op als je de vrije keuze hebt, vanaf Infra tot aan applicatie; in heel wat organisaties zijn er deelterreinleveranciers die bijvoorbeeld alleen Infra-as-a-Service of Platform-as-a-Service bouwstenen leveren, en die maken hun eigen keuzen. 

Maar als die vrije keuze er is, rationaliseer dan. Niet alle drie de toekomstvaste tools (box manager, generiek IaC tool en container IaC tool) doch twee. Bijvoorbeeld alleen box manager en container-IaC; de paar vereiste akties op generiek-IaC niveau worden dan als uitstapje gedaan vanuit de box manager. Of alleen generiek-IaC en container-IaC tool; de hele Linux/Windows- en middleware installatie wordt dan ook in het generieke IaC tool gedaan.

De motivatie voor het beperken van de toolset is efficiëntie: elk tool heeft een aanzienlijke dosis overhead. Dus als we  terug kunnen naar twee tools i.p.v. drie door die 2 tools te kiezen die een gegeven situatie het beste afdekken (zie advies 1), dan scheelt dat fors. Bij alle klanten waar ik met dit advies kwam was het een tijdrovend proces, maar uiteindelijk is met objectieve criteria een goede keuze te maken en leggen ook de ‘verliezers’ zich erbij neer.

4. Probeer zoveel mogelijk hosts als cattle te genereren, in plaats van als pets te onderhouden

Dit advies heeft meer uitleg nodig. In het Infrastructure-as-Code taalgebruik kennen we vee (cattle) en huisdieren (pet). Een cattle-host wordt niet via een desired-state-systeem vergeleken met de gewenste situatie, doch simpelweg leeggepoetst/weggegooid en vervangen door een nieuwe gebaseerd op een template met de nieuwste patches en applicatiecode. Een pet-host wordt juist wel vergeleken en bijgewerkt. 

De analogie moge duidelijk zijn: een veehouder heeft een heel andere band met zijn honderden koeien of varkens dan met zijn boerderij-huisdieren. Ondanks de namen voor sommige koeien ziet hij ze als vervangbaar, als deel-van-een-grote-familie. Huisdieren zijn qua emoties onvervangbaar, krijgen een individuele behandeling, en worden verzorgd zolang als het kan.

In een aantal organisaties ervaren we dit als eindgebruikers aan den lijve. Onze desktops worden dan als ‘cattle’ beschouwd, en de helpdesk heeft als regel dat het oplossen van een incident maximaal een uur mag kosten. Wordt de puzzel en reparatie langduriger, dan wordt de desktop (of alleen de Citrix-VM) vervangen door een nieuw uitgerolde omgeving. Mogelijk vervelend voor de individuele eindgebruiker, maar een kostentechnisch verdedigbare keuze van de organisatie.

De ratio achter het advies zal duidelijk zijn: cattle is aanmerkelijk goedkoper qua bediening, en bijvoorbeeld het onderhouden van de IaC programmatuur, dan pets. Maar pets zijn nooit helemaal te vermijden, denk aan machines met een relevant filesysteem of zelfs de hosts met de IaC-tooling erop.

Renoveer met beleid

Hopelijk herken je iets van de hier beschreven situaties, en geven de adviezen handvaten voor de toekomstige Uitrol-architectuur. Dus met een goede afbakening tussen de tools, een geminimaliseerd aantal tools en een nadruk op het genereren van hosts als cattle. Wij van CGI hebben er uitgebreide ervaring mee en komen graag een handje helpen!