In 2011 Gartner published 5 migration strategies. Eight years later let’s see how valid they still are and where are we in terms of evolution:
1. Rehost: The infamous “lift and shift” and I dare to diminish it under the following considerations:
It’d be a mistake to do a 1:1 deployment of the actual environment to a cloud equivalent. Let’s, for example, consider the migration of Windows 2008 and/or Windows 2003 single application servers which are critical to the business. And this is more common than it seems, 100s of applications are to this day running that way, ex: A 2 layer critical transactional service running front-end services in the form of a .net application and with a back-end of SQL 2005.
The L&S solution: Deploy the application to a high availability environment in at least 2 regions or zones with a high availability data back-end service like Amazon RDS or Azure managed instance which is an IaaS instance just wrapped as a “service”
On top of this additional considerations need to be taken: Traffic management, Data Security, Backup and Recovery, System integration, etc. In the end, those couple of servers might end up being migrated to 4 to 6 VMs, 2 in each region plus the database service. Very few of the Cloud benefits are leveraged using these mechanisms: Elasticity is one, if the application doesn’t support it, the service will become way more complex and certainly more expensive, independently of being run in the cloud.
Lift and Shift provide the lowest return in value and it’s the one to be avoided whenever possible. It might be the only alternative for applications that are at their end of life, the application can’t be re-factor for whichever reason, it’s urgent to move it to the Cloud, etc.
Another inconvenience of this strategy is that once the applications are running on the Cloud is very unlikely they will be migrated and/or re-architected. Especially in an organization where the journey to the consumption model has recently begun.
This is the first step to leverage the benefits of going to the Cloud, ex:
If you have dozens of terabytes of data stored on a SAN/NAS you’d want to migrate them to some of the following services:
- BLOB or SMB storage in Azure
- S3, FSX or EFS in AWS
There are certain changes to be made to the backend and to the application using these services, the vendor may or may not support the platform. If it’s in-house development with access to the source code, training the development team will take some time but nevertheless will bring a good set of long term advantages such as:
- Less cost of Ownership, no physical hardware to manage
- Automatic replication of the storage to a secondary zone or region
- Protection and recovery of deleted files
Much better availability, Microsoft provides up to 99.99% availability whereas AWS for S3 provides up to 99.9%
Also, the application would need to be aware of this geographic redundancy for the storage and manage failure and outages accordingly.
Things start to get harder as more of the Cloud services get used. The human resources factor will play a big part in this since it’s not very easy to get people with these skills and with the relevant experience. It’s also a good approach to train the in-house engineering team, they will be part of the transformation and they do know the organization much better than any external vendor or consultant.
One good step is to start using the serverless layer of the Cloud vendor, for simple things such as file transfer(s), file synchronization between two physical sites, etc. Both AWS and Azure provide a good set of tools for this.
This is the ultimate desire state, a dream come true for any computer engineer. Also, it’s the less likely to be taken especially if the organization is risk averse and/or has compliance to adhere to.
Nevertheless and as things evolve in a non-linear fashion the end state might be a combination of services. One of the most important reasons for migrating to the Cloud should be to evolve out of the monolithic state where many if not most of the applications are today.
- Virtual Machines are migrated to Containers and orchestrated by Kubernetes
- Non-relational databases move to Table storage or No-SQL
- Websites running on full servers are migrated to Web applications or Blob storage (assuming they’re static)
- Database Clusters are migrated to RDS in AWS or SQL PaaS in Azure
At the beginning of this post, I said I was going to evaluate the 5 migrations strategies and ended up talking more about each one in specific and additionally I only speak of four since decommissioning is quite clear in itself.
In my experience with customers I’ve worked in the past 6 years there are multiple combinations of maturity and that’s only one of the factors that will influence the migration and adoption approach.
Also, performing a big-bang approach especially inside an organization new to the Cloud might be too much of a cultural challenge. Usually, the firsts steps into it are via SaaS which in most cases is transparent to the end-users, Office 365 is a good example of this.
Let’s think of an example. All organizations have a public website which can be transactional or static. The best approach to run this workload might be one of the following:
- A SaaS Content Management Server, Magento is an example of this
- If it’s completely static with very few changes, S3 is a great alternative. Even for static sections of a website
- A content Management Server running on Virtual Machines, Adobe AEM for example.
The most expensive of these 3 options is the one with Virtual Machines, no doubt about it.
Once the organization is committed to moving to the Cloud and/or adopts the ‘Cloud First’ mentality the journey begins and it will take time and lots of effort and some times lots of emotion for such a large scale transformation
- Mind the fundamentals. Where do you want to go?
- Avoid the hype. Containers, Micro-Services, Serverless. All of them have their place and reason of existence and there’s a right way to implement and get the best value out of all of them.
- Get the right team and train the people, make them part of the transformation.
- Get a good strategist. Someone who can provide the length and depth in the vision of where to go
- Execute first and foremost. Forget about POCs, forget about the start of the project meetings, just sail straight into it. It’s easy, it’s extremely cheap and it’s possible.
Gartner’s Five “Rs” of Multicloud
Three Myths about Hybrid Architectures Using the Cloud
How to Go Fast