August 28, 2022•746 words
Recently I was working on getting a basic Node.js REST API running on Microsoft Azure's App Service platform. I've only used AWS professionally, but I wanted to get a sense of what it would take to run a simple website off of Azure so I decided to give it a whirl.
The experience left a sour taste in my mouth and helped me understand why AWS is currently winning the Cloud Wars.
Let's start with the most jarring difference: documentation.
Azure documentation is sorely lacking in discoverability and usefulness. The documentation site is vast and likely contains a lot of good information, but it's organized in a way that forces developers to jump between entirely different sections of their website. And despite how detailed it gets in some places, other times it would inexplicably be missing explanations of configuration settings.
AWS documentation has its own issues, but I can generally trust that a basic walk-through will have everything I need to get started and each setting will be explained in the reference links the documents point you to in each tutorial.
Second issue: Azure's GUI-centric approach.
My favorite part about AWS is that (most) everything can be scripted with configuration files. Azure has the same feature, but I could not find a single tutorial that gave me enough information to write my own configuration file for the service I was using. Instead, I used a tutorial that walked me through building what I wanted in the Azure console and I then exported the configuration file for reproducibility in the future.
With AWS, the config-first tutorials teach you what each part does and why it's needed, so you can do the whole thing without ever opening the AWS console.
On top of that, the exported config came with a magic token variable to connect GitHub with Azure, but I couldn't find a single reference as to how to change that later or create it to begin with if I were to not use the Azure console to configure my service.
Third issue: Azure can't unzip
After following a tutorial for making the Node.js REST API (which didn't even work when initially deployed), I noticed the upload of the build artifact to the server was taking over 10 minutes because the build output had not been archived or compressed. So I decided to archive it using the
tar format instead of
zip (since the build server was a Linux machine) so I could iterate more quickly on trying to get the API fixed, since it still hadn't been working up to that point.
After fixing what turned out to be some issues with environment variables, the API still didn't work. I poured over the code and couldn't find anything wrong. Everything worked on my machine and the templates matched what was in the tutorial, except for the file archive step I added to fix their slow upload speeds (which should've been my first clue). There wasn't anything obvious left to change!
It took a two-hour call with an Azure agent before they finally realized that the Azure service I was using could not open up
tar files, so the API wasn't being fully deployed. I needed to create a
zip archive instead. So I changed it, and the API started working!
I understand that
zip is the archive tool baked into Windows, so naturally Microsoft will prefer using that to other tools. But it's not hard to write code that checks the archive file type and chooses the right tool when expanding the archive, so I was flabbergasted to hear that the archive format is what caused the problem.
If you know me at all, you'll know that I hate Amazon and tolerate Microsoft, so it's weird for me to be endorsing AWS over Azure. But my experience with Azure has really soured my desire to ever try using it again. I know Microsoft really cares about the developer experience in their .NET tooling ecosystem so it's strange that the same care has not been applied to Azure yet. Maybe they'll get to it someday, but AWS is still the easiest to use at this point.
Anyway, that's more words than I ever thought I'd write about file compression tools so we'll leave it at that. I'm just glad it's working now and figured my tech savvy readers would get a chuckle at how one small assumption can cost you hours of your life.