Dat Kun Je Niet Virtualiseren!

We krijgen dit voortdurend te horen in de IT: een leverancier vertelt ons dat een systeem niet gevirtualiseerd kan worden. De redenen zijn talrijk. Aan de IT-kant zijn we altijd verbaasd dat een leverancier zo'n schandalige bewering doet; en vaak zijn we net zo verbaasd dat een klant (of manager) hen gelooft. Leveranciers hebben er door de jaren heen hard aan gewerkt om deze verkooppraatjes te perfectioneren, en ik denk dat het belangrijk is om die te ontleden.

De grondoorzaak van de problemen is dat leveranciers vrijwel altijd op zoek zijn naar manieren om hun eigen kosten te verlagen en tegelijkertijd de winst uit klanten te verhogen. Dit verklaart veel van wat anders als vreemd gedrag zou worden gezien.

Eén ding dat heel veel leveranciers proberen te doen, is de scenario's beperken waaronder hun product wordt ondersteund. Door dit te doen, positioneren ze zich zo dat ze eenvoudigweg geen ondersteuning hoeven te bieden – ondersteuning is duur en onbetrouwbaar. Dit is een veelvoorkomende strategie. In sommige gevallen is dit zo agressief dat er zelfs geen enkel acceptabel productiescenario meer bestaat.

Een veelgebruikte manier om dit te doen, is het niet ondersteunen van enig ondersteund besturingssysteem, waardoor de leverancier de facto zijn eigen software uitfaseert (vandaag de dag zou dit bijvoorbeeld betekenen dat alleen Windows XP en eerder wordt ondersteund). Een ander voorbeeld is het uitsluitend ondersteunen van producten die niet gelicentieerd zijn voor de betreffende toepassing (een voorbeeld zou zijn dat een product als Windows 10 als server gebruikt moet worden). En een van de meest voorkomende gevallen is het verbieden van virtualisatie.

Deze scenario's brengen klanten in lastige situaties, want enerzijds hebben ze te maken met best practices uit de branche, standaard implementatierichtlijnen, interne tooling en beleidsregels waaraan ze zich moeten houden; en anderzijds hebben ze leveranciers die vaak een correct systeemontwerp, -planning en -beheer verbieden. Deze behoeften staan op gespannen voet met elkaar.

Natuurlijk verwacht niemand dat elke leverancier elk mogelijk scenario ondersteunt. Er moeten grenzen worden gesteld. Maar er is een gigantische kloof tussen het ondersteunen van redelijke, goed geïmplementeerde systemen en het actief vereisen van onacceptabel slechte implementaties. We hopen dat onze leveranciers zich als zakenpartners gedragen en een gemeenschappelijk belang delen in ons succes of, op zijn minst, in het succes van hun product, en dat ze niet rechtstreeks proberen beide te ondermijnen. We zouden hopen dat er, op zijn allerminst, naar beste vermogen ondersteuning wordt geboden voor elk redelijk implementatiescenario en dat gegarandeerde ondersteuning waarschijnlijk wordt geboden voor correct ontworpen scenario's volgens best practices.

Stel je een wereld voor waarin het rijden binnen de maximumsnelheid en het dragen van een gordel je autogarantie zou schenden, en waarin je alleen ondersteuning zou krijgen als je roekeloos en onbeschermd zou rijden!

Een aantal belangrijke zaken over virtualisatie moet worden begrepen. Het eerste is dat virtualisatie een al lang bestaande best practice in de branche is en dat verwacht wordt dat deze in elk productie-implementatiescenario voor diensten wordt toegepast. Virtualisatie is op geen enkele manier nieuw; zelfs in de markt voor het midden- en kleinbedrijf valt het al ruim tien jaar in de categorie best practices en in de enterpriseomgeving al vele decennia. We zijn allang voorbij het punt waarop het niet-gevirtualiseerd draaien van systemen als acceptabel wordt beschouwd, en dat geldt ook voor legacy-implementaties die al lange tijd in gebruik zijn.

Er zijn natuurlijk altijd zeldzame uitzonderingen op vrijwel elke regel. Sommige systemen hebben toegang nodig tot zeer specifieke hardware en virtualisatie is dan mogelijk niet haalbaar, hoewel dit met moderne hardware-passthrough vandaag de dag vrijwel ongehoord is. En sommige systemen met extreem lage latency kunnen niet gevirtualiseerd worden, maar deze zijn normaal gesproken beperkt tot alleen de grootste internationale investeringsbanken en de meest agressieve hedgefondsen, en zelfs de meeste van die traditionele toepassingen zijn weggevallen door verbeteringen in virtualisatie, waardoor zelfs die situaties zeldzaam zijn geworden. Maar de kern is: als je niet kunt virtualiseren, moet je het betreuren dat het niet kan, en je zult duidelijk weten waarom het in jouw situatie onmogelijk is. In alle andere gevallen moet je server virtueel zijn.

