Until a couple of months ago, I was working with Microsoft Azure as a cloud provider within my professional environment. Mainly for the last 3 years since I started the cloud adventure. But now, a new professional opportunity is allowing me to switch from Azure to AWS, learning of the leading market cloud provider. Therefore, I decided to open a new “Training Pills” series.
As you can imagine, today, as I write this article, all AWS terms and configuration stuff is really new to me. Thus, I decided to take profit of it and start writing a bit about the topic. What are the steps that I am following? Which are the main topics that I see useful if you are starting with certain services in AWS? And that is the goal of these series of articles that I am starting with this first one.
Initial differences between Azure and AWS
One of the main differences is the number of services and its intrinsic magic of Azure services compared to AWS. And its user interface. But the main technical difference is the number of services that AWS offers, and the wide variety of technologies supported. For sure Azure is improving there, but the power of Azure resides on the .NET related services, as you could already imagine. And this is something that does not happen in AWS. You would need to wait a while, as example, to work with the latest .NET framework on your serverless Lambda functions. This is usually not a problem on a daily basis but is something to mention.
In any case, I see the power of AWS in companies where the main stack is not clearly defined. Meaning that you have applications in many different languages and you probably want to have a harmonised cloud provider. But, at the same time, I can see Azure more powerful when it comes to developing and deploying Microsoft solutions, for obvious reasons. One of them could be setting up hybrid environments for companies that are migrating to the cloud. In that case, probably Azure would fit more. Mainly because of the on-premise services that you might think in your Windows environment have its direct counterpart in Azure. And without forgetting the magic when building and deploying your applications.
Creating a new serverless application
In my experience with Azure, PaaS approaches have been always the preferred solution for most of the business cases. In that sense, Azure WebApps was the most used service for deploying solutions that mainly were Web APIs. If we map that to AWS, we would find Elastic Beanstalk; an easy way of creating serverless applications. You will notice the first differences when trying to create your first applications. Azure forces you to organise all the resources for your application (databases, VPNs, functions…) in Resource Groups. This is something that in AWS doesn’t happen, you are more flexible in that sense.
But, in the other hand, AWS have other ways of organising the services that might differ between one and the other. For example, in case of Elastic Beanstalk, you need to create first an Environment before creating your Application, otherwise AWS will create one for you. Meaning that you are forced to organise your instances by application. This is something that can be good or not that good depending on your business case.
So as a resume for this first pill, you will notice that, in terms of services, you will have something like the same between vendors. So you would have same approaches for same common problems. If you come from Azure, it won’t be hard for you to identify these mappings and familiarise yourself with the user interface and solutions. In Azure you will be more helped when it comes to setting your Microsoft solutions, when in AWS you have a more harmonised approach but with a really interesting and well structured documentation. I will try to continue publishing articles as soon as I get more expertise on the AWS services, but it looks really promising!
