When clients say “We want to get all our applications onto the cloud.” Our is always: “Why would you want to be just ‘on’ the cloud?”
The difference between being “on” and being “in” the cloud might seem a minor nuance but in fact there’s a world of difference. “On the cloud” means operating largely the same way as before – the same applications running in the same way on a bunch of servers that are now on the cloud rather than on-premises or in a co-located datacenter. The IT benefits are marginal and the business benefits can be non existent.
This anachronistic approach is a legacy of the ‘lift-and-shift’ approach used for the last decade or so by SIs and datacenter vendors. They have migrated applications at a server level from the old datacenter to a new datacenter or from vendor to vendor as contracts change. In those environments the “transition and transform” approach made sense.
In cloud though, this approach is flawed and detrimental to cloud adoption in the long term.
As AWS’s strategy head Stephen Orban describes in his excellent ‘6Rs’ approach to cloud adoption, lift and shift is just one of six options – and even so he describes it as “lift-tinker-and-shift”. The difference with being “in” the cloud means taking advantage of the powerful capabilities that cloud provides such as elasticity, micro-service architecture, infinite storage and so on. An application that is truly “in” the cloud extracts maximum advantage from all of these.
A simple example is when migrating a classic three-tier application to cloud. In this use case continuing to run a bunch of servers to host databases makes little sense. Instead cloud enables you to get off the patching and server operations treadmill and use a service like Amazon RDS or Azure Database. Application teams care little about the underlying servers, typically they see a database endpoint and what they want is a scalable database that provides the resources and capabilities they need when they want them. This is the “re-platform” option of the 6Rs.
Moving an application “into” the cloud enables app teams to re-architecture and re-factor the application to take advantage of low cost, charged-per-unit microservices and – as cloud competency amongst the app teams builds – perhaps move to a serverless architecture.
Of course, none of this is helped by the array of migration tooling available, nearly all of which is focused on discovery and migration orchestration at the server level, which promotes this lift-and-shift mentality.
Instead, organisations adopting cloud need to take an application-centric view of their estate and understand the servers, environments and components that make up those applications then use this to plan and execute effective migrations.
In the modern world no application is an island and it’s imperative to understand the interfaces – or the affinity – between applications. A robust interface map, enables an organisation to gather its applications into sensible migration groupings, which de-risks the execution and ensures data feeds don’t break.
This doesn’t mean that lift-and-shift doesn’t have a place. In a number of use cases it certainly does, for example, with very simple applications and servers, or where there’s a clear cost benefit to coming out of a datacenter. It could also make sense at the end of a datacenter or service contract when time is of the essence.
Additionally, as the profile of organisations adopting cloud moves from the pioneers, to the settlers and on to the city planners this latter group favours a more risk-averse approach. By combining an application centric view with the 6Rs, they can create a successful multi-phased migration plan.
Another approach (of the many available) involves migrating on an environment-by-environment basis leading with a lift-and-shift for dev and test. This enables the application and support teams to build familiarity with cloud in a low-risk way. As they develop cloud competence they can migrate the non-live environments such as DR. Having developed their skills and experience with cloud, the application team can choose whether to lift-and-shift (transition and transform) production or to build a cloud-native production environment and re-platform onto it.
Clearly, there is no one right way to migrate to cloud but continuing to use traditional lift-and-shift approaches carries the risk of kicking the technical can down the road. It means opting to continue to be held back by long-standing technical constraints and instead of profiting from the game changing capabilities that the cloud offers.