If I wanted to do IaaS I would have done so already, and most likely on EC2. However, I don't want to spend time doing devops, which is what makes PaaS so attractive in the first place. Actually the true PaaS is Cloud Services, which we've integrated along with the queues and tables. It's definitely not in beta - it's been out for quite some time. Most of my PaaS experience comes mostly with App Engine, which I liked as a platform (save for the odd quirk). When I first signed up with Azure, I was blown away by how good the interface looked compared to App Engine. However, over time as we've developed a non-trivial but not overly complex (internal) service, I found many things that I took for granted on App Engine had to be coded from the ground up on Azure (namely, logging and HTTPS).
Who writes a cloud platform thinking that logging is not important, and instead gives me a dashboard with pretty graphs with information no-one ever uses? Instead you have a separate Diagnostics module which intermittently works and then the best you can do is store as a blob or to a table, which must then be read out with another tool. Which you need to write yourself, or Azure Storage Explorer, a bare-bones table reading tool on CodePlex.
Then there's the crown jewel of the Azure clusterfuck, the Azure emulator. Deploys take anywhere between 20-60 minutes, after coming from App Engine's 30 second deploys (they used to take about 2 minutes to upload and begin serving - the difference it makes is astounding in being able to keep in flow). If there's no way around that time, then your local dev tools need to be rock fucking solid, because if you deploy, you want to make sure that you've got all those really dumb mistakes out the way. Instead, random roles intermittently stop logging, and the Azure emulator craps out with random shit after a few Build and Runs. So then it's time to restart. That's if VS2012 doesn't suddenly decide to hang when I right click on the Solution name to publish, after which it comes up with the most bizarre message "VS is currently completing an action - you'll have to wait" (paraphrased). It never does finish so Ctrl-Alt-Esc we go, kill the process... except the process still hangs around. So you restart and you end up with the same problem, except you now get another process of VS chewing through 180Mb of RAM for no reason. Okay, time to restart.
I've had my issues with the App Engine tools running on OS X (mainly a really odd issue with pytz, and the single-threaded local webserver which was slow as shit until 1.7.6), but I've only had to restart my computer a handful of times in a year and a half of development. Two months in Windows and I'm restarting 5 times a day.
After dealing with all that, the annoyance generated by every other minor issue becomes magnified by an order of magnitude, and you begin to ask yourself, who the fuck is designing this shit? ASP.NET MVC4 ApiController. At it's most basic settings it allows you to do REST. You get model binding on static objects, which is good for the most basic of validation. There are a billion tutorials on how to specify routing rules so you can specify "/api/objects/" or if you're being adventurous, "/api/objects/action", because that's all you'll ever need. There's a whole heap of magic, but it's the wrong fucking magic. Aaron Swartz showed the world how to do this in 2005 with web.py, it's not rocket science. To make development bearable, I have to add an insane amount of NuGet packages. You end up with masterpieces like AttributeRouting, for which I could never thank the author enough, but I shouldn't need to add a package to get sane routing. And model binding? The moment I move from static objects, it breaks. Looks like you need to write your own custom fucking model binder now (although I may not have to - still looking into it - Scott Hanselmann had a blog post about it somewhere). Oh, and sending something as JSON? Microsoft were at least smart enough to add in JSON.NET over their own overengineered mess, and yet somehow I still need reams of code just to be able to send an object as JSON. Just restrict the damn types to JSON types when you send it and be done with it! I don't want to type three pages to send serialised text when in Python all I have to do is json.dumps()!
In all this mess, the reason we went with Azure is because we have to connect to Exchange and Microsoft were smart enough to put out the EWS (Exchange Web Services) Managed API, which is actually works as intended. It was either that or write a SOAP handler in Python for the 5 different Exchange schemas (which are similar but not exactly the same). In the end dealing with Azure and not having to maintain an internal Exchange library is worth the trouble (but not by much).
Sadly, this very much mirrors my experience. I love Azure and ASP.NET MVC4. But the moment my deploys went from 5 minutes to 20 minutes and more, I started hating myself for any random code or test I wish I cleaned up first.
Overall though, Azure is a great product and once you wire things up correctly, it makes out to be a fantastic hosting service. I do not have experience with Amazon's hosting stack, but I plan on sticking with Azure for the long haul.
The wiring up is killing it for me - the wrong parts have been overengineered (MVC4, JSON) and not enough attention has been paid attention to the things that need to be stable (Azure dev tools). Overall the service has amazing potential, insofar as you can do a lot more than you can do on something like App Engine (which only supports HTTP - which after using Azure, was a good decision). But it drops the ball on all the basic features, whether they be buggy or missing.
The big issue I have with MVC4 (and many other Microsoft things with which I've been working) is that MVC4 doesn't work to fit around me - I need to work to fit around it. Compare that to working with Flask - supporters say it's a "beautiful API", but really what it comes down to is that Flask is minimal enough (not minimalist), gives you everything you need to work with the web, and if you need to do something complex, doesn't get in the way. It's at the appropriate level of abstraction. MVC4 is not.
I guess we'll see how the cost goes over time as well - not sure how that will pan out. I wish I had better stuff to say, because I was quite excited about it when I first started using it, but I have soured on it and won't use it for anything not Microsoft-centric.
Way to go, this completely describes Azure (and MSFT web) development. We've been using the MSFT stack for the last 4 years and this is 100% consistent with our experience.
Once I started I couldn't stop. This is my therapy for the last three 16 hour days I've done debugging our Azure-based service. My compatriot (an ex-Microsoftie) has been working with it fully for the last two months, and I have no idea how he maintained his sanity.
Who writes a cloud platform thinking that logging is not important, and instead gives me a dashboard with pretty graphs with information no-one ever uses? Instead you have a separate Diagnostics module which intermittently works and then the best you can do is store as a blob or to a table, which must then be read out with another tool. Which you need to write yourself, or Azure Storage Explorer, a bare-bones table reading tool on CodePlex.
Then there's the crown jewel of the Azure clusterfuck, the Azure emulator. Deploys take anywhere between 20-60 minutes, after coming from App Engine's 30 second deploys (they used to take about 2 minutes to upload and begin serving - the difference it makes is astounding in being able to keep in flow). If there's no way around that time, then your local dev tools need to be rock fucking solid, because if you deploy, you want to make sure that you've got all those really dumb mistakes out the way. Instead, random roles intermittently stop logging, and the Azure emulator craps out with random shit after a few Build and Runs. So then it's time to restart. That's if VS2012 doesn't suddenly decide to hang when I right click on the Solution name to publish, after which it comes up with the most bizarre message "VS is currently completing an action - you'll have to wait" (paraphrased). It never does finish so Ctrl-Alt-Esc we go, kill the process... except the process still hangs around. So you restart and you end up with the same problem, except you now get another process of VS chewing through 180Mb of RAM for no reason. Okay, time to restart.
I've had my issues with the App Engine tools running on OS X (mainly a really odd issue with pytz, and the single-threaded local webserver which was slow as shit until 1.7.6), but I've only had to restart my computer a handful of times in a year and a half of development. Two months in Windows and I'm restarting 5 times a day.
After dealing with all that, the annoyance generated by every other minor issue becomes magnified by an order of magnitude, and you begin to ask yourself, who the fuck is designing this shit? ASP.NET MVC4 ApiController. At it's most basic settings it allows you to do REST. You get model binding on static objects, which is good for the most basic of validation. There are a billion tutorials on how to specify routing rules so you can specify "/api/objects/" or if you're being adventurous, "/api/objects/action", because that's all you'll ever need. There's a whole heap of magic, but it's the wrong fucking magic. Aaron Swartz showed the world how to do this in 2005 with web.py, it's not rocket science. To make development bearable, I have to add an insane amount of NuGet packages. You end up with masterpieces like AttributeRouting, for which I could never thank the author enough, but I shouldn't need to add a package to get sane routing. And model binding? The moment I move from static objects, it breaks. Looks like you need to write your own custom fucking model binder now (although I may not have to - still looking into it - Scott Hanselmann had a blog post about it somewhere). Oh, and sending something as JSON? Microsoft were at least smart enough to add in JSON.NET over their own overengineered mess, and yet somehow I still need reams of code just to be able to send an object as JSON. Just restrict the damn types to JSON types when you send it and be done with it! I don't want to type three pages to send serialised text when in Python all I have to do is json.dumps()!
In all this mess, the reason we went with Azure is because we have to connect to Exchange and Microsoft were smart enough to put out the EWS (Exchange Web Services) Managed API, which is actually works as intended. It was either that or write a SOAP handler in Python for the 5 different Exchange schemas (which are similar but not exactly the same). In the end dealing with Azure and not having to maintain an internal Exchange library is worth the trouble (but not by much).