Migrating from AWS to Azure: What We Learned
What is Cloud Migration?
For anyone trying to wrap their head around cloud migration—or if you’re just looking for an easy way to explain the concept to your less tech-savvy colleagues—consider the following analogy:
Imagine your office has an intern who gets lunch for everyone each day from the local sushi restaurant. The intern is well accustomed to this task and knows all the ins and outs necessary to complete it; they know the route to the restaurant, which menu items are particularly good, and they’ve learned the tricks for ordering.
One day, the office decides to change things up for lunch by ordering from the local pizza restaurant instead. The intern still has the same basic task (i.e., ‘Get Lunch’), but the approach that worked for the old restaurant won’t necessarily carry over to the new one. Maybe you need to ring a bell to access the sushi place but knock three times enter the pizza one, or the former can be reached via subway but getting to the latter necessitates driving.
These may sound like trivial complications, but they can lead to bigger issues if they aren’t anticipated.
You can understand cloud migration in much the same way: it’s not a daunting task, but it is one that requires forethought and planning. If you drop a brand-new lunch order for +30 people on a hapless intern at 11:55am, don’t be surprised when you don’t get what you wanted.
Differences Between AWS & Azure
The services between these two clouds are generally comparable, in the sense that most services that AWS supports, Azure supports and vice versa. However, it’s important to note the few areas where these cloud providers diverge, since there are some subtleties in how you have to set up in the cloud to which you’re migrating.
One of the biggest differences between AWS and Azure lies in asset access management. Azure uses Microsoft’s Azure Active Directory, which manages permissions using domains and email addresses, while AWS Identity and Access Management operates on the traditional user model.
The difference in authentication mechanism will definitely change the way your app authenticates to the different services when you’re doing a migration. For example, while it is possible to set up automatic authentication or code lists on Azure with managed identities, it’s not yet supported across all services and programming languages.
There are several important differences between Azure and AWS from the perspective of machine learning (ML). In our experience, Azure Machine Learning Service and AML Studio make the development and deployment of ML models faster and easier. Additionally, Azure’s partnership with Databricks makes it easier to use Spark and Spark-related services for running ML models. On the other hand, AWS recently released a service called SageMaker Neo that enables running ML models anywhere in the cloud and at the Edge, which is still not available with Azure.
Another difference that we kept running into: C# is a first-class citizen on Azure. For example, AWS provides codeless authentication across almost all of their services but Azure only has it across half of their services, at least when it comes to Python. So, if you’re using C#, you’ll be supported, but Azure is not quite there yet with other languages, like Python or Java.
You can see it in the support posts; a lot of the examples are C# and other Microsoft technologies.
Most of these differences can be boiled down to the fact that AWS is a more mature cloud than Azure. Granted, Microsoft has made impressive progress catching up, but Amazon did have a four-year head start. And sure, AWS may be more mature, but that doesn’t mean you can do more with it than you can with Azure—it just means some things are easier. A big part of that is the community: more AWS users means more blog posts.
It’s also worth noting that there are some things Azure gets right because it’s newer. We like the permission structure in Azure a lot better because, unlike AWS, we didn’t have to write a lot of JSON for custom policies. We had lots for AWS, but we haven’t made a single one for Azure.
We also prefer Azure’s approach to resource groups, where everything has to be attached to a resource group or inside a resource group. That’s the focal point of all your resources. In AWS, you can essentially create resources at a whim—which means you can lose track of them—so they might be running or sitting idle somewhere without you knowing. In Azure, it’s very clear that your resources are in resource groups and you can just delete them.
Both clouds support DevOps practices via CI/CD, but while AWS CodeBuild, CodePipline and CodeDeploy all fall under the AWS umbrella, Azure DevOps (formerly known as VSTS) operates under a separate portal with a distinct UI.
For more information, this comparison of AWS and Azure services may be helpful.
AWS to Azure in 5 Steps
For all the subtle differences between AWS and Azure, we found migrating from the former to the latter to be relatively straightforward. As is often the case with infrastructure, the majority of the work happens in the planning stages, prior to the actual migration itself. Our process can be broken down into five steps:
The first thing you’ll need is a list of the services you’re using on your current cloud provider and a list of the available equivalents on the new one. Obviously, the Azure and AWS APIs are slightly different, so you’ll need to figure out what basic tasks your apps need and how to do those tasks using the APIs from your new cloud provider.
Returning to the analogy from the beginning of this post, this is equivalent to confirming that your intern will still be able to (for example) carry everyone’s lunch back to the office if they’re hauling pizza rather than sushi.
Cloud migration is a team effort, from planning to execution. As a team, you’ll need to decide how you want to set things up in the new cloud and identify any potential issues. For us, it was deciding things like, “Okay, we want a Kubernetes cluster here, we want a PostgreSQL database there, we need load balancers for this and this,” and so on. We also used this as an opportunity to make some application and infrastructure changes that came up in discussion.
In our analogy, this is the part of the lunch order where everyone settles on what and how much the intern is getting. That might seem trivial until you consider the chaos that would ensue in the absence of any communication for an office lunch order. How could we expect our poor intern to handle 30 independently ordered pizzas?
Even the best laid plans rarely survive collision with reality. Despite all the preparation and internal consultations you’ve done in anticipation of your cloud migration, it’s possible that there’s something that hasn’t occurred to anyone in your organization.
But, hey, that’s what tech support is for, right?
In our case, Microsoft was willing to look at our architecture and discuss potential problems, which was a big help. If someone in your office is gluten-free, you wouldn’t send the intern for pizza without verifying the restaurant they’re going to has GF options, would you?
This is where the rubber actually meets the road: creating the root domain for the active directory, making user accounts, letting them in, creating a Kubenetes cluster, setting up data storage services, migrating the data, etc.
The analogy here should be painfully obvious (but just in case it’s not): This is the part where the intern actually gets pizza for the first time.
Although your migration is technically complete by this step, there’s still one thing left to do: verify that it was successful. This includes security audits as well as variations on Steps 1-3: keep doing research and stay updated on your cloud services, check in with your other teams to make sure they have everything they need; and be ready to open a support ticket if the need should arise.
Even if everyone’s eating, it’s not a successful lunch run if the order got messed up somewhere along the way.
Cloud Migration - What We Learned
There’s no such thing as a free lunch, and the same can be said for cloud migration.
In the latter case, cost will be dictated primarily in terms of the time and efforts of your migration team. Fortunately, if you do your research, consult with everyone who’ll be affected and make ample use of your cloud providers’ support, your migration will run a lot smoother.