//embedr.flickr.com/assets/client-code.js

Last week, at Google Next, there was a lot of talk about Apps built on the wonderful new abstractions and platforms cloud providers and PaaS providers are bringing to market.

These apps are sometimes called cloud native.  And in 2017, it’s the way to engineer new apps.

But what about the existing apps? The other 99% of the portfolio?  The answer for those is to migrate them, as-is, to the new cloud platform in the least disruptive way possible.

This “lift & shift” is sometimes dismissed and / or belittled by some of my cloud friends as not being real cloud.  They are correct. It’s not “real” cloud –whatever purity test that entails.

These apps won’t scale out or failover to a new region. In fact, the old apps running in the new cloud bring in all the old management processes such as ITIL into the new cloud environment.  The question is why even bother?

My answer: it’s a necessary transitional step towards cloud adopti0n.  Here’s why:

• You can’t re-write every app in a large enterprise in any cost effective or time relevant way.  So dispositions and priorities will have to be made and much will have to be migrated as-is.
• Apps travel in packs. If you have ever seen an ERP diagram of all the systems it touches, it becomes pretty clear the “APP” is in fact a composite of many sub-systems. You can’t just move one component; you must move all the ones which have to be together in one wave.  This is something we do at very large scale day in day out; so I see it in practice.
• Many enterprise apps are actually commercial off-the-shelf software  (COTS)products. In fact the core ERP systems are all COTS. The enterprise has neither the code nor the expertise to re-write these app and the vendor may have no plans to offer it as SaaS.
• For every app, a disposition has to be made. Re-write? Remediate? Modernize? Lift-and-shift? Remove? Leave as-is until end of utility?  The application portfolio view and the dependencies between components is a key piece of work to asses readiness to move to cloud.

The second bullet point is one of the main reasons to migrate (lift and shift) workloads to the cloud. New, cloud native apps that extend or replace components of the older app can more easily be considered once the old apps are in their new cloud hosting environment. From security to networking to assurance, all these processes can now be carried out in the new cloud thus spreading a set of fixed costs  over a larger set of apps.

Wither the datacenter?

Once an organization has committed to adopt public cloud, a mental clock starts ticking; what is going to happen to the datacenter?  Keep it, and for what? Renew the lease? Close it?

And if half the apps go to the cloud but half remain, will the application owners be happy if their hosting costs double? After all with fewer  tenants, the higher the allocation rent.

The reality is no app owner wants to be left holding the last app in the data center. This starts the planning cycle to shut down a datacenter.

You must vacate the premises by a certain date in order to free up the capital or opex and move to a cloud.

That’s the forcing function: avoiding a data center lease renewal or avoiding building one, and freeing up capital.  Hence the need for lift-and-shift.

People who are planning large migrations to cloud are aware that this doesn’t really change the quality of the service or make the app better, initially

But they know they will be in an environment with a richer set of services. Which sets the stage for app modernization.

A real case study: Accenture Cloud Platform evolution

My own area is a microcosm of what I just wrote.  I’m responsible for a software product offering called Accenture Cloud Platform. We architect, engineer and deliver a complete cloud management platform as a service, billed ion a consumption model. We offer a range of services, from cloud procurement, brokerage, cost analytics, managed billing, workflow automation and many other managed services.

In early 2014 we stirred, shook, and moved our apps from an internal data center to the cloud.  Our cloud management offering is made up of many underlying software components: three tier components (web, app servers, databases), open source components, COTS components (including one that requires a Windows Server), plus a variety of tools like back up servers, monitoring, patching, antivirus, application performance managers, user tracking, and more. An enterprise cioppino of software.

This whole stack si dedicated to delivering great cloud management services for our clients.  Step one in going to cloud? We lifted and shifted the entire stack to the cloud.

Once we were stable and comfortable in the new environment, we started modernizing.  No more SQL but now use SQL as service. No more load balancers, we adopted native DNS, and the native data warehouse.

At the end of 2015, we faced the need to build a whole new discovery and policy component for our offering. From managing thousands of VM’s, the next challenge requires us to manage billions of items.

We chose to go all in serverless for this new component; it would sit along side the older components (see prior post).  This May we will deliver brand new functionality for our offering; this time using a modern web-native stack.

This is why lift and shift is strategic. Once one can operate in the new environment, one has  the option to modernize and incrementally re-write components while adding value to existing operations.

In theory, one could execute this strategy without a massive lift and shift. In practice the cost of network modernization in the datacenter, the complexity of security design, and the need to modernize the old apps in the old infrastructure to make them “sufficient” to work with the new apps make this scenario unrealistic. Better to lift and shift.