De transoebelemaanse dwergslak, Ikea en applicaties voor cloud

De transoebelemaanse dwergslak, Ikea en applicaties voor cloud

Uitstekend voorbereid. Dat ben ik. Gewapend met een kloeke slidedeck begin ik mijn presentatie die bol staat van innovatieve techniek. Dat denk ik. Dertig slides over congerved en zelfs hyperconverged stack, software defined, netwerkvirtualisatie en de producten die zulks allemaal mogelijk maken. Aan het eind krijg ik wat vragen die overduidelijk ontstaan uit beleefdheid: vragen om maar een paar vragen te stellen. Maar ik merk dat er weinig echte interesse is. Klassieke inschattingsfout: de vraag achter de vraag niet horen, laat staan begrijpen. Hoewel er een CIO en een IT-director in het publiek zitten, vinden ze het verhaal over dit technische fundament beslist niet belangwekkend. Ze willen lekker wonen. Daarbij hebben ze ideeën over hoe de kamers eruit moeten zien. Maar hoe wij het fundament de grond inheien en sterker: hoe wij de heimachine naar het terrein vervoeren, boeit ze niet in het minst. Het had moeten gaan over applicaties en data.

Nu had ik meer belangstelling gewekt met een verhandeling over het baltsgedrag van de Transoebelemaanse dwergslak.

Toch zie ik veel bedrijven in mijn vakgebied dezelfde ‘fout’ maken. Vanuit de traditionele IT zijn we heel snel geneigd om naar de infrastructuur te kijken. Dat is vertrouwd terrein. Ons nerd-brein krijgt een kick van de specs van de nieuwste generatie E5-processor. Ons bloed gaat sneller stromen bij de throughput-getallen op een vers en juist geconfigureerd VxLAN.  We zijn heel druk met verzinnen hoe we infrastructuur naar de cloud kunnen brengen. Ergens vinden wij, echte die-hard IT’ers, dat ook heel eng. Wij houden zo van die machines op de datacentervloeren. Wij baltsen, net als die Transoebelemaanse dwergslak. Wij knuffelen onze servers, die steeds kleiner en kleiner worden. Maar liever nog dwergservertjes in ons datacenter, dan alles in de cloud. En we denken dat onze klanten – de klanten van grote IT-dienstverleners – er net zo over denken en dus vertellen we vooral over de harde IT. Alsof je daar nog het verschil maakt. Niet dus.

Commodity

Het interesseert eigenlijk niemand nog: IT voor IT. Nee, IT moet vooral randvoorwaardelijk werken. Enabling, heet dat in jargon. Nog meer jargon: infra is commodity. Het is er gewoon. Je wilt er ook niet over nadenken hoe je het krijgt. Zoals de Billy van Ikea. Kwestie van de plaatjes in de handleiding volgen, overeind zetten en vullen met boeken. De uitdaging zit meer in de keuze van de boeken. Infrastructuur is de Ikea van de IT. Zolang er maar een duidelijke instructie bij zit. Kijk maar eens op de portals van de grote IaaS-providers: kant-en-klare bouwstenen (templates en blueprints), slechts een enkel stuk gereedschap (stap-voor-stap instructies) en een afrekenmechanisme. Klaar voor gebruik. Infastructure-as-a-Service als Billy, de muis als imbussleuteltje. Dat geldt niet alleen in public cloud, maar in private. “Deployment took me two days, instead of two months.” Eén doosje met ruimte voor tweehonderd virtual servers.

Denk Billy.

Maar dan: die boeken. Als we de boeken nu eens vertalen naar applicaties? Je hebt grote boeken, dunne, dikke, nieuwe en oude boeken. En je hebt boeken die in serie zijn uitgegeven. Al die boeken moeten wel in die kast passen. Die boeken moeten in diverse typen kasten passen. Nog mooier zou het zijn als je die kast enigszins kunt aanpassen aan die boeken, door bijvoorbeeld de plankjes op andere hoogtes te hangen.

