At Web 2.0 Expo Microsoft essentially stole the show with the introduction of its Live Mesh platform. Live Mesh is, essentially, an integration hub that incorporates and manages Internet connected devices that today are unrelated and managed individually using open standards.

Microsoft might not like the term "integration hub", but that's basically what it is. Yes, on the surface it's a platform that enables inter-device communication and seamless access to a variety of services, but under the hood it's got to be doing some pretty complex integration work. While Microsoft plans on using open standards, that doesn't mean that those standards allow devices to communicate directly. My Blackberry, Outlook, and storage devices don't use the same interface, after all; in order to communicate and share data across disparate device there must be some kind of integration (i.e. translation of data formats) going on.

Now that sounds cool. Who wouldn't be interested in being able to copy data from remote or local storage over to their digital picture frame? Or from their camera to their picture frame and their remote storage for backup?

This is one heck of an initiative, and it sounds hella cool. But (and there's always a but) it's going to take a massively resilient and flexible infrastructure to ensure that all the disparate points in the mesh are always available, secure, and perform up to consumer expectations. Microsoft is right in that consumers, because this is the market at which Live Mesh is targeted, do just want things to work.

The danger in these kinds of initiatives is the same danger that's always existed: if you fail to ensure that your infrastructure can handle a new application you may be faced with a massive, hurried "fix-it" project after the fact. First impressions are the most important, and if you got it wrong the first time it's very difficult to change that and convince potential customers you got it right the next time.

This is where things are going to get ugly. Microsoft can certainly ensure that its services are available, secure, and fast within the mesh. But if this platform is successful customers will want to include other services from other vendors in their mesh (which is what Microsoft anticipates, that's all good) and that means other services - over which Microsoft does not have control - may negatively impact consumer perception of mesh. Which means that Microsoft will need to impose some kind of service level agreements on service providers who wish to make their services available in "the mesh" and that service providers are going to have to ensure that their application delivery infrastructure can provide fast, secure, and always available access for its services.

Acceleration, security, optimization, intelligent routing...all these capabilities will be necessary to ensure that every service in the mesh is available, secure, and fast as well as highly scalable. How about secure remote access so you can access your "devices" at work while you're at home, and vice versa? The possibilities here are endless, but they are going to require a lot of infrastructure support to make them all reality.

If - and I do mean if - this takes off as well as Microsoft hopes, it certainly could be the killer-app for application delivery.

Imbibing: Coffee

Anyone who's listened to Bob Rivers' Twisted The Twelve Pains of Christmas can probably relate to the angry husband screaming, "When one light goes out they all go out!" because, yeah, we've all been there.

Imagine now, if you will, a data center. A data center filled with servers humming along, each running three or four applications in virtual machines a la VMWare. Imagine now - it shouldn't be hard at all - that one of those servers suddenly just stops working. Let's say the drive crashes.

After the blue smoke dissipates and the screams of "When one component crashes they all crash" fade away, it's time to consider what just happened. (Yeah, the analogy here is a stretch, but try to go with it this morning, okay?)

Yes, OS virtualization has its benefits, there's no doubt about that. But like SOA and the challenges associated with composition-based application development, there are some interesting challenges associated with virtualizing the data center using OS virtualization. This challenge is particularly frustrating because aside from ensuring that the underlying hardware and OS upon which the virtualization solution is installed are stable and redundant, there isn't anything you can do to prevent this scenario from taking down not one but all the applications running within virtual containers on that server.

Even if it isn't a crash that causes the downtime, maintenance, upgrades, and patches will require the server be shutdown or rebooted, which means all the applications running within virtual containers on that server are going down.

You may recall that I walked through a BEA TCO analysis of virtualization and ended up with some controversial results. This subject is no different in that regard.

You'll notice that the blue in the stacked graph here represents "unplanned downtime". Now, I'm not sure what the definition of unplanned downtime is, but I assume that it's downtime that wasn't planned. :-) Seriously, I make the assumption that this category includes downtime resulting from things like hardware component failure, emergency patches, etc...

I find it interesting that the non-virtualized environment has more unplanned downtime than the virtualized OS. Presumably this is because there are fewer hardware servers and thus fewer things that can go wrong to cause the downtime in the first place.

What bothers me is that the cost of unplanned downtime must necessarily include things like lost revenue and productivity, and this is likely to be higher in a virtualized OS architecture because if one server crashes multiple applications are likely going to be affected. Imagine if it was SOA services and processes deployed across a virtualized OS architecture. Talk about a ripple effect.

Regardless of whether its SOA or traditional web-applications deployed on a non-virtualized or virtualized OS architecture, you need some kind of assurance of availability and resiliency. That kind of assurance comes from an application delivery network.

So if you're trying to mitigate the risk associated with downtime in either environment an application delivery network is going to be your best option. Even though you can bring new instances of your applications on-line in the event of a failure - extremely quickly and painlessly in the case of a virtualized OS architecture - you still have to make sure clients and customers can actually reach the new instance, and that means some sort of intelligent routing capability - the kind of intelligence you get with an application delivery controller as part of an application delivery network.

Imbibing: Coffee

There's a lot of things that BIG-IP can do to improve the reliability, scalability, and performance of Web 2.0 applications. But there are always two sides to every story, and so it is with BIG-IP and Web 2.0, or specifically, AJAX.

This latest article, Getting Started with iControl and AJAX, offers advice and code to get you started building a custom AJAX-based dashboard for BIG-IP.

Imbibing: Coffee