General Manager & Partner | Azure MVP
Note: This is a continuation of a previous article regarding migration to the Cloud you can find here.
So you are a bit more convinced that the Cloud might be a solution to you. Do you have a plethora of solutions running on premises, or maybe just one simple server with an ERP on it?
How do you proceed?
How do you make sure your migration is a success?
The term “Lift and Shift”, used by a lot of managed services companies, us included
, is used to describe the process of taking your local infrastructure and moving it “as it is” to the Cloud, in an Infrastructure as a Service hosting type.
This is, as opposed to migrating the solution to Platform as a Service, which basically means taking advantage of the services the Cloud provider might offer, to reduce the complexity and management work of your infrastructure.
In a nutshell, here is a comparison between the two models:
Even though this approach is much less risky than migrating to PaaS (which could mean re-architecting your solutions, and changing the code of your applications), it is still not quite a walk in the park. There are a few things to consider, and I list here just a few of them.
Modern or legacy solution?
Did we write/purchase the solution many years ago, when nobody was thinking about distributed systems? How about the ability of the solution to run in parallel on multiple servers, with a load balancer in front of them?
I won’t get too technical, but for legacy systems moving to the cloud might pose some problems. Recently, Microsoft Azure for example has done a great job in removing such risks, because even for such applications which weren’t designed for distributed workloads, we have the Load Balancers who can take care of this by enabling Session Stickiness or Client Affinity (both the LB from IaaS, which is a level 4 LB, and the LB from Web Apps which is a level 7 LB, can take care of this in at least a minimal way).
In theory, you take your local solution and move it to the cloud in a 1:1 manner. But it is not quite so in reality. Because you might want to change some parts of your solution in order to better benefit from the Cloud, for example:
- Your local solution is monolithic. You have both the web server and database server on the same machine. When you go to the cloud, you might want to be able to scale those independently – meaning you want your web fronted isolated from the database to better use the resources.
- On premises, you use something like a daemon, or a cronjob, or a Rabbit Queue, or a MSMQ. All of these have better correspondents in the cloud – meaning, services provided to us (without the operational burden on us) – and you might want to replace the local components with the services in the cloud.
So, this might affect your topology. If on premises the web server was “near” your database (calls on the same machine are an order of magnitude under 1 millisecond), the web server calling a database service in the cloud means TCP access (milliseconds per call). So, beware of such changes, think where your solution is very chatty and address those areas – sometimes with changes in code.
Because the cloud is not under our desk, the typical latency is somewhere around 40-50 milliseconds for a call to resources in the Cloud. If your users or some software clients of your backend in the Cloud need smaller latency, consider technologies like Azure Express Route, with smaller latency (under 10 ms) and guaranteed bandwidth.
A migration to ANY Cloud provider brings some degree of lock-in-ness. The moment you start moving away from using just Virtual Machines, the moment you incorporate services like SQL Azure Database, Table Storage, Cosmos DB, etc. – all great services, in your solution, that moment you become linked to that specific Cloud provider.
Moving your solution to another Cloud provider would mean replacing those specific services with their counterparts (if they exist, they usually do) from the new provider. And that means cost. So, choosing the Cloud provider is a very important decision, not only but also because of this aspect.
Even though the Cloud is great, there will always be scenarios for on premises workloads. Or even more: hybrid workloads – having parts of the solution in the Cloud, and parts of it on premises. For example you are a big enterprise and you have some customers’ front-facing applications, all of which use some backend / middle-tier components (web services), which in turn are linked to an ERP and some analytics databases. You might want to move the frontends in the Cloud so your users will experience a much better interaction (the cloud is auto-scalable), but you cannot move the backends, ERP, and some critical databases – which are used by a lot of internal systems as well. This situation is called hybrid, and it probably involves VPNs, Express Routes, or some infrastructure technologies like these.
A great technology from Microsoft is called Azure Stack. This is great specifically in hybrid scenarios because Azure Stack is using the exact same technology as Azure. Meaning: the same way to create and manage resources in Azure and on premises with Azure Stack. Which means less operational and management work: you have the exact model, the same technology, the same tools to monitor and operate your workloads, wherever they are.
Lift and Shift is usually the first approach towards the cloud we have seen with our customers. It involves less risk, it gives benefits immediately to our customers, it helps them learn how to work with the cloud, but still should be taken seriously.
Mihai Tataran, is the General Manager of Avaelgo, and a Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers.