Multicloud is als Java

Even een IT-geschiedenislesje. Er was eens een droom van platformonafhankelijkheid. Een droom die mede werd beleden door een leverancier van een niet-dominant computingplatform. Deze leverancier had een grote concurrent, die met zijn veelgebruikte desktopplatform een deel van de IT-wereld domineerde en van daaruit de serverwereld ambieerde. Deze concurrent zag die droom natuurlijk als een nachtmerrie.

Droom najagen

De droom najagende leverancier kwam met het bevrijdende Java: een platformonafhankelijk platform. Eenmaal geschreven softwarecode kon dan op allerlei verschillende platformen draaien. Bevrijding van vendors en hun lock-ins. Waarmee Java dus zelf weer een bindmiddel kon zijn, alleen was dat niet de insteek. De grote concurrent omarmde dit, én voorzag het van uitbreiding. Waarmee het toch nog platformgebonden werd.

Wie toen de Javawereld wilde bestrijken, moest rekening houden met deze split; Java en ‘Windows Java’. Gezien de realiteit van zaken als ontwikkelkosten, target markets, beperkte budgetten en ROI (return on investment) werden er keuzes gemaakt. De één koos voor een uniforme benadering en probeerde code-portabiliteit te preserveren. De ander koos voor optimalisatie en de markt van het veelgebruikte platform. Een nieuw soort vendor lock-in.

Bevrijding en beperking

Nu de IT-industrie goed is gezeteld in het cloudtijdperk, lijken dit soort verwikkelingen iets van het verleden. Mede dankzij virtualisatie is het makkelijker mogelijk om over te stappen. De virtual machine oppakken en verhuizen maar, op naar een andere cloud. In de praktijk is het niet altijd zo eenvoudig. De infrastructuur van de ene cloudaanbieder is niet die van de andere. Idem dito voor de geboden functionaliteit, hier en daar.

Er komt bij cloud wel wat om de hoek kijken als het gaat om een strategische keuze met het oog op heen en weer schuiven, overschakelen en overstappen. Een platformagnosistische aanpak voor multicloud kan dan noodzakelijk zijn. Bevrijding is mogelijk, maar kent z’n prijs. En dat niet alleen in de initiële opstelling. Het kan ook beperkend zijn voor optimale benutting, of zelfs gebruik van bepaalde nuttige functies uitsluiten.

Geleerd van het verleden?

Tegenover geoptimaliseerde of gewoon goede benutting van cloudkracht staat lift&shift: het domweg overhevelen van bestaande, on-premises omgevingen. Die software-installaties weten dan vaak niet eens dat ze in de cloud draaien. Voor sommigen is dit afdoende, voor anderen is dit zonde van de gemiste cloudkansen. Als reactie daarop valt ‘cloud native’ te zien: het speciaal voor de cloud ontwikkelen van software. Maar is dat dan niet als ‘Windows Java’? Of hebben we geleerd van de IT-geschiedenis?