A couple of weeks ago, I decided to create this new blog on Azure; that's why I ported BlogEngine.NET to Azure. In this post, I will quickly describe this new platform and present the issues I encountered and how I solved/workaround them.
In case you don't know what it is, here is a small summary (you can find out more on Wikipedia and in its FAQ):
"Azure Services Platform is an application platform in the cloud that allows applications to be hosted and run at Microsoft datacenters. It provides a cloud operating system called Windows Azure that serves as a runtime for the applications and provides a set of services that allows development, management and hosting of managed applications off-premises."
Practically speaking, you use it by building & packaging your website, then uploading it through Azure's front-end and after that, your website becomes available at an address like: http://MyWebsite.cloudapp.net/
Note that it can be used not only for .NET applications but also PHP, Java, Ruby, etc.
Aside for the hosting itself, Azure Services Platform also includes many services. I will only mention the Azure Storage (to store files and loosely structured data) and SQL Azure (a SQL Server running in the cloud). They were all designed to be highly scalable (keep that in mind when noticing odd limitations).
Microsoft provides SDKs to emulate most of these services on your machine (the "Development Fabric"). This makes debugging a lot easier. In theory, if your application works properly on your computer, it will also work online (though, it isn't exactly the case, at the moment).
Experimenting with Azure
Now, let's talk about what it is like to develop for this platform.
1. Online, Azure allows you to store data in "Azure tables". They aren't relational. They behave like "untyped sets", so you can put any object (with different types and properties) in the same "table"; there is no fixed schema and tables can be created on-the-fly.
The Development Fabric comes with a Development Storage which relies on SQL Server to emulate the storage of data. Unlike the online version, it has many annoying restrictions (due to its implementation based on SQL Server): You must run a tool (Devgentable.exe) to generate the tables where your data are stored. The most annoying part is that the strings have a MaxLength of 1000. This is very small for any serious work. Overall, it means that taking advantage of Azure tables as untyped sets is troublesome since it makes the application untestable locally.
Sadly, I don't see how to workaround this problem. At best, you can manually increase that MaxLength. Let's hope that a better implementation is released soon.
2. As I explained before, you must package your application to upload it. This means that, each deployment must contain the whole project. This is understandable for the binaries files, but it also means that you can't make a quick change to web.config or an HTML page for example. And I wouldn't want to be among the people having to upload the whole PHP/Java environment each time (required because they aren't pre-installed like .NET is).
This problem is solvable. After all, Azure Storage gives access to individual files; so supporting adding/updating/deleting them is possible. All that we need is have access to the web root in the same way. Note that in both case, the scalability is abstracted (there are many copies of your files on different computers and they are kept in sync).
3. We really need a great solution to access the Azure storage services. Right now, I'm using AzureStorageExplorer; it is good enough, but has many shortcomings. There are third-parties offering more complete solutions, but they are not free.
4. Windows Azure has an API to log events. This is really useful to monitor a website. The problem is accessing the logs. At the moment, we have to: dump into a storage, wait, download and finally read. We need a web interface to access logs in real-time!
My current workaround (implemented in my BlogEngine.NET for Azure): All logs are sent through the same API (class ApplicationEnvironment). I added a static StringBuilder where I store them, and at the end of each web request, I save it in the Azure blob storage (filename based on a date). Then, I use AzureStorageExplorer to read it. I could also create a webpage to read it online. This solution is primitive, but it works. Don't forget to disable it in production (to reduce costs).
5. Finally, the most irritating issue happened when I was starting. The application was not starting at all. In regular .NET applications, the debugger is attached before any code is executed, so any error can be intercepted and debugged. This is not the case for the DevFabric. Moreover, I could not even read the logs in its console. So, I used the StringBuilder introduced in 4. I dumped it in a file after each log:
File.WriteAllText(Path.Combine(HttpRuntime.AppDomainAppPath, "logs.txt"), Logs.ToString());
That way, I could at least add enough logs to eventually figure out where the bugs were.
By the way, in Silverlight, there is the event Application.UnhandledException which can be used to detect any exception unhandled. This is very useful since, with it, I no longer have to put try/catch/log all over the place. AppDomain.UnhandledException seems to do a similar job, but I haven't tested it yet.
Overall, I really like Azure; considering the constraints due to scalability, it is a nice platform. And I understand that it is still in beta/CTP (commercial availability is scheduled for November). I hope that this feedback will help to improve it.
Subscribe