One hurdle I run across while talking to AWS users about Azure comes down to terminology. Every cloud vendor has their own vernacular and this can be a source of endless frustration when one starts to compare the two services. Developers that have already wrapped their mind around AWS’ parlance often find themselves struggle to understand Azure’s.
There is of course a intrinsic difference between the two platforms which contributes to the confusion. And before we draw any lines between the two platforms, we should first address this fundamental difference.
Infrastructure vs. Platform
There are three primary Cloud Service Models in the market today - Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).
Amazon Web Services is fundamentally an Infrastructure as a Service solution. Azure on the other hand is fundamentally a Platform as a Service solution. While it is true that they both offer some components from each Service Model, they remain primarily influenced by their core model.
Essentially the difference comes down to where you place the abstraction layer. With IaaS they provide a virtualization infrastructure and leave the rest to the you. PaaS on the other hand includes both the infrastructure and the runtime environment (OS, runtimes, middleware, etc.).
By further abstracting away from the physical environment, PaaS delivers fantastic scalability with substantially less management overhead. You manage your application and your data, the rest is handled for you automatically.
Connecting the Dots
A word of warning (and preemption of the inevitable complaints): I am making certain generalizations to make this more digestible. In doing so, some nuances of the various platforms may be overlooked.
At the highest level there is some parity between AWS and Azure. They both divide the service into four primary categories Compute, Storage, Database and Networking. As you move down the stack however is becomes muddier. Hopefully the following will help simplify transitioning from Amazon to Azure.
Elastic Compute Cloud (EC2)
The closest allegory to EC2 is Azure’s VM Role (currently in Beta). Specifically it aligns with an EC2 instance leveraging Local Instance Store. They both are stateless instances (meaning they don’t persist data on the root disc). Both also support a file system persistent model to deal with the inevitable files that get generated (see below). Unlike AWS however, Azure uses a user-supplied VHD rather than building the image in the cloud directly.
Unlike the VM Role, there is no allegory for the Web or Worker Roles. These roles are pure PaaS instances. You publish your application to them and the underlying platform is maintained for you.
Web roles in Windows Azure are special purpose, and provide a dedicated Internet Information Services (IIS) web-server used for hosting front-end web applications. You can quickly and easily deploy web applications to Web Roles and then scale up or down to meet demand.
Worker roles run asynchronous, long-running or perpetual tasks in the background. They are very similar to Windows Services or Daemons. When you separate your application’s background processes in a Worker role and host the front-end in a Web role, you can better distribute your application logic and have more fine grain control over how your application scales.
Elastic Block Storage (EBS)
Azure Drive aligns quite well with EBS. The Azure Drive is a VHD hosted within Azure Storage (technically within something called a Page Blob). This VHD can be mounted by your Web, Worker or VM Role. This drive looks like any other secondary drive connected to a server. Data written to an Azure Drive will persist outside of the instance that mounted it. You can also mount an Azure Drive Snapshot, providing a read-only data store to a large number of instances.
Dynamo is a NoSQL database that is very similar to Azure Table Storage. NoSQL is an excellent way to store unstructured or loosely structured data in a cloud environment. Wile they lack the referential integrity of a relational database, they are extremely efficient. This efficiency allows them to scale incredibly well.
Simple Storage Service (S3)
When it comes to storing stuff in the cloud, the examples sited almost always revolve around digital media of some type. AWS S3 is Amazon’s answer, Azure Blob Storage is Microsoft’s. They both serve the same purpose, storing large binary objects.
Simple Queue Services (SQS)
Queuing is vital to successfully scaling out in the cloud. Azure includes a persistent and reliable messaging service called Azure Queue. This is the primary way your machines (AWS) or roles (Azure) relay information to each other.
Relational Database Service (RDS)
As sexy as NoSQL is, it doesn’t replace traditional relational database. When you need to store structured data with transactional support, turn to SQL Azure. SQL Azure is a high availability clustered SQL platform. It uses the same tooling as SQL Server, making it a relatively easy transition from traditional SQL Server deployments.
Both platforms also have a host of additional services that you can add into the mix as well. I’ve decided to forgo diving into them at this time rather risk getting stuck in the weeds sorting out things like Rout53 and Traffic Manager. These are more advanced topics and beyond the scope of what I covered here.