You have application workflows running in a data centre. For the sake of argument, we can say that this is a J2EE application running on a WebSphere cluster that references data in a relational database.
Many issues may arise here – the contract with the data centre provider could be nearing completion, the hardware might be close to end of life or there could simply be a plan to move to a cloud provider as part of an ongoing strategy.
This is where we enter the realm of practical architecture. In isolation, it would seem the commonly held view that all applications should be architected for the cloud would apply here. This is not, in itself, a bad idea. In an ideal world, we would go back to the original business problem and solve that; this makes sense because the current implementation was a point-in-time solution to a specific problem.
If we determine the business problem is still the same, this leads us to one desired outcome – ‘application X running on AWS’. However, a key thing to remember when moving to the cloud is that dynamically scalable compute, storage and networking is not a direct copy of an existing data centre; there are considerations that are specific to the cloud. These are particularly important where there is a need to automatically scale applications based on load. So, one of the considerations for the target state architecture is, “Will this application need to automatically scale up/down based on load?” This would not have needed to be considered for the current application architecture. Capacity planning, resilience and redundancy considerations would have been considered, and these requirements would have been met by a combination of clustering and specifying infrastructure to cater for expected peak load.
To take advantage of the elastic nature of cloud infrastructure, the application architecture needs to be designed appropriately. An existing application infrastructure is very unlikely to be able to take advantage of this capability.
This is where the principles of simplification, practicality and transitional architecture are useful. We know that the desired end state is for the application workflows to be running in the cloud and to take advantage of elastic infrastructure. This is the best way to optimise cost and maximise business benefit.
When we look at what needs to happen, there are a few things to consider:
- Defining the application infrastructure in the cloud
- Rewriting the application to leverage elasticity
- A change in operational processes to support deployment and management of cloud applications
Operational change is mandatory in any situation, but we do have some scope for simplification within the other two. If we break the path to the end state into a few steps we can mitigate some of the delivery risk in the transformation project. These steps separate the infrastructure and application transformation.
Minimise what you are changing
The first step is to perform a lift and shift of the application. This requires replicating the data centre environment in the cloud. The operational processes to support and maintain the production application will need to be completed during this phase. Once this is done, the second phase can be performed without the pressure of needing to meet the data centre exit date.
The second step is to rewrite the application to take advantage of the elastic scalability of the cloud. The benefits of separating this step from the first one are twofold. Firstly, you keep the amount of things changing to a minimum. Secondly, you can take the lessons learned about the operational impacts of running cloud applications and apply them to the second step. With some experience of managing your chosen cloud vendor, you stand a greater chance of success in defining and supporting the end state architecture.
Over the course of the transformation program it is only the platform or the application that are changing, not both at the same time.
In conclusion, while some projects may be candidates for application rewrite and migration, consideration should be given to breaking down the transformation into manageable steps.
The following principles can be applied to most situations of this kind:
- Simplicity: change only what you need to in each step.
- Transitional architecture: you don’t have to jump directly to the end state.
- Be realistic about what can be achieved: take small steps along a well-planned path.
- Successful delivery is the best way to maintain stakeholder support.
This post was written by Paul Hawkins