Azure Platform as a Service vs Infrastructure as a Service
Platform as a service (paas) sounds nice, you have a load of servers on the cloud somewhere where you are paying just for what you need or use and these are quickly scalable up and down. In the case of Azure, this means you get an automatic web farm with multiple instances and this is a real headache taken away for highly scalable applications. So I want to describe my experiences of Azure platform as a service against any other infrastructure as a service (iaas). I haven't used Azure iaas but I'm guessing it similar to Amazon etc.
Since the infrastructure is deliberately hidden, there is the trade-off between needing to access it for debugging purposes and trying to keep people away from fiddling with it. You can enable remote desktop access on the deployment but I have found this troublesome and error prone and not at all easy to debug.
Since the platform is effectively a large eco-system which Microsoft own, if you want to debug locally, you have to use their emulator on your own PC to debug. Again, I have found this error prone and it can throw fatal errors without much clue as to what has happened. It also means you cannot always run the application directly from IIS if the Azure emulator isn't working (I get errors in the azure system somehow) and therefore you have to deploy to test things. It also means that you are not running code and writing files to the kinds of places you think since the debugging (and deploying) process packages the files up and moves them away from the project folder. This means that file changes aren't usually picked up when debugging and you have to restart the debugger (if it works!).
There are problems with using things like diagnostics, something that is quite fundamental to setting up new systems with all their inherent problems. This was related (I think) partly to a major change that occurred in the Azure SDK which majorly re-factored namespaces but without renaming the classes leading to confusion as to which online examples related to which versions of the SDK but I also, I think, many of the online samples didn't work for multi-instance web services which meant I spent a long time trying to get something to work. I had almost nothing to go on (except knowing it didn't work!) and eventually stumbled on an example which was different and which then worked for me.
Advantages of Azure
As you might imagine, Azure has been designed to be easy-to-use, otherwise paas wouldn't be worth it. The web management interface is quite slick and the ability to deploy directly from Visual studio is very helpful. You can deploy databases either directly from a database project in Visual studio or directly from SQL Server Management studio. There are various monitoring options as expected and I haven't spent much time here yet. There is also the ability to extend the functionality of Azure instances using startup scripts, commonly using powershell, which can allow you to do pretty much everything you would expect on the underlying server.Problems with Azure
I think it would be fair to say that the initial setup and deployment of a basic application is quite straight-forward but the deployment process can be very slow, especially when compared to my old manual deployment via subversion. This is annoying when a small mistake breaks something and you have to "roll back". My deployment usually takes about 10 minutes, this is even when using "deployment update" rather than "deployment replace".Since the infrastructure is deliberately hidden, there is the trade-off between needing to access it for debugging purposes and trying to keep people away from fiddling with it. You can enable remote desktop access on the deployment but I have found this troublesome and error prone and not at all easy to debug.
Since the platform is effectively a large eco-system which Microsoft own, if you want to debug locally, you have to use their emulator on your own PC to debug. Again, I have found this error prone and it can throw fatal errors without much clue as to what has happened. It also means you cannot always run the application directly from IIS if the Azure emulator isn't working (I get errors in the azure system somehow) and therefore you have to deploy to test things. It also means that you are not running code and writing files to the kinds of places you think since the debugging (and deploying) process packages the files up and moves them away from the project folder. This means that file changes aren't usually picked up when debugging and you have to restart the debugger (if it works!).
There are problems with using things like diagnostics, something that is quite fundamental to setting up new systems with all their inherent problems. This was related (I think) partly to a major change that occurred in the Azure SDK which majorly re-factored namespaces but without renaming the classes leading to confusion as to which online examples related to which versions of the SDK but I also, I think, many of the online samples didn't work for multi-instance web services which meant I spent a long time trying to get something to work. I had almost nothing to go on (except knowing it didn't work!) and eventually stumbled on an example which was different and which then worked for me.