Are your applications ready to live in the cloud?
It's all in the preparation
So, you are ready for a journey to the cloud. You have evaluated the benefits and you think you are ready to migrate your applications to a castle in the sky.
But the road to cloudy happiness is a long and winding one. Getting your applications into the cloud takes preparation.
The first step is to nail down the motivation for the move. Cost reduction is usually a key motivator, as companies pool resources by virtualising their hardware.
Agility is another. Putting applications in the cloud makes it possible to provision computing power and storage faster and more flexibly than running them on dedicated tin. Cloud computing also helps regulate volatile demand.
After you port everything to the cloud, you will want to benchmark it against a set of assumptions made at the start.
Your success metric may be to reduce capital expenditure on hardware, for example, or to increase the reliability of your application infrastructure. Perhaps you are shooting for a more flexible infrastructure that lets you implement new enterprise applications more quickly.
Unfortunately, these kinds of applications are the ones subject to most resistance. Symantec’s Virtualization and Evolution to the Cloud survey (registration required) last year polled 3,700 companies around the world.
It found that mission-critical enterprise apps were less likely to be virtualised within the next 12 months, let alone managed as part of a private cloud environment. Instead, companies were choosing web apps, Office applications, email and calendaring for virtualisation.
A general perception of lack of control is holding companies back. They are worried about what virtualisation will do to disaster recovery. They fret about security issues such as authentication vulnerabilities, account hijacking and how to control an environment that is also running other applications.
Clearly then, if companies are serious about shifting applications to the private cloud, they had better make sure that the orchestration layer above the virtualisation part is pretty solid.
What does this involve?
The layered look
Virtualising your hardware so that your software can run without being dependent on a particular piece of tin is just one leg of the journey. There are pieces on top of this virtualisation layer that differentiate the cloud.
For one thing, the cloud’s attraction lies in its ability to absorb your computing headaches, but this can only happen if you do everything in the same way. The processes that form the basis of your computing service should be templated.
Provisioning, application patching, user account setup, storage allocation and recovery, application data backup and backup testing – all of these should be operated from a single playbook. Standardisation is what allows private cloud applications to scale.
Standardisation makes it possible to automate these processes. Their steps are well understood and replicable, so they can be codified using management tools.
This orchestration layer manages the location and operation of the virtual machines and applications in the cloud. It decides that your business analytics application can have some more MIPs during the overnight number crunching process, shortly after the nightly network backup and virtual desktop anti-virus patching processes have finished.
A chargeback mechanism is the icing on the cake
On top of all this sits a self-service layer, which provides the interface between the cloud and the users and lets them provision their own application services. It helps to automate the provisioning and customer service burden, just as the automation layer automates back-end processes.
A chargeback mechanism is the icing on the cake for organisations truly committed to private cloud computing.
The notion that you can charge customers based on the number of MIPS they use for business analytics apps, or the number of Gigabytes they are using for their document and mail storage, is a truly great idea, but of course they have to agree to it first.
The chargeback layer, perhaps more than any other, will require some frank conversations with business managers.
Preparing an application for the private cloud operation means preparing it for operation at all of these layers. It should be able to take advantage of the resource elasticity that cloud offers, along with its self-service and chargeback capabilities.
It must be easily deployed, automated in its management and dynamically scalable.
Different companies may be starting at different points on the road towards cloud-based applications.
Some haven't virtualised their applications or servers at all. Some have virtualised their hardware but don’t have the necessary building blocks in place to call their environment a private cloud.
Which applications make most sense for private cloud migration?
Some more equal than othes
Applications with resources that are under-used are good candidates, as are those that have limited capacity and are threatening business processes because they cannot cope with demand.
There are also other considerations that will affect an application’s suitability.
Consider, for example, its reliance on specialised hardware. If your application is mainframe-based, or uses specialised encryption hardware, the transformation process might be more difficult than if it is a generic x86 application that can be easily ported and automated.
Also, consider whether the vendor has an appropriate licensing mechanism for its application. If fully cloud-compliant, an application might be able to scale across thousands of processors.
This could be great for your business, but only if the vendor has a realistic way of charging you for it.
Finally, make sure you understand the business value of the applications you are considering for the private cloud.
It is important to separate out which are mission critical, which are adding significant value to the business and which can be given a lower priority.
Armed with all this information, you can create a transformation strategy for the applications in question.
This strategy depends largely on the architecture of the application that you are moving. How you move your apps and how much refactoring they require depends on how they are built.
Remember that moving your applications to the cloud needn’t happen all at once. A proof of concept phase is important to ensure that you can navigate your way through the practicalities of cloud migration.
Deploying a greenfield application to test the water is useful because it can reduce the number of application dependencies you might encounter.
Private cloud migration can be a daunting task, especially when moving a larger application portfolio, and you will meet both technical and organisational challenges along the way.
But with these basic rules you will at least be forewarned as you begin the journey. ®