Familiar with AWS but looking to take the plunge with Azure? You’re not alone. While AWS is the top public cloud provider, more and more, developers, managers, and cloud wizards from the cloud that Bezos built want to chance to savor that Azure flavor.
But how do you move with grace and elegance from AWS to Azure? I thought you’d never ask! (Actually, I did think you might ask, so I wrote the following blog post to guide Azure for AWS users. Please continue.)
What’s in a name? With Azure, less nonsense
I’m an Azure developer by heart, so I’m going to start with the best part about moving to Azure. The naming. It just . . . makes sense. If you want to create a new virtual machine, you create a (wait for it) “Virtual Machine.” Need storage? That’s called “Storage.” Need automation services? Yep, you guessed it. It’s called “Automation.”
Comparing Azure to AWS isn’t apples to apples, but at least with Azure services, you can be sure 9 times out of 10 your apples will be called “apples” and not something that sounds like a new Christopher Nolan movie. (I’m looking at you, Inferentia.)
“But what about Cosmos DB and CycleCloud?” you might ask. Yes, yes. There are always exceptions to a rule. But when it comes to Azure, more times than not the key to naming is to think of what the service does — not what silly name marketing could dream up. (Sidenote: This straight-forward naming sadly does NOT carry over to the confusing naming conventions of Azure cert exams.)
How do I create a scalable, highly available web application that allows continuous integration with ease?
To answer that question, AWS has created Elastic Beanstalk. If you’ve been exposed to AWS for a while, you might know how to use Elastic Beanstalk, or EB, to create a web application. (And yes, my above point on AWS naming still stands.)
The standard architecture for EB, as proposed by AWS, looks something like this:
With that in mind, let’s convert that to Azure. First up, a small table that shows the “conversion” between AWS and Azure for the services and bits that we need:
|Web App||Elastic Beanstalk||App Service||Elastic Beanstalk is a wrapper for a number of services. App Service is the instance to which code is deployed.|
|Hosting Environment||EC2 Instance(s)||App Service Plan||An App Service Plan defines the resources (VM) used to host the App Service.|
|Database||Dynamo DB||CosmosDB||Both are NoSQL database services.|
|Network||Virtual Private Cloud||Virtual Network||–|
|Domain Name Service||Route 53||DNS||–|
|Load Balancer||Elastic Load Balancing||Application Gateway||The load balancer for App Services is Application Gateway. For VMs, you’ll use Azure Load Balancer.|
|Resource Group||If you feel like it||YOU MUST HAVE IT (said in your best German accent)||Resource groups are optional groupings of resources in AWS. In Azure, all resources must exist in a resource group.|
And when we put those Azure components together to create a web application, we get an architecture that looks like this:
The two implementations are not hugely different. The main difference is that on AWS, an Elastic Beanstalk implementation is a wrapper for all the services that make up a web application. For Azure, an App Service is the actual instance of the application where your code is deployed to.
It’s always a straight forward mapping, right?
No. Sorry, it isn’t. I deliberately chose a simple web application scenario, because it’s common and it’s a good general use case. Every single implementation of a cloud architecture will be different. My point is that most of the services used for common computing scenarios on AWS can be found on Azure. My suggestion is to look through the reference architecture diagrams for Azure for the section that is closest to your scenario on AWS. These are great for pointing you in the right direction and for learning the range of services in that segment (i.e., using containers will involve ACR, ACI, AKS and more.)
Choose your tools
Choosing the tools that are right for you often has little to do with the cloud computing provider you use. My advice is always to choose the tools that work best for you. If you’re that person that loves Vim, then use that. (We can’t be friends though.)
Most of the tools that you use for AWS are the same for Azure. However, there are a few tools that Azure professionals tend to gravitate towards. And what better way to share the details than in a nice table. I know you like these too.
|Writing Code||Visual Studio Code||Visual Studio Code|
|Code Tools||AWS SDK||Azure SDK|
|Commande Line Use||AWS CLI||Azure CLI|
|Scripting of Infrastructure||CloudFormation||PowerShell|
You can see the overlap is significant. The main differences going from AWS to Azure are PowerShell (which Azure nerds loooove) used for defining infrastructure and the Azure CLI.
How hard is it to make the switch from AWS to Azure?
Wondering if you should take the plunge? It isn’t so much a plunge, as a mild splash. If you have a decent understanding of AWS and cloud computing in general, many of the services, concepts, and architectures are very much the same. As discussed, the naming is very straight-forward (mostly), and the tools share some commonality.
Are you looking to get started with Azure — to get some intel before getting your feet wet? Maybe you’re asking yourself, “Self, why should I get an Azure certification?” Or maybe you’re curious as to which Azure certification is right for you. We’ve got you covered with that and loads of Azure courses and resources to help you get started, including plenty of free courses around Azure, from an intro to core Azure concepts, to Azure architecture design, and Identity and Access Management for Azure.
So go on. Make the splash. See you in Azure-land.