Originating Author: David Floyer
As users taste more Web services their affinity grows for applications that are simple, scalable, high performance and always available. This naturally increases the expectations for IT to 'raise the bar' for internal applications.
Blade computing can help hardware availability, but recovery problems remain. Commodity OS suppliers, particularly Microsoft, are still stuck in architectures where the processor and OS are the fundamental units of computing, and the application has the responsibility of recovering from failure. In the meantime organizations like Google have developed high availability infrastructures where loss of any component does not impact the applications supported â€“ the infrastructure can automatically recreate state from other components. High availability is built in to the infrastructure, not added to the application.
Applications built as web services have very attractive cost and maintenance characteristics, both for applications built within an organization and external services such as Google applications premier edition. One of the challenges of architecting high availability systems for web service applications with commodity components is application recovery time. Hardware can fail over instantaneously, but recovery of state requires sophisticated software that is complex, takes significant time, and is often fragile.
Action Item: IT organizations should be wary of promising high availability web services built on blades or any other commodity hardware and software. Where they exist, IT should first qualify and make available external services built on high availability infrastructures that are protected from component failure.