logo

I've finally put my virtual pen to paper to contribute to our growing blog! I'm Vern Brownell, the founder of Egenera. I was an IT infrastructure customer eight years ago when I decided to create Egenera.

The inspiration for our technology was the frustration that I had with the complexity and brittleness of the computing infrastructure that had been built up in our data centers. The incumbent vendors seemed to lack interest in reducing complexity and were quite happy to sell more servers and infrastructure to exacerbate the problem. A light bulb went off for me and I decided that there was an opportunity to build a company around an architecture that would use virtualization and abstraction to simplify and dramatically improve the agility of data center infrastructure.

My view was that the server environment and the associated infrastructure needed to be simplified first. We took a clean sheet of paper design approach and set out to build the PAN Manager architecture that our customers use today.

Last month I was in China and was impressed by the universal support and sympathy that poured out from around the world for the victims in Wenchuan, southwest China. Compared to the tragic loss of over 69,000 lives, the loss of infrastructure and systems seems trivial. Nonetheless, it was another stark reminder of what can happen.

I recall that in data center threat analysis that I participated in years ago, earthquakes always seemed to rank as one of the most probable disaster events in earthquake prone areas followed by floods, fires and terrorist events. USGS reports that so far for 2008, there have been 269 earthquakes per month measuring 2.0-5.9 in magnitude in the US. Worldwide, there have been 2261 per month of the same magnitude.

As a former customer, I found providing adequate Disaster Recovery and Business Continuity Planning to prepare for events like earthquakes to be one of the hardest parts of running an enterprise IT shop. There are, of course, many issues which are not technology related, but technology is always an important part of business continuance planning. The classic rapid recovery method that most people seem to use is to provide duplicate hardware at two geographically diverse with some sort of data mirroring between sites. This method can work very effectively, albeit at significant cost and complexity. The lesson that I learned is the frequent testing is absolutely necessary and in fact in many or perhaps even in most cases the tests will not complete flawlessly.

Many of my friends and colleagues in IT in NYC and DC had to exercise their BCP plans with the terrorist attacks of 9/11. Although I was no longer in the IT business in NYC and I did not experience this tragedy first hand, I've heard that most firms that had this style of DR did quite well with their recoveries. So what's the problem? It really comes down to expense, complexity and power.

The classic method requires a significant duplication of hardware, furthermore each time a system is changed in the slightest way, the backup system must also be updated. This is error prone. Most of the failures that I have seen were the result of misconfiguration of infrastructure or applications. It takes tremendous effort to keep two systems in complete sync. It's always a tough investment to prepare for something that hopefully will never happen. And given the nature of the costs and effort, this type of backup is almost certainly only done for the most critical of applications.