Preface

I know a lot of people that work with Microsoft Azure, and I know a few people that work for Amazon Web Services. I go further back with the Azure people, so they get to suffer from my Facebook rants about how much Azure has wronged me, and how much greener the grass is over in Bezos’ walled garden – whilst the people at AWS see none of it thanks to the algorithms.

This post is an attempt to mend fences/garden walls a bit. Both cloud providers have their specialities and I’m going to opine about what they are.

All of my opinions are based around the stuff I want to do, and how much work the cloud provider makes me do.

1. Host simple blogs
   1. I don’t care about storage, just make it happen
   2. I might want to make tiny code changes, make that possible
   3. I want to be able to access a command-line and some logs for when PHP breaks itself
   4. I want HTTPS. Don’t make it a big deal
2. Deploy ASP.NET Core apps of the latest stable framework version (no previews necessary)
   1. I want the code to deploy automagically after I push my changes to github
   2. I want to be able to see correlated logs for various sites that call eachother. Make it look like Graylog
   3. I want correlated logs from mobile apps as well
   4. I want HTTPS. NBD, right?

Very simple requirements, and usually they are covered in various beginners’ guides

Coalface

Azure

Hosting ASP.NET Websites in Azure is of course simple, although not as simple as you would think. Yes, you can create what was known as a Windows Azure WebApp, now App Service, selecting the latest framework and just make it work. You will have to accept that it will randomly stop working as the make sweeping changes in the underlying architecture, from being a simple VM with a rogue git installation doing the actual deployment to some mysterious docker-based solution, even though your app isn’t containerised. As usual with Microsofty things, it is very easy to create a sample app, but getting something that works in production is a lot of work.

AWS

In Amazon Web Service-land things are different. They have very mature .NET APIs as wel, and will let you use a myriad of services, but there are no services that directly replace Azure WebApps. If you have a .NET Core Web API you can host it in AWS Lambdas using dedicated APIs and it will do exactly what you want at a very low cost, most likely completely free, depending on what other services you use. If you want to host a web site made by old people, one that uses server side rendering, you are SooL, and will either have to host a VM like a barbarian or learn docker / docker-compose. Fargate seems cheap though. The point is, the threshold to even get started is pretty high, but once you have produced something you have it written as a script somewhere and it seems production ready.

California

Once I guided a customer through reading a certificate information screen in a browser, and they immediately noted over the phone that the certificate "was trusted by California and was something something 2048 South Africa". The abbreviations for Certificate Authority and the Rivest, Shamir, and Adelman public key encryption algorithm caused confusion.

Certificates in Azure just got a lot better. You used to have to use a dodgy plugin in your Azure Website if you were suffering through using a Windows App Service that would set up Let’s Encrypt challenge endpoints and generate and install certficates for you, and getting it to work automatically was not fool proof (exhibit A, me – a fool – not managing) , or – if you had a proper Linux App Service – hand cranking the certificate util in your local WSL installation every couple of months and manually upload the certificate like in the olden days. Now though, allegedly you click once and it works.

Meanwhile in Bezos Land, there is a certificate manager, you have to faff with domain verifications, like in Azure to be fair, and IAM up and down, but then everything just works TM.

Drop the (data)base

Azure Database

Microsoft rarely ventures out to break backward compatibility, but when they do, they really break it. When they decided “Heard you like RDBMS, so we put RDBMS in your cloud” they built a SQL Server of the mind, a false creation proceeding from the heat oppressed Service Fabric. I e they implemented a small subset of SQL Server features, and made a new highly specialised application that to the end user almost looked like a load balanced SQL Server in the cloud. They called it SQL Azure (I think) and just told developers to increase connection timeout and not to expect connections to stay open. As the years have passed, compatibility has come closer, but it’s still surprisingly anaemic at places.

AWS RDS

Bezos et al just put a SQL Server in a VM and locked down the access. Boom, job done. Sure, getting backup and restore to work required some SQL hacking and more IAM to access S3 for storage to access any backup files, but to the end user it mostly just looks like a SQL Server, and you see few oddities when using Management Studio. It is important to note that the user interface is very cryptic hostile to beginners, but it doesn’t look obtuse on purpose, so you forgive it.

It’s a set-up

Azure App Service + Vault

Using the parameters in Azure App Services to configure your app is super trivial in ASP.NET Core, as you can read them as normal ASP.NET IConfiguration values, and they seem pretty reliable, except when Azure Pipelines decides to wipe all settings, which it may or may not do depending on mood.

Secrets, like certificates and keys, are easily stored in Azure Key Vault that can also be piped into the ASP.NET Configuration system for ease of use.

AWS Systems Manager, KMS and Secrets Manager

Because .NET Core is a pretty big deal, there are already APIs that give you the same benefits from a programmer perspective, you can just download your settings into the normal IConfiguration system, but there are pitfalls with encryption keys for certain settings and compatibiltiy with AWS KMS can be a faff to get right.