Posted by The cloud got its start when AWS made the infrastructure that they used internally available to the masses. Microsoft and Google quickly followed suite by launching their own cloud platforms to compete and keep up with Amazon’s market lead.
The early days of AWS didn’t have a ton of Windows support other than plain virtual machines. This allowed Microsoft to step in as the go-to resource for .NET developers looking to leverage the cloud. But as we go through this post we’ll see that this isn’t the case anymore, with AWS providing a much richer .NET ecosystem, as well as Google’s Cloud making leaps and bounds in terms of .NET support.
The goal is to determine who provides the best experience across every technology on which you can host a .NET application, be it an API or Worker. To that end, we’ll look at Virtual Machines, Containers, and Platform-as-a-Service offerings from all three platforms. All three of the big cloud providers enable those technologies to work with the .NET Framework to varying degrees. In some cases the winner is obvious, while in others it’s a much blurrier line. The result is a 2-part series to determine .NET Cloud Supremacy.
About The .NET Framework
It’s easy to forgot about the ‘good old’ .NET Framework with all the attention .NET Core is getting lately. I considered skipping the comparison for the .NET Framework entirely but eventually decided to do it for one simple reason: the majority of customers today are still running .NET Framework applications and will be doing so for the foreseeable future.
Businesses can’t afford to rewrite existing applications that have been reliable for years but they could benefit from finding more scalable, and reliable ways to run them in the era of the cloud. Technologies like Platform-as-a-Service and Containers are enabling .NET Framework applications to do just that and move forward into the “next generation” of software development.
Virtual Machines: AWS and Azure lead but Google is close behind
It’s easy to forgot that Azure was originally called Windows Azure. It was called that because it was originally heavily focused on enabling the cloud for .NET developers who were “stuck” running their applications on Windows. That relationship has resulted in tight integrations between VMs, Azure Portal, and its monitoring tools, giving it a net advantage over its rivals.
All three clouds provide similar features. Autoscaling, logging, monitoring, pricing, and provisioning can all be accomplished fairly easily. The choice of cloud provider therefore depends more on the other needs of the product being built. For example, integrating with on-premise Microsoft technologies (like Active Directory) will be seamless with Azure. As a rule of thumb, figure out what you need to integrate with and find the provider that fills those needs the best.
AWS do have an X-factor in this race. They’ve been providing their cloud services a full four years longer than Microsoft. You can see that 4 year edge when you compare AWS Console to Azure Portal or the AWS CLI to Azure Powershell. They both get the job done but the AWS tools are easier and clearer to use.
Platform-as-a-Service: Azure.
Azure have two players in the PaaS space. App Service and Service Fabric both let you run applications in the cloud without worrying about maintaining servers. Service Fabric is the more complicated of the two but that complexity is translatable into additional flexibility. It’s possible that they’ll sunset App Service as it’s been around for almost 5 years now but the recent addition of Linux support might indicate otherwise. It’s a safer bet to invest in Service Fabric, even with the additional complexity that it brings to the table.
Service Fabric can run any type of application, be it an API or a worker. The same can’t be said for AWS’s Beanstalk, which only supports hosting APIs. Beanstalk does support Blue/Green deployments out of the box though and is much simpler to use than Service Fabric. It’s a decent option if your needs are limited to hosting APIs.
I spent lots of time on the Google App Engine documentation trying to figure out if the .NET Framework is supported. App Engine is built on Docker and the images that GCP provide are all for .NET Core on Linux. While they say the images are customizable, it’s unclear as to whether .NET Framework on Windows is supported.
Containers: Toss up
Containers were originally for Linux only and running them on Windows was a complete afterthought. Since then Microsoft has invested heavily in containers for .NET Core and luckily .NET Framework has come along for the ride. The close relationship developed with Docker has paid off not only from a base image perspective but also from an Azure integration perspective. Azure Container Service runs Kubernetes, the tool of choice for managing containers. All this makes for a very interesting, if operationally expensive, way of modernizing an older application.
AWS officially added Windows container support in December 2017, although it’s been in preview since late 2016. Any newly released products tend to be a bit buggy and AWS themselves have a list of Windows container caveats that should be kept in mind.
Google’s Windows container support is on par with Azure’s. Kubernetes, developed by Google, can be used to manage your Windows containers here too. And although Kubernetes can be run anywhere, it’s only natural that it will run more seamlessly on Google’s Cloud Platform.
The nature of containers is that they run exactly the same everywhere so the choice of which cloud to run them on shouldn’t matter too much. The decision can instead be boiled down to other factors, such orchastrator of choice, cost and familiarity.
Will any of this change?
It’s likely that there will be some changes at the PaaS and Container level but I wouldn’t expect much movement in the Virtual Machines space. While the .NET Framework is still extremely popular, the push to .NET Core will continue and dry up the need for new technologies to support the “old” .NET Framework.
Marc Roussy 