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).