A phrase you might hear around cloud computing is lift and shift. In this model you effectively take your existing application and move it, wholesale, into a cloud environment such as Amazon EC2. There’s no re-architecting of the application; there’s no application redesign. This make it very quick and very easy to move into the cloud. It’s not much different to a previous p2v (physical to virtual) activity that companies performed when migration to virtual servers (eg VMware ESX).
Naturally, since you’re running in the cloud, you have great availability and scalability. Job done, right?
Well, that depends on the problem you’re trying to solve.
By performing a “lift and shift” you haven’t solved your resiliency or reliability issues. You haven’t solved your backup issues. You haven’t solved your security issues. Indeed, these issues may become worse, as we’ll see.
Underneath your cloud instance is a physical machine. Physical machines need patching or repairing. This is scheduled downtime that is now out of your control. Your cloud based operating system instance could be shut down and rebooted without any notice. This means you still have to build old-school “high availability” solutions; clustering, fail-over, etc. Because you may not get any notice this HA solution needs to be better automated than you might already have.
Because you’ve just copied your existing solution into a cloud you still have to manage your operating system instances; that means user identity management, audit trails, change controls and so on. However this cloud instance may be (likely will be) outside your security perimeter so now you need to extend your Identity and Access Management systems to that. Worse, you now also have to control access to the cloud provider’s dashboard; who is allowed to spawn new virtual machines, change network definitions, firewall rules?
Security scanning of your environment hasn’t gone away either; you need the same level of control (patching, vulnerability management, etc) as you had before.
Your cloud provider may give you nice resilient disks; that’s nice! But resiliency isn’t the same as a backup solution. You still need to backup your files (e.g. for 7 or 10 year retention to meet audit requirements).
All of this may work out more expensive than doing it in house. People look at Amazon and say “wow, that’s cheap! So much cheaper than my company can provide a virtual machine for!” And the up-front number is cheaper. But then you add in all the additional tools that you use (I&AM, vuln scanning, logging, network traffic, backups, patching…) and notice your in-house cost has all that bundled in and it can easily turn out that your cloud instance works out more expensive.
So with all these negatives, why would you “lift and shift”?
Well, it’s not a once size fits all problem. A large mega-corp running 30 datacenters should be able to provide virtual servers cheaper than Amazon. But a small company that only needs 100 servers? Or only has a couple of datacenters? Well now the equation isn’t so clear cut. It may well be worth effectively outsourcing the datacenter to a cloud provider. Why go to the hassle of maintaining physical servers, needing physical security guards, staff to manage the HVAC systems, NOC teams to replace failing kit…
Having your kit in the cloud can also help you migrate to a more modern architecture; once you’ve got an API driven infrastructure it becomes easier to look into building apps and environments that can start to make use of auto-scaling, micro-services, resilient architectures, 12-factor apps…
Conclusion
“Lift and shift” is a viable model of using cloud computing, but it’s not a panacea. You have all of the management challenges of running in your own datacenter (or co-located datacenter); you need to manage your servers, build HA solutions, replicate data, have backups etc etc. It may, initially, even cost you more money than you expected.
But once you are there you can start to take advantage of other features; want to use Apache Spark? Amazon already have this pre-built; you don’t need to engineer that yourself. Want to make use of multiple datacenters, close to your customers? They have plenty of points of presence to assist in that.
Don’t go looking at the problem as “We need to be in the cloud! Let’s lift and shift”. Instead look at the use cases; would it make sense to re-architect and rebuild your app to be more “cloud native”? Maybe even something simpler… perhaps you’ll find you don’t need to run your app 24x7; only spin it up one hour per day…
“Lift and shift” is one of the crudest methods of getting into the cloud. But it doesn’t make it a bad way of doing it. It’s just another tool in the toolbox.