Publieke Cloud: leggen we de lat wel hoog genoeg?

Infrastructuur hoort in dit tijdperk van virtualisatie en cloud geen belemmering meer te zijn voor welk functioneel businessdoel dan ook. Dit principe heeft u vast vaker gehoord, maar wat ik het laatste jaar meemaak bij klanten van CGI geeft aan dat de realiteit weerbarstiger is. Laten we kijken naar het speelveld.

De lat rond WAN latency

Casus éen. Een grote verzekeringsmaatschappij begint in 2016 zijn hele klantenregistratie te centraliseren, waardoor alle regio’s (tientallen landen) in een enkele centrale database kunnen belanden. En ook direct online-real-time benaderbaar zijn; voor intensieve opvragen zoals schade-saldi en toegangsdelegaties gaat dit via geoptimaliseerde replica-databases. Terecht, de NoSql-familie is hiervoor beduidend sneller dan een read-write SQL database.

Echter: de centralisatie is alleen voor de regio Europa. Als er namelijk vanuit Azië en Amerika direct calls naar deze replica databases zouden plaatsvinden, dan kan door de latency (snelheidsbeperking door de WAN afstand) nooit de vereiste 30 milliseconde responstijd per call geboden worden. Dus krijgen deze regio’s een eenmalige kopie van de code, waarmee ze dan een eigen regionale masterdatabase en opvraag-replicas kunnen bouwen en neerzetten. Dit leidt tot fors verlies in codekwaliteit, dubbel onderhoud en hogere hosting-kosten.

De eerste denkfout in deze redenering is de aanname dat centraal aangestuurde replica databases allemaal in Nederland moeten staan. Juist Cassandra-achtige replica’s, met asynchrone synchronisatie via een message bus zoals MQ of Apache Kafka, kunnen uitstekend in bijvoorbeeld Singapore en Miami staan. Van daaruit bedienen ze, met uitstekende latency, de applicaties over die hele regio.

En de tweede denkfout is dat sowieso decentraal geredeneerd wordt. Of nu de private of public cloud gekozen wordt, zodra de onder strikte centrale controle staande replica’s in het ontwerp geplaatst worden, werkt het. Bijvoorbeeld ‘public’ met Google, AWS of Azure is het neerzetten van een model-onder-centrale-controle ‘bouwstenen van de plank halen en opstarten’: we kiezen een regionale hostingzone, regelen alle beveiliging (dat kan ook aan alle eisen van dit soort organisaties voldoen), definiëren de replicatie en we zijn ‘up and running’. 30 milliseconde responstijd, zelfs voor een datacentrum in pakweg Sydney dat Singapore aanroept of van Sao Paulo naar Miami, gaat probleemloos.

Naar analogie van de slagzin van een bekend opleider zou ik willen stellen: ‘wij als CGI zorgen voor de juiste stok. Maar de klant bepaalt hoe hoog de lat gelegd wordt’. En de lat kan in gevallen zoals deze een heel eind hoger liggen door de logica volledig te centraliseren en de cloud regionaal de dienst te laten leveren. De geclaimde ‘besparing’ door minder centralisatie is schijn, de eerder genoemde extra kosten van de versnipperde benadering doen deze besparing ruimschoots teniet.

De lat in stackbeheer

Casus 2. Een andere klant, maar met een vergelijkbare terughoudendheid voor de cloud. Nu is het een financiële instelling die volop bezig is met Agile en DevOps voor de applicatiebouwers. Agile voor de ondersteunende teams zoals security, network en IaaS hosting is minder ver doorgevoerd. Terecht; invoeringen zoals een nieuwe Linux- of SSL-versie hebben van nature deels een Waterval-karakter. Hun strategie is private-cloud-first.

Een van de stack-ondersteunende teams is de IaaS afdeling. Inhoudelijk scoort deze best goed, met momenteel vooral IaaS op hypervisor en op termijn containerization met Kubernetes/Docker. Met een stuk PaaS-database of ander meer klassieke optie voor data-opslag, werkt containerization gewoon minder goed. Investeringen worden voornamelijk gedaan in extra bouwstenen van de hypervisor en PaaS-achtige add-ons als databases en loadbalancers.

De keuze voor private in plaats van public cloud heeft hier m.i. een erg storend neveneffect. Door het prioriteit geven aan al die extra bouwstenen is er geen ruimte voor een hypervisor upgrade. Dat betekent technical debt, wat weer leidt tot incidenten. Deze technical debt zou in de public cloud niet voorkomen. Want bij Azure, AWS, Google en de zijnen is het principe ‘wij gaan met onze service elke maand over naar de nieuwe versie, uw klantfuncties gaan automatisch mee’. Dus als deze klant mij vraagt hoe met dit principe ‘Infrastructuur hoort geen belemmering meer te zijn voor welk functioneel businessdoel dan ook’ om te gaan, dan wist ik het wel...

Wij zorgen voor de juiste stok…

In beide gevallen geldt dus: aan de polsstok zal het niet liggen. Wij van CGI engineeren met genoegen pakweg een WAN-replicatie over de cloud, regionale replica databases, Kubernetes-clusters op Azure of AWS of dat soort modellen. En zullen de klant ook uitleggen wat de voordelen zijn om op dit vlak in-het-diepe-te-springen: de business case voor public cloud is, bijvoorbeeld als technical debt erg kostbaar zou zijn of de applicatie onterecht versnipperd zou raken, snel genoeg gemaakt.

Aan de lat ligt het, in ieder geval voor bovengenoemde casussen, soms wél. De IT-doelstelling voor klanten zoals deze zou een public-cloud-tenzij filosofie moeten bevatten en geen private-cloud-first. Onze klant wil namelijk wereldwijd kunnen concurreren met een zo groot mogelijke flexibiliteit en zo laag mogelijke kostenpeil. Dus als ons in dit soort casussen gevraagd wordt mee te denken met als aanname private cloud, dan zullen wij de klant uitdagen om de lat hoger te leggen wanneer wij denken dat dit mogelijk is. Dit zullen we uiteraard gefundeerd doen op basis van voor- en nadelen van de public cloud en eventueel hybrid cloud. De keus is uiteindelijk natuurlijk aan de klant. En deze principes én onze jarenlange ervaring met het toepassen ervan kunnen de klanten beamen!