Thoughts on Azure – Compute, Storage and SQL
I think Azure is ready to go as a platform for a Software as a Service platform. When we think of cloud-based infrastructures, it has many pieces that make it both viable and attractive from many points of view. For one, it’s hooked tightly into a great development tool in Visual Studio 2010, and the latest SDK and Tools make it a simply process to publish to the cloud directly from the IDE.
On top of this, you can also hook into your Compute and Storage account right from Visual Studio Server Explorer windows, which is nice.
So what is Azure, really?
I attended a technical briefing for Microsoft partners in Toronto last week, and this was the biggest question. I think there is a lot of misconception out there about what is offered and was is possible with Azure.
Windows Azure - Compute
To be quite blunt, this is primarily meant for Web Apps and Web Services, with the Compute platform tailored to what are called “Web Roles” and “Worker Roles”. These can ONLY to be coded in managed code, however they can invoke executables written in whatever language you like. Basically, a web role is a web app, and do pretty much anything a web app can do. A worker role is akin to a windows service, and if you’ve coded your windows services with decent separation of concerns, you should be port one of those over with no difficulty.
The real power of the Compute platform is that is allows you to manually ramp up the number and size of Instances (read: Virtual Machines) that you want the app to be deployed, both for Web and Worker roles. This means you can flip a config variable and ramp up the power without ever calling IT or touching any routers or load balancers or anything. If you have a multi-tenanted app, this is nice. If not, if you have a an app that’s is single-server, uses a ton of session, is coded like the tutorials, and isn’t meant to be publically available… you might want to reconsider if you need a cloud solution at all.
What’s really good here is that, as of June 2010, .Net 4.0 is supported in Compute.
Windows Azure – Storage
Table Storage – this is really “entity” storage (I know, I know, kind of the same thing), but really this is just a serialized object repository which the ability to be queried in OData style using the Data Services API. Basically, you can dump objects in and get them out again. It has automatic partitioning based on a partition key, meaning this is very scalable. What stinks about it right now is that it only supports a pretty small subset of the OData (and therefore Data Serviecs) specification.
Blob Storage
Blobs equal files. You can do block (sequential, or streamed) blobs or “paged blobs”. These are not good names, but who cares? The biggest annoyance is that it isn’t as good as Amazon S3 (yet), except that it’s stored in the same environment as your Compute instance(s), meaning that you don’t pay for data transfer to and from the Compute and Storage. You only pay for data transfer in and out of Azure itself.
Queue Storage
A queue where items live for up to seven days, 8kb string max. Useful for implementing a multi-instance worker role pattern where the web roles create items in the queue and they are processed by an offline worker role. These are not MSMQ, but they are still wicked useful.
SQL Azure
Databases in the cloud. Great! Except that you can’t do Table partitioning based on filegroup, which is major pain. The only way to scale is to do what is called database sharding. I’m hoping I can hold out until we can do something less useless. I don’t want to rewrite app code and join data in my data access layer. That defeats the purpose of SQL Server at all.
To be continued…
Windows Azure AppFabric
The most important thing about Azure AppFabric is to know that it is NOTHING like Windows Server AppFabric. Which is too bad – because there isn’t yet a decent solution for distributed caching Azure Compute… a real shame.
All in all, Azure is the real deal, and you’d do well to research this carefully – the naming of the technology has changed over the last 18 months and there is as much misinformation and rumor out there as anything else. If in doubt, stick with what MSDN tells us.
more later - joel