Is het niet belangrijk?

Als een leverancier je niet toestaat om standaard best practices voor gezonde implementaties te volgen, wat zegt dit dan over de mening van de leverancier over zijn eigen product? Als we het over een willekeurige andere implementatie zouden hebben, zouden we ons onmiddellijk afvragen waarom we een systeem zo slecht implementeren als we van plan zijn ervan afhankelijk te zijn. Als onze leverancier ons dwingt om ons zo te gedragen, zouden we op dezelfde manier moeten reageren – als de leverancier het product niet net zo serieus neemt als wij de minste van onze IT-diensten nemen, waarom zouden wij dat dan wel doen?

Dit is een “impedantieverschil”, zoals we in ingenieurskringen zeggen, tussen onze behoeften (productiesystemen) en de manier waarop de leverancier die dat systeem maakt ze lijkt te behandelen (hobby- of vermaaksystemen). Als we voor ons bedrijf afhankelijk moeten zijn van dit product, hebben we een leverancier nodig die meedoet en zakelijke behoeften begrijpt – die een productiegerichte instelling heeft. Als het product niet op de zakelijke markt gericht of zakelijk klaar is, moeten we ons daarvan bewust zijn. We moeten ons afvragen waarom we vinden dat we een dienst in productie moeten gebruiken, waarvan we afhankelijk zijn en waarvoor we ondersteuning nodig hebben, die niet bedoeld is om op die manier te worden gebruikt.

Wordt het ondersteund? Wordt het getest?

Iets wat vanuit het perspectief van klanten vaak over het hoofd wordt gezien, is of de noodzakelijke ondersteuningsmiddelen voor een product wel aanwezig zijn. Het is niet ongebruikelijk dat het team dat een product ondersteunt klein wordt, of zelfs verdwijnt, maar dat het bedrijf het product blijft verkopen in de hoop er zo veel mogelijk uit te persen, gokkend op het zich door een probleem heen worstelen of simpelweg het terugbetalen van klantgelden mocht de leverancier in een situatie belanden waarin ondersteuning eenvoudigweg onmogelijk is.

De meeste softwarecontracten bepalen dat de maximale schade die van de leverancier kan worden geëist gelijk is aan de kosten van het product, oftewel het bedrag dat is uitgegeven om het aan te schaffen. In een geval als dit loopt de leverancier geen enkel risico door een product aan te bieden dat hij niet kan ondersteunen – zelfs niet als er een meerprijs voor ondersteuning wordt gerekend. Als de klant erin slaagt het product te gebruiken, mooi, dan worden ze betaald. Als de klant dat niet kan en de leverancier het niet kan ondersteunen, verliezen ze alleen geld dat ze anders nooit zouden hebben gekregen. De klant draagt al het risico, niet de leverancier.

Dit suggereert natuurlijk dat er ook weinig of geen voortdurende tests van het product plaatsvinden, en dit zou een extra punt van zorg moeten zijn. Het feit dat het product draait, betekent niet dat het zal blijven draaien. Aan de slag gaan met een niet-ondersteund, of erger nog, niet-ondersteunbaar product, betekent dat je in de loop van de tijd steeds afhankelijker wordt van een product met een waarschijnlijk afnemend niveau van potentiële ondersteuning, dat langzaam slechter wordt naarmate de tijd verstrijkt, terwijl de behoefte aan ondersteuning en de afhankelijkheid van de software juist naar verwachting zullen toenemen.

Als een propriëtair product in productie wordt geïmplementeerd en de beslissing wordt genomen om af te zien van implementaties volgens best practices om aan de ondersteuningseisen te voldoen, hoe past dit dan in een beslissingsmatrix? Zou dit moeten impliceren dat er geen behoorlijke ondersteuning bestaat? Wederom, zoals eerder, duidt dit op een mismatch met onze behoeften.

 

Wordt Het Nog Steeds Ontwikkeld?

Als de implementatiebehoeften van de software oude, verouderde praktijken volgen, of verouderde (of niet redelijk actuele software of ontwerpen) vereisen, dan moeten we de waarschijnlijkheid in twijfel trekken dat het product momenteel nog wordt ontwikkeld. In sommige gevallen kunnen we dit bepalen door de softwarereleasecyclus enige tijd in de gaten te houden, maar niet in alle gevallen. Er is een gegronde vrees dat het product dood kan zijn, zonder een overgebleven ontwikkelteam dat eraan werkt. De code kan simpelweg oud zijn, technische schuld die wordt verkocht in de hoop er nog een laatste paar euro uit te slaan met een oude, verlaten codebasis. Dit proces komt in werkelijkheid veel vaker voor dan vaak wordt aangenomen.

