This is Part 2 of PDC, if you missed Part 1 check it out.
The Azure content at PDC was mostly new to me, although for those that have been following the Azure announcements closely, I’m told there was little news that would be considered new. Nonetheless, there were some important things that I’d like to mention here.
AppFabric is a new technology in Azure that I still need to go back and review the presentations to more clearly understand. AppFabric facilitates dividing an application into component sets and defining how each component set should scale. There was a very good demonstration during the keynote regarding how AppFabric can allow for websites to automatically spin-up new instances as needed to handle high traffic situations, then collapse back to the baseline configuration when the surge has passed. While this isn’t a unique cloud concept, the AppFabric announcement outlined how this will be accomplished in Azure. AppFabric also enables cloud to on-premises connectivity. It also includes security management. This short description hardly does AppFabric justice, so check it out for yourself.
Microsoft trucked in a mini-Azure container for the show. You can see some pictures here.
The Azure container was an impressive display of thinking outside of the box. By sticking hundreds or even thousands of servers in a shipping container, Microsoft can drop massive amounts of computing power in a parking lot, resulting in rapid growth of their cloud computing power. The containers are all-weather, self-regulating and require connection to power, water, and the internet. If you think about the alternative of building massive buildings with huge AC and fire suppression systems, this is an impressive low cost way to scale.
Additional announcements around Azure include support for PHP, Java, SAP, and MySQL.
For me, the most exciting Azure learning was around SQL Azure. SQL Azure is a real database platform in the cloud. The problem with most cloud data storage is that the storage is like “blob” storage, or perhaps you prefer the definition of a REST entity data store. For the most part, data is pushed and popped from the store by Ids. There is more to it than just this simple explanation, but whatever it may be, it isn’t a traditional relational database that is easily accessible via query, with joins across entity objects.
Previously, if you wanted a real database in the cloud, you needed to use an infrastructure cloud platform, where you can host an SQL server instance (or your database of choice) inside a virtual machine. However, if you wanted redundancy and scalability, this required you to setup multiple virtual machines with multiple SQL server instances, along with the need to setup and manage replication. SQL Azure removes all that mess and allows for a database that is easily accessible with built in redundancy, and scalability (up to its current size limits.) While at PDC I was able to use the onsite computer lab to do a hands-on Azure lab. It took me 10 minutes to create an Azure account and instantiate an SQL Azure database. I configured the account to only allow my IP address on an incoming connection, then connected to the SQL Azure database using SQL Management Studio running on the local computer in the lab. That was all it took. From that point I had full access to do whatever I would normally do to create a database right from my local PC.
I asked the Microsoft rep at the SQL Azure booth, “So what’s missing?” “Not much,” was the answer. Full text indexing isn’t supported yet and neither is the XML data type. There is also a size limit on the database that is currently “small” by many enterprise standards, but 10GB isn’t too shabby. I’m sure there is an exhaustive list somewhere, and I’m sure master DBAs would cringe at the statement “not much,” however the core of what we consider standard database stuff is there, including stored procedures, views, and triggers. SQL Azure also has the ability to synchronize with on-premises databases.
SQL Azure didn’t start out as a relational database and in the early days there was some question of if and when SQL Azure would become a relational database. Most data platform solutions such as Amazon S3 and Google App Engine’s Data Object Store, as well as SQL’s original entity storage called SQL Tables are simple key based entity data stores. The stores are perfect, in fact often required, for the killer applications on the web, such as Facebook, due to their high volume, and mostly independent style of data access. However, most applications that run on the internet don’t have the demands that exceed what can be handled by a relational store. Additionally, most of those applications use the data in ways that require the features of a relational store, such as reporting and aggregation. To take most existing applications and move them to one of the entity based data stores would almost always require a complete rewrite of the data access methodology. So it was a bit of an odd situation to have the cloud that could scale massive applications, and a data store that matched the same needs of the massive applications, but there were relatively few applications that really needed that type of hosting environment. Most of the applications didn’t really need or want what was being sold, when it came to data. SQL Azure’s relational data store now fills that gap, and makes it much easier to take existing applications to the cloud, and avoiding the mess of managing virtual machines in the cloud.
SQL Azure will be production live in January 2010.
See Part 3 for the Everything Else part of the PDC review