Andreessen sees DCML taking off

Opsware Chairman Marc Andreessen has never shied away from the bleeding edge. The creator of Netscape, which was one of the fundamental drivers that helped popularize the Internet, Andreessen has consistently pushed toward that edge and suffered some cuts and bruises but never a critical amount of blood loss.

At Opsware he oversees the company's aggressive efforts to forge the concepts of automating the complete IT life cycle of large companies, including provisioning, deploying, changing, and scaling, and consolidating servers and business applications as a way of lowering IT costs. Opsware is now attempting to extend the envelope proposing the new Data Center Markup Language (DCML) and the DCML Organization that will serve as a foundation on which users can build interoperable applications in hopes of making utility and grid computing into practical realities.

Q: How soon do you expect to gain the support of IBM, Microsoft, and Sun Microsystems on this?

Andresseen: Well right now we have companies like Computer Associates (International), BEA (Systems), EDS (Electronic Data Systems), Tibco (Software), MicroMuse, and NetIQ. And if you look at the cross section of vendors like CA, NetIQ, MicroMuse, they comprise a very large percentage of the installed monitoring systems. Tibco is petty dominant in enterprise messaging and BEA has good share among Web application servers, so we think this is a really good starting point. The observation that we make is, traditionally the big technology companies tend to be late adopters of standards, especially standards they didn't invent. But they eventually adopt them in response to customer demand because customers are usually very much in favor of this kind of thing, which is what we think the case will be case here. They move relatively slowly to wait to see what sort of traction it gets. So I think it will take a little time.

To me the analogies that apply here are to TCP/IP and HTML, which all the companies you just mentioned were not in favor of originally but ended up adopting them and are enthusiastic supporters of them. DCML is that kind of thing where they can pick it up and adopt it whenever they want. The standard is open and they will be able to pull the Reference Implementation down off the Internet like anyone else. So in time it will be easy for them to support.

Q: Do you intend to take this to standards bodies such as the W3C and OASIS, and, if so, when?

Andresseen: That will be something under discussion with the original 25 partners. It will be one of our first topics of discussion. It will happen for sure, but we will talk to the group at large to discuss the timeframe.

Q: How long before some of the companies backing this can deliver products that ascribe to the standard?

Andresseen: They can start rolling out product that will be interoperable starting early next year. What will happen is the 1.0 specification will be out early next year, sometime in the first quarter. We will ship a DCML 1.0-based version of Opsware early next year. Then we will release both a Reference Implementation of DCML source code in open source form also in next year's first quarter, and then also a set of open source DCML descriptions of a lot of the common components that make up a datacenter like a lot of the common servers, and software products like Oracle and BEA. So people should be good to go basically in first quarter of next year. And also, as a vendor you will be able to implement DCML however you want in your own commercial products.

Q: How did the discussions come about among the founding companies for this?

Andresseen: The original discussions go back nearly a year to when EDS and Opsware started working together. We found ourselves dealing with a lot of the issues that we talk about around DCML from a pragmatic standpoint. We would talk about how do you describe datacenters? How do you describe elements of datacenters? How do you describe servers? How do you know which patches are on which servers? When you do a code push how do you know what servers to push the code onto and how do you know what the configurations should be? We (EDS and Opsware) do all those things, but do them in a proprietary way. So we realized it would be nice if we just opened that all up to increase interoperability. Also EDS, like all of our other customers, rolls out Opsware in conjunction with a monitoring system and in conjunction with a billing system and a tracking system and so forth, so there needed to be a way to plug all those together. Instead of creating a bunch of proprietary APIs we wanted to do that in an open way.

Q: You mentioned most of the components of the datacenter that it will encompass, but what about tools?

Andresseen: Exactly. From a tools standpoint you are talking about two different kinds of tools: development tools and production or management tools. On the management tools side, and that is a big thrust of today's announcement, you have companies here like MicroMuse and NetIQ and Mercury ... Well this is going to be the standard way these tools interoperate. Basically. what all of those vendors will do, including us, is to make sure all of our tools interoperate and work smoothly together.

When people develop apps they should be able to specify during the application development process more of what they expect the production environment to be like. Like what versions of middleware is it going to run on, what servers, how much storage it needs, how it should scale in response to capacity, and how it should be monitored. Today, applications do not have a standard way of exposing these things out to the people who are actually responsible for making them run. This is why it is so hard to keep these systems up and running. So this will be a way for app dev tools to basically provide a capability for the developers to describe more of those things. (With this standard), application development tools will start to emit DCML descriptions of the anticipated production environment along with the application itself. That will take a little more time though.

Q: IBM and Sun are already working on grid and utility computing and leveraging the Globus Toolkit. And there is some application activity taking place in grids and the utility model. Does that make it more pressing to get IBM and Sun on board?

Andresseen: It will take a little time. Companies like IBM prefer, if possible, to be in a position of control. Sun's whole strategy right now is if you buy everything from Sun it will all work together. As users continue to buy from lots of different vendors they want openness and they want choice. If you bought your whole IT environment from IBM 15 years ago, for instance, you could have it all networked together with SNA (Systems Network Architecture). But if you introduced anything else from another vendor all of a sudden it did not work. The same thing is true today for a lot of their utility computing stuff. One of the reasons users are not buying more of it is (because) they are just not happy with that proposition at all.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about BEACA TechnologiesEDS AustraliaElectronic Data SystemsIBM AustraliaMicromuseMicrosoftNetIQOpswareOracleSun MicrosystemsTibcoW3C

Show Comments