How to give your applications a long and happy life
From cradle to grave in the Cloud
Are your applications well managed? Many companies get it right for part of an application’s lifecycle but few excel at all of it.
Putting an application into a private cloud can help you to manage it more consistently from cradle to grave.
Software applications need different resources at four main stages: development, deployment, maintenance and decommissioning.
At an application's birth, developers need to test its functionality and performance with a high degree of flexibility. They need development machines and virtual users.
In its operational phases, they need deployment servers, storage and other system resources.
And at the end, they need resources for the application’s retirement, including archival storage for data. Providing these resources efficiently at different stages of the lifecycle can be challenging.
Running an application in a private cloud environment changes the rules of the game. Each stage of the lifecycle alters because the available resources change.
A testing time
In the development phase, it can be difficult for application developers to find enough server resources. Provisioning a test system can be a lengthy process in an environment that is not virtualised.
Just because many systems operate at 10 per cent usage doesn't mean that a developer can simply claim the other 90 per cent of CPU time.
In a private cloud, however, provisioning of test servers is easier. Computational spikes caused by performance testing can be absorbed into the overall workload.
Automating key processes is an important part of the cloud concept
This is particularly true of performance testing, which can be especially resource-intensive. A private cloud can scale more readily to meet these needs.
Automating key processes is an important part of the cloud concept, and this is especially true when making test servers available to developers.
When they are ready to test an application, they should be able to provision a test server using a self-service portal.
That provisioning process should load everything necessary: not only the operating system but any additional elements such as code libraries and tools that support the testing process.
As always in private cloud operation, the benefits come with standardisation and automation.
A cloud-based environment can change the pace of the development cycle because functional changes can be introduced far more frequently.
This is particularly true if an organisation has layered platform-as-a-service (PaaS) functionality onto the basic infrastructure-as-a-service offering that typifies a competent private cloud.
PaaS deployments can introduce common application resources that make the deployment of cloud-based applications a higher-level activity. It has the potential to re-use software resources, decreasing the complexity of each application.
But for any of this to work, the development process must fundamentally alter. Traditional software development lifecycles tend to prioritise monolithic development, where large chunks of functionality are delivered over a relatively long time.
An agile cloud development process changes all that, dramatically shortening incremental development cycles and making tests far more frequent.
Mind the gap
In this way, running applications in the cloud closes the gap between development, growth and maintenance.
Making the development cycle more efficient makes it easier to add functionality to applications during the growth phase. This post-deployment phase is when development teams can create incremental versions of the software to accommodate changes in scope.
Being able to retrieve and manipulate software builds and then provision test servers makes it easier to manage a rapidly updated set of iterative rollouts.
This ease of deployment can also make it easier to maintain systems by closing the gap between development, testing and deployment.
Rolling out maintenance code can be an easier process in a private cloud than rolling out code to individual client machines.
Time to retire
Perhaps the most significant change the cloud brings to applications is in the retirement phase, when management teams decide that a software application should be discontinued.
HP and CapGemini's 2011 Application Landscape Report revealed that 60 per cent of all respondents said they kept data for retired applications beyond its expiration date, just in case it was needed.
Almost a third of respondents agreed that up to one in 10 applications should be retired, and another half suggested that between 11 per cent and 50 per cent of applications are candidates for decommissioning.
Yet fewer than one in five respondents listed decommissioning as a likely strategy when rationalising applications.
Application decommissioning costs money: data must be archived, for example. Yet few companies allocate funds for application retirement, according to the survey.
This is another area where private cloud infrastructure can help. Data can be archived relatively easily because storage can be provisioned more easily.
Old habits die hard
Still, a private cloud infrastructure is not a panacea. Without the right disciplines, application lifecycle management teams can run into difficulties.
Cloud-based applications’ shorter development cycles may mean quicker functional improvements for users, but it also forces development teams to adapt. Changing the way they are used to developing and maintaining applications can be daunting for some.
The shift in development pace also encourages a shift in testing procedures, moving the emphasis from unit testing to functional acceptance testing. Development and deployment teams must be ready for this transition.
Another challenge in application retirement is that some functions may still need migrating, which requires developer input.
Challenges such as these s at all stages of application lifecycle management can often make it more appropriate for some applications to be managed outside the cloud.
A mix-and-match approach can often be best, with applications residing inside or outside the cloud based on specific architectural characteristics and the readiness of the development team to handle the change.
The important thing, as ever, is to focus on the application rather than just the infrastructure.
The cloud, after all, is there to serve the software and not the other way around. ®