Applicatie Virtualisatie, last of verlichting

De toepassing van applicatie virtualisatie is binnen veel bedrijven de afgelopen twee jaar behoorlijk toegenomen. Omdat het beschikbaar stellen van werkende applicaties behoort tot de belangrijkste en meest kritische elementen van de bedrijfsvoering, zijn veel organisaties geneigd om dit zelf uit te voeren of te besturen. De processen die hierbij horen zijn vaak overgenomen uit de tijd van klassieke software distributie. Verouderd dus?

Bij traditionale software installaties moet iedere processtap die genomen wordt de kwaliteit van de applicatiedistributie verbeteren of waarborgen. Dit was nodig omdat fysieke applicatieinstallaties het doelsysteem veranderden en daarmee negatieve bijwerkingen konden veroorzaken. In het meest gunstige geval werkte de zojuist gedistribueerde applicatie niet, maar in veel andere gevallen werd de werking van andere applicaties of zelfs het onderlinge operating systeem verstoord. Met als gevolg dat gebruikers niet of niet optimaal konden werken hetgeen productieverlies betekent voor de organisatie. Het herstellen van deze situatie is ook niet eenvoudig. Meer dan eens blijkt dat de deïnstallatie van het laatst geïnstalleerde product geen oplossing biedt omdat niet alle installatiestappen omkeerbaar zijn. Na deïnstallatie blijven toch nog geïnstalleerde elementen achter of foutieve instellingen onveranderd. Om dit op te lossen moet vervolgens niet meer de applicatie maar eigenlijk het gehele onderliggende systeem geanalyseerd en waar nodig (handmatig) hersteld worden.

De komst van applicatie virtualisatie lost veel van deze traditionele uitdagingen op. Virtuele applicaties kunnen geen conflicten meer veroorzaken, hebben geen negatieve invloed op de stabiliteit van het onderliggende systeem en zijn daarmee makkelijker te distribueren. Doordat de feitelijke installatie niet plaats vindt blijft er na deïnstallatie, wat eigenlijk niet meer is dan deactivatie, ook niets op het systeem achter. Eenvoudiger dus en daarom goedkoper…toch?

In de praktijk blijkt dat veel organisaties weliswaar de applicatie virtualisatie technologie adopteren, maar de implementatie voornamelijk technisch benaderen. De voorgaande technische methodiek wordt vervangen door een nieuwe. Zelden worden ook daadwerkelijk de processen rondom de applicatie distributie aangepast op de efficiëntie van de oplossing. Als de processen niet worden geoptimaliseerd of verkort dan zal er ook geen besparing worden gerealiseerd. Sterker nog, door een initiële investering van bijvoorbeeld software licenties, infrastructuur en opleiding van medewerkers, wordt het zelfs duurder! Daarom is het belangrijk om eens kritisch naar de processen rondom virtuele software distributie te kijken.

Geen conflicten

Virtuele applicaties kunnen geen conflicten met elkaar hebben, dat wil zeggen dat de stappen in het proces die hiermee samenhangen geschrapt kunnen worden. Regressietesten zijn niet of hooguit beperkt nodig. Testprocedures van individuele applicaties kunnen sterk vereenvoudigd worden omdat de stabiliteit op de werkplek niet hoeft te worden beoordeeld. Er kan gefocust worden op een technische (distributie) en een functionele test. Het zou zelfs mogelijk zijn om de test uit te voeren op een productiewerkplek van een (vrijwillige) eindgebruiker. Het ergste scenario is dat de applicatie niet werkt en teruggetrokken wordt van de werkplek, aangevuld met hooguit een mopperende gebruiker.

In de tijd van traditionele software distributie maakten we ons druk over wat er wel en niet in het distributiepackage mocht zitten. Alleen wat bij de applicatie hoorde mocht blijven en de rest werd verwijderd. Niet alleen was dit een zeer tijdrovende bezigheid, het was ook lastig om vast te stellen. Pas bij de feitelijk test van de applicatie kon met zekerheid worden bepaald of er niet te veel verwijderd was.

Bij virtuele applicaties moet vooral geconcentreerd worden op de functionele werking en is de inhoud van de package totaal niet interessant. De inhoud is vaak niet eens zichtbaar voor de eindgebruiker. Er is dus geen noodzaak om de virtuele omgeving uitgebreid op te schonen van zaken die misschien wel, misschien niet bij de applicatie horen. Er zijn hooguit twee uitzonderingen op deze regel. Op de eerste plaats moeten er geen zaken in de virtuele package zitten die de werking van de applicatie kan beïnvloeden. Meestal zijn dit systeeminstellingen die per ongeluk tijdens het virtualiseren zijn opgepikt. Op de tweede plaats is het verstandig om te kijken of de oorspronkelijke installatiebestanden niet per ongeluk zijn opgenomen in de package. Dit kan de package onnodig groot maken.

Het applicatie delivery proces kan niet alleen op een aantal vlakken sterk vereenvoudigd worden, maar zal ook uitgebreid moeten worden. Zo is de relatie van een applicatie met andere applicaties een belangrijk element geworden bij de toepassing van applicatie virtualisatie. Wanneer applicaties fysiek geïnstalleerd worden kunnen ze eenvoudig van elkaars diensten gebruik maken. Een virtuele applicatie draait echter in een geïsoleerde omgeving. Geïnstalleerde applicaties werken binnen veel bedrijven vaak omdat een afhankelijkheid toevallig op het doelsysteem aanwezig is in plaats van dat deze bewust geïnstalleerd is omdat de relaties volledig inzichtelijk zijn. Als een virtuele applicatie contact moet hebben met een andere virtuele applicatie dient die relatie expliciet te worden gemaakt. Inzicht in de onderlinge relaties is bij toepassing van deze techniek dus een must.

Kortom: mijn advies is om bij de toepassing van applicatie virtualisatie ook de processen te veranderen. Durf te innoveren met de mogelijkheden van deze nieuwe techniek. Probeer, wanneer applicatie virtualisatie nog niet wordt gebruikt, op voorhand een goede implementatiestrategie te bepalen. Laat je adviseren over bekende valkuilen en uitdagingen. Denk daarbij ook aan een strategie voor applicaties die niet te virtualiseren zijn. Maak van de toepassing van applicatie virtualisatie geen last, maar een verlichting!