Bij applicaties werkt dat eigenlijk net zo. Applicaties wil je kunnen distribueren naar verschillende platformen en wel naar behoefte. Het liefst volledig geautomatiseerd. Als een applicatie tijdelijk meer wordt gebruikt, dan moet een platform automatisch meer bronnen opschakelen: compute power, geheugen, storage, maar ook netwerk moet hierin flexibel meeschalen: op en af. Zo bereik je altijd optimale beschikbaarheid van een applicatie. Probleem is dat veel applicaties niet geschikt zijn voor dergelijke elasticiteit. En bedrijven gooien niet zomaar hun bestaande applicaties overboord voor nieuwe, cloud-native applicaties. Die ‘oude boeken’ moeten geschikt worden gemaakt voor ‘nieuwe lezers’: het taalgebruik moet wellicht een tikje gemoderniseerd en de beschikbaarheid aangepast. Niet meer louter in een gesloten vitrinekast met temperatuur- en vochtregulering, maar open kasten waaruit een ieder een nieuw, herzien exemplaar kan pakken.

DNA

Hoe doe je dat? Ofwel hoe migreer je applicaties naar een omgeving die een dergelijke elasticiteit heeft, doorgaans in IaaS-omgevingen? Dan heb je grosso modo twee keuzes. Of je pakt het hele ding in en verplaatst het als container. Dit is wat tools zoals Docker doen:  Docker pakt applicaties en alles dat erbij hoort in als compleet filesysteem: code, executables, tooling, systeemdata, alles dat nodig is om een stuk software te laten draaien op een server. Werkt prima, maar is niet erg flexibel – al beweert Docker zelf van wel. Een organisatie wil doorgaans controle. Soms is het nodig om in stukjes van de applicatie iets te wijzigen, om welke reden dan ook. Of je wilt stukjes applicatie ergens anders hergebruiken. Dan moet je het DNA van de applicatie echt blootleggen: alles uit elkaar halen en begrijpen hoe die verschillende componenten met elkaar communiceren in een functioneel geheel. Dan begrijp je ook hoe bepaalde componenten elders ook gebruikt kunnen worden.

Waarom zou je dat doen? Omdat dit echte business orchestratie is. Vanuit de business – de onderneming, het bedrijf, de branche – bekijk je welke data op welke plek, in welke vorm, op welk moment en voor welke doelgroep beschikbaar moet zijn. Die behoeften veranderen steeds sneller, bijna ongeacht in welke markt een onderneemt. Vanwege die snelheid moet je extreem flexibel met stukjes software kunnen ‘schuiven’ zodat je bijna onmiddellijk de nieuwe functionaliteit kunt leveren die jouw klanten wensen. Dat wordt alleen maar heftiger. Want als je nu eens bedenkt dat die functionaliteit wordt gevoed vanuit Big Data? Dankzij Hadoop precies weten wanneer welk product waar gaat verkopen? Precies weten in welke regio en bij welke doelgroep iets gaat scoren? En vervolgens volledig geautomatiseerd – aan de hand van die Big Data – al de benodigde functionaliteit én capaciteit opschalen, op precies het juiste moment, in de gehele keten. Dat is orchestratie.

De techniek kan dat al. Diverse cloudpartijen hebben de tools ontwikkeld waarmee dit allemaal mogelijk is. Probleem is… die oude applicaties die goud geld hebben gekost en waar al je business intelligentie al in zit. Applicaties die niet defacto geschikt zijn voor ‘elastic fabric’. Veel bedrijven staan nu voor de keuze: applicatiemigratie of volledige nieuwbouw. Die keuze is niet eenvoudig. Het begint met een strategie en daaruit voortvloeiend architectuur principes. Die moeten worden gedragen vanuit de  business. De onderneming, haar producten en de processen om die producten te maken en te verkopen, moet de blauwdruk zijn voor het applicatielandschap. Dan bepaal je de functionaliteit en hoe je data ontsluit en verwerkt binnen die functionaliteit. En waar moet dat dan op ‘landen’? Die vraag wordt hoe langer, hoe meer volstrekt oninteressant.

De Transoebelemaanse dwergslak zal op zoek moeten naar andere manieren om zichzelf te verkopen. En bedenk dat slakken hermafrodiet zijn. De analogie laat ik verder aan u.