Re: Loong term view
"Azure is easier to use"
I use Azure every day and can confirm that it most certainly is NOT easier to use than AWS. At least from a development and deployment point of view.
I'll list a few off the top of my head examples of where Azure makes things more awkward than AWS (or an on-premises setup, which is basically the same as AWS) I'm talking from a .net perspective, which in theory should make things easier so I dread to think what it's like for non .net folks.
- Wrappers. To deploy to Azure you need to wrap your projects in a special .cloud project. These frequently become corrupt (especially when upgrading) and have lots of config XML duplication. Very awkward to merge. (You don't have to use these if all you are making is 1 website but for anything remotely interesting you have to use this mechanism)
- Deployment. Is SLOW. You can deploy from Visual Studio, which packages up your application then sends it up to Azure, which will then makes a whole new VM, installs what it needs then allows you access. This can take anything from between 5 and 45 minutes depending on the size of your application and which way the wind's blowing. Note that getting the deployment set up in the first place is a pain because you need to mess around with storage locations and other auth stuff. Oh and if you just want to make a minor CSS tweak (for example) to a wrapped website you need to do a whole new redeployment because any changes you make via RDP aren't guaranteed to remain.
- Config. With Azure, they've thrown the .settings stuff in the bin and implemented a fudge so you can store your settings in the .cloud project and access them through a proprietary MS class. This does fall back to web.config or app.config if the setting isn't found but it throws and catches an exception to do it. Also it duplicates config, meaning it's easy for stuff to get missed out. Oh and it still takes ~5 minutes to make any config change via the Azure front end (it must do a soft reboot or something).
- Waste. For every project in a .cloud wrapper Azure will create a VM, eating into your cores limit.
- Backup. Backups (of Azure SQL) are still practically impossible to get set up in a reliable, automated, on and off-site way.
- Azure SQL. Is just generally awful. Missing features (freetext search, custom CLR functions, scheduling), difficult to diagnose when things are going wrong.
- Scheduling. Is only available via creation of a mobile app and even then it's only able to call a web service so you still need a whole instance per (different) scheduled action.
- Remote access (RDP). Needs to be enabled specifically from the first deployment or you need to redeploy with the various settings enabled. Makes debugging a failing service very difficult. Oh and you can't do an in-place swap of VMs while turning on RDP because it creates another endpoint and you can't swap in that situation. That means downtime, of however long it takes it to deploy.
- Diagnostics. Aren't provided by MS at all. The best software seems to be "Azure Management Studio", which is OK if a bit flaky (I put this down to the services they are calling rather than their software). But to get anything useful you have to mess around with more settings, pepper your code with more Azure only MS classes (Azure Diagnostics), turn around 3 times and stand on your head.
...That's all that immediately spring to mind.