Last year, some 40 management tool vendors formed the DCML Organization, a consortium committed to developing an open standard to facilitate interoperability and better integration between tools. Vendors say the the evolving Data Center Markup Language will be critical to the development of utility computing and simplify life for data center managers. The first release of DCML is scheduled this quarter, with products adapted to the specification expected by midyear.
One of the leaders of the effort is Tim Howes, chief technology officer at Opsware Inc., a data center software automation vendor in Sunnyvale, Calif. He discussed the motivations for developing DCML and its technical challenges and potential user benefits with reporter Patrick Thibodeau.
Q: What problem is the DCML Organization trying to solve?
Over the past five to eight years, there has been a tremendous explosion of complexity in the data center. The problem is that the traditional management tools haven't kept up with that explosion. You have something doing monitoring, for instance, that needs to communicate with something doing provisioning.
Think back 10 years ago. There were relatively few servers in the data center. Those servers were relatively large, and they were running a relatively small number of applications, maybe in the dozens. Today, there are literally thousands of servers in data centers, as well as hundreds or thousands of applications running across those servers. The complexity of managing that has just gotten out of hand.
Q: Where are existing management tools falling short?
It's not so much that they are falling short. The problem is that no one company writes data center management software that solves the entire problem. Even if there were such a company, would you really want to put all your eggs in that basket?
Q: Where does DCML fit in?
There's a need to have all these management products communicate with one another, and that's what DCML is about -- providing a common data format for exchanging information about the environment being managed between all of these different management systems.
Q: Can you give an example of how that would work?
When you provision a new machine, you want to make sure that machine is monitored, so you need to communicate to your monitoring system that there's a new machine to be monitored. Today that happens, if you are lucky, by somebody leaving a Post-it note on the monitor of the guy who runs the monitoring system. But DCML allows that to happen in a more automated fashion. Similarly, that happens with security systems, backup systems -- there are all kinds of different systems. DCML provides the vocabulary, the language if you will, for those systems to communicate with each other.
Q: How long is the list of applications and systems potentially affected by DCML?
The list is ultimately as long as the variety in the data center -- any system that you are using to manage your environment. We're focused on the data center because that's where we think the most complexity is, but the complexity actually extends beyond the data center to other environments as well, and there's nothing to prevent you from applying DCML to those environments.
Q: What are the initial goals for DCML?
We're trying to create a standard data format that can be used to exchange information between automation and utility computing systems and traditional management systems. The use cases that we have in mind are: making sure provisioning systems can communicate with the systems that manage the machines that they provision; making sure those systems can communicate with the asset-tracking, inventory and billing systems that are responsible for keeping track of what's going on in the environment; and translating that into billing for customers or cost accounting for internal purposes. We want all these things to be able to communicate with one another.
Q: What technical challenges do you face?
The biggest technical challenge is being able to deal with the level of diversity that's out there. Another technical challenge is to define DCML in such a way that it can be adopted incrementally so that neither vendors nor customers have to radically change their products or how those products are used.
Q: What kind of information must be exchanged, and in what format?
The format is XML-based. The information really falls into three categories. The first is the physical components themselves -- the environmental information, such as characteristics of the server and networking gear. The second type of information, called the library, is the best practices and policies that you want. Finally, there is the blueprint, which shows how to combine those physical components in with the best practices that you specified in the library to produce an actual environment. DCML is not going to mandate the best practices. Instead, it will provide the mechanism to express best practices that would be different from one IT department to another.
Q: The big challenge in writing standards is often political -- balancing competing vendors' agendas. Is that true here?
It's always a bit of a challenge. We've got an opportunity to decide whether we want to make a standard that's very useful on the ground and works or that satisfies the political winds of different players. Historically, the standards that are successful are the ones that stay focused on implementation and adoption. Success to me is not how many [vendors] sign up and say they are going to support the standard. Success is how many get it into their working code and then how many customers end up using it.
Q: Some big vendors, including Sun Microsystems Inc., Hewlett-Packard Co. and IBM Corp., aren't involved with DCML. Can you succeed without their participation?
It's not at all surprising to me. The big companies are invested in their own proprietary technologies, and they often don't see it in their interest to migrate to an open standard until or unless their customers force them to do so.