Kleinere softwarebedrijven slagen er vaak in een eerste softwarepakket te ontwikkelen, het op de markt te brengen en beschikbaar te maken voor verkoop, maar zijn niet in staat om hun ontwikkelteam na de eerste release(s) te behouden of opnieuw te bemensen. Dit is in feite een veelvoorkomend scenario. Hierdoor blijven klanten achter met een product dat naar verwachting in de loop van de tijd steeds minder levensvatbaar wordt, met implementatiescenario's die steeds risicovoller worden en gegevens die steeds moeilijker te ontsluiten zijn.

 

Hoe Kan Het Worden Ondersteund Als Het Platform Niet Wordt Ondersteund?

Een veelvoorkomende paradox in sommige extremere situaties is software die, om als “ondersteund” te kwalificeren, andere software vereist die ofwel buiten ondersteuning valt ofwel nooit voor de beoogde toepassing werd ondersteund. Veelvoorkomende voorbeelden hiervan zijn de eis dat een serversysteem bovenop een desktopbesturingssysteem draait, of de eis van versies van besturingssystemen, databases of andere componenten die helemaal niet meer worden ondersteund. Dit laatste scenario komt angstaanjagend vaak voor. In een dergelijke situatie moet men zich afvragen of er dan überhaupt ooit een implementatie kan bestaan waarbij de software als “ondersteund” kan worden beschouwd? Als een deel van de stack altijd buiten ondersteuning valt, dan is de hele stack niet ondersteund. Er zou altijd een reden zijn waarom ondersteuning geweigerd zou kunnen worden, wat je ook doet. De reden waarom we daarom zouden eisen dat we best practices vermijden, zou er evenzeer voor pleiten om de software zelf in de eerste plaats niet te kiezen.

Ontbreekt Het aan Vaardigheden en Kennis in de Branche?

Misschien is het probleem waarmee we worden geconfronteerd bij dit soort softwareondersteuningsproblemen dat het team of de teams die de software maken simpelweg niet weten hoe goede software wordt gemaakt en/of hoe goede systemen worden geïmplementeerd. Dit behoort tot de meest redelijke en valide redenen voor wat ons in deze situatie zou brengen. Maar, net als de andere hypothetische redenen, laat het ons bezorgd achter over de kwaliteit van de software en de mogelijkheid dat ondersteuning werkelijk beschikbaar is. Als we de leverancier niet kunnen vertrouwen om de meest zichtbare onderdelen van het systeem correct af te handelen, waarom zouden we ons dan tot hen wenden als onze experts voor de onderdelen die we niet kunnen verifiëren?

Het Grote Probleem

Het grote, overkoepelende probleem met software die twijfelachtige eisen stelt aan implementatie- en onderhoudspraktijken in ruil voor het ontsluiten van anders achtergehouden ondersteuning, is niet, zoals we doorgaans aannemen, een kwestie van de algehele softwarekwaliteit, maar een van levensvatbare ondersteunings- en ontwikkelpraktijken. Dat deze kwesties duiden op een aanzienlijke zorg over ondersteuning op de lange termijn, zou ons sterk moeten doen afvragen waarom we deze pakketten in de eerste plaats kiezen en er sterke ondersteuning van verwachten, terwijl we vanaf het begin zeer zichtbare en zeer ernstige zorgen hebben.

Er zijn natuurlijk gevallen waarin er geen andere softwareproducten bestaan om in een behoefte te voorzien, of geen enkel product met een redelijkere levensvatbaarheid. Deze situatie zou uiterst zeldzaam moeten zijn en mocht een dergelijke situatie zich voordoen, dan zou die moeten worden gezien als een grote marktkans voor een leverancier die die specifieke markt wil betreden.

Vanuit zakelijk perspectief is het absoluut noodzakelijk dat de best practices voor de technische infrastructuur niet volledig worden genegeerd in ruil voor het blind of bijna blind volgen van leverancierseisen die in elk ander geval als roekeloos of onprofessioneel zouden worden beschouwd. Waarom verzuimen we zo vaak om op deze manier uitmuntendheid te eisen van kernproducten waarvan onze bedrijven afhankelijk zijn? Het brengt onze bedrijven in gevaar, niet alleen door de handeling zelf, maar veel meer nog door de risico's die worden geïmpliceerd door het bestaan van een dergelijke eis.