Virtualisation and packaged applications. When is a silo not a silo?

To the outsider, suggesting that such workloads as SAP, Siebel and so on should be candidates for virtualisation feels like a bit of an anathema.

Such packaged apps have a reputation for being monolithic and siloed, and perhaps inappropriate for running on a VM. Or indeed, if these are the flagship applications on which an organisation is depending, perhaps they are too critical to run on the same box alongside any of those pesky, and (dare we say) lower-class applications, such as web servers?

Much of this series has covered how virtualisation can move beyond pilot and into production, and to be sure, you don’t get more ‘production’ than your ERP or CRM system. So the virtualisation of packaged applications is not something to be undertaken lightly, particularly for organisations that have yet to familiarise themselves with virtualisation.

However, virtualisation does make sense in a number of areas associated with packaged apps. For a start, things are more complicated than the name “package” might suggest. For a variety of historical reasons, many organisations will be running multiple instances of such applications, both on production servers and for development and test purposes.

Management of such applications can be highly dynamic – existing production versions need to be patched at intervals, and new versions deployed. Meanwhile, as with other software applications, there are requirements around system availability and disaster recovery that need to be treated.

Virtualisation can, therefore, bring quite a lot to the party. It offers the ‘usual’ operational benefits of workload flexibility at peak resource times, ease of management, fault tolerance capability, (potentially) better performance and so on. In this context, as well as offering a half-way house for organisations suffering from packaged application sprawl – at least multiple instances (some of which may be less used) can be consolidated onto a reduced set of physical systems.

In terms of the deployment lifecycle as well, new versions of a packaged app instance can be released without the dependency on either deploying new hardware, or freeing up existing server resources. Indeed, given that workloads themselves can be checked in and out, the process of testing, deployment, upgrade and so on can take place in a more coordinated manner.

Patches can be tested on a snapshot of a live system, potentially on the same physical server, making life simpler for operations staff and reducing downtime for business users – though with the recognition that data privacy issues may exist, especially if customer data is involved.

What’s not to like? Well, as we know form other articles in this series, such benefits do come at a cost – not least that the virtual environment needs to be architected and designed correctly in the first place – for example in terms of storage access to avoid bottlenecks, or physical RAM allocation.

In terms of the databases upon which such applications depend, certain configurations are not currently supported – notably around clustering. I’m not a database expert, but it does make sense that virtualisation and clustering need to be handled with care, given that both deal with how workloads are distributed across physical servers. In terms of workload:server ratios, virtualisation offers an N:1 model, and clustering a 1:N model. Adding virtualisation into the mix does make things messy, and somewhat undermines the logic for using clustering in the first place.

Other areas of note are around licensing, which we discussed here, and vendor support – some vendors still require that a bug is reproduced on a physical server, though the word is that this is a worst case scenario from a troubleshooting perspective.

In summary, then, virtualisation does offer a number of benefits for packaged applications, which go beyond simple consolidation, into helping reduce friction in the way packaged apps are configured, tested and deployed. To take advantage of such benefits, however, requires a thorough understanding of how virtualisation fits.

If you have already learned from pilot experiences, or from using virtualisation in a test and development environment, you will have a good grounding in what can be done, and what you need to do to make the most of virtualisation in this context. Whether you have past experience or not, it is worth recognising the mission criticality of your packaged apps, and moving forward with appropriate care and attention.