The Lift-and-Shift Fallacy: Why It Will Cost You Time, Money and People
Are you ready to move your IT operations to the cloud? If you have become all too aware of the drawbacks of your existing IT system, it is easy to imagine that moving wholesale to the cloud will solve your problems and give you a fresh start.
After all, the cloud is flexible, fast, scalable, up-to-date, full of shiny, exciting new features, and is low on overhead and maintenance. Who wouldn't want to move there?
The truth is that cloud deployment has a great deal to offer. But it rarely pays to move to a new and radically different platform without having a clear understanding of how you should and shouldn't make the move. When it comes to making the move to cloud-based IT, there are many things that you need to understand clearly.
Moving to the Cloud: Conflicts
Let's start by taking a look at some of the problems that you are likely to run into if you try to simply lift and shift, without taking a close look at what you're doing, and why you're doing it.
Architecture
Cloud-based architecture is not on-premises architecture. It can be argued that the architecture which is most appropriate for cloud-based deployment (and is native to the cloud) does not, for the most part, even resemble the traditional architecture of software running on in-house servers.
What do we mean by this? Traditional software architecture is largely monolithic. An application consists of a single program (or a small group of programs and support files) containing all of the processes and services required for core application functionality. It can be very well structured, it can be object-oriented, it can be spaghetti, but from the outside, it's all just one big blob of code.
Microservices...
In the cloud, it is much more natural and convenient to deploy software in the form of individual microservices, each in its own virtual machine or container, and each handling one kind of function or responsibility. Individual instances of each microservice are created and destroyed as needed.
Microservice-based architecture is fast, versatile, easy to maintain, and makes optimum use of cloud-based system capabilities, such as dynamic resource allocation. It is also one of the fundamental factors which makes continuous delivery possible, since microservices can be replaced or updated individually, without requiring the entire application to be recompiled and tested.
...Not Monoliths
If you attempt to move a monolithic application to the cloud without refactoring it into microservices, you will lose many of the advantages of cloud deployment, and you will be bringing many of the problems of your existing IT model with you. You will probably wind up spending a considerable amount of time, effort, and money on measures designed to give it adequate resilience (such as adding multiple servers), and compensating for the inherent inefficiencies of monolithic applications in a cloud environment.
Wasted Investment
Moving to the cloud should mean starting over when it comes not only to architecture, but also to basic development and IT practices, and your entire deployment chain. The move to the cloud is generally an excellent time to shift from siloed development and operations roles to a unified DevOps team, if you have not already done so.
It is also likely to be a good time to take advantage of the unique features the cloud offers, and make the full move to an automated continuous delivery chain. If you don't do this, you may find that you have gained very little, except for the reduced overhead from outsourcing server hardware and maintenance. Just about everything else will be a wasted investment.
The same holds true for your IT staff. Once they are trained in the skills required for basic cloud deployment, it is natural for them to want to put those skills to full use. If, however, your cloud transition is minimal, and you’re retaining such things as monolithic architecture, and a drawn-out, intermittent development cycle, they are likely to feel frustrated, and may look for jobs where they can make better use of their new skills.
Moving to the Cloud: Resolutions
What can you do to prevent problems such as these?
Priorities
Before you lay out a migration roadmap, look at your priorities, and make sure that you are focused on the things that matter. The competitive advantages of moving to the cloud should be a major concern. If you are in an industry where your competitors have already made the move to the cloud and are showing obvious benefits from having done so, you have a strong incentive to make the move yourself.
The same is true if your competitors aren't cloud-based, but you can see ways in which moving to the cloud will give you a clear advantage. On the other hand, if there are elements of your IT system that would give you no advantage if they were moved to the cloud (as might be the case, for example, with a system for automated control of factory floor equipment), then you will need to take that into consideration.
Similar considerations hold true for such factors as time to market, and the rate and quality of change to be expected. A slow and rough transition to cloud deployment may be costly. The time taken to plan a smooth transition is likely to be more than worthwhile, even if it means a significant delay in the first stages of rollout.
Lighthouse Projects First
The first stage of the actual cloud transition should focus on one or more lighthouse projects. These are small-scale projects for moving relatively small auxiliary applications or systems to the cloud. A lighthouse project is as much a test of the transition process as it is a conversion project, so it should incorporate all aspects of the system development life cycle, allowing you to identify and overcome potential problems and bottlenecks, and serve as a model for later and larger cloud transition projects.
One of the major functions of a lighthouse project should be to give your development team practice in decomposing a monolithic application into microservices. To be a truly adequate lighthouse project, it should require full refactoring into microservices.
Migrate When It Makes Sense
The truth is that you don't need to (and probably shouldn't) migrate everything to the cloud at once. In fact, when it comes to existing applications, a very good basic rule is that you should only move them to the cloud when there is a tangible benefit to doing so.
If your spare-parts warehouse inventory database is doing quite well on your local server, it can stay there. However, if the time comes when the local server is inadequate for spare-parts inventory (for example, you have several warehouses in widely separated locations), then you can set out plans for its migration.
By following a few simple guidelines such as these, you can make the move to the cloud everything that it should be, and avoid the pitfalls of lift-and-shift.
