Category Archives: CML

Elastra and data center configuration formats

I heard tonight for the first time of a company called Elastra. It sounds like they are trying to address a variation of the data center automation use cases covered by Opsware (now HP) and Bladelogic (now BMC). Elastra seems to be in an awareness-building phase and as far as I can tell it’s working (since I heard about them). They got to me through John’s blog. They are also using the more conventional PR channel (and in that context they follow all the cheesy conventions: you get to “unlock the value”, with “the leading provider” who gives you “a new product that revolutionizes…” etc, all before the end of the first paragraph). And while I am making fun of the PR-talk I can’t help zeroing on this quote from the CEO, who “wanted to pick up where utility computing left off – to go beyond the VM and toward virtualizing complex applications that span many machines and networks”. Does he feels the need to narrowly redefine “utility computing” (who knew that all that time “utility computing” was just referring to a single hypervisor?) as a way to justify the need for the new “cloud” buzzword (you’ll notice that I haven’t quite given up yet, this post is in the “utility computing” category and I still do not have a “cloud” category)?

The implied difference with Opsware and Bladelogic seems to be that while these incumbent (hey Bladelogic, how does it feel to be an “incumbent”?) automate data center management tasks in old boring data centers, Elastra does it in clouds. More specifically “public and private compute clouds”. I think I know roughly what a public cloud is supposed to be (e.g. EC2), but a private cloud? How is that different from a data center? Is a private cloud a data center that has the Elastra management software deployed? In that case, how is automating private clouds with Elastra different from automating data centers with Elastra? Basically it sounds like they don’t want to be seen as competing with Opsware and Bladelogic so they try to redefine the category. Which makes it easier to claim (see above) to be “the leading provider of software for designing, deploying, and managing applications in public and private compute clouds” without having the discovery or change management capabilities of Opsware (or anywhere near the same number of customers).

John seems impressed by their “public cloud” capabilities (I don’t think he has actually tested them yet though) and I trust him on that. Knowing the complexities of internal data centers, I am a lot more doubtful of the “private cloud” claims (at least if I interpret them correctly).

Anyway, I am getting carried away with some easy nitpicking on the PR-talk, but in truth it uses a pretty standard level of obfuscation/hype for this type of press release. Sad, I know.

The interesting thing (and the reason I started this blog entry in the first place) is that they seem to have created structures to capture system design (ECML) and deployment (EDML) rules. From John’s blog:

“At the core of Elastra’s architecture are the system design specifications called ECML and EDML. ECML is an XML markup language to specify a cloud design (i.e., multiple system design of firewalls, load balancers, app servers, db servers, etc…). The EDML markup provides the provisioning instructions.”

John generously adds “Elastra seems to be the first to have designed their autonomics into a standards language” which seems to assume that anything in XML is a standard. Leaving the “standard” debate aside, an XML format does tend improve interoperability and that’s a good thing.

So where are the specifications for these ECML and EDML formats? I would be very interested in reading them, but they don’t appear to be available anywhere. Maybe that would be a good first step towards making them industry standards.

I would be especially interested in comparing this to what the SML/CML effort is going after. Here are some propositions that need to be validated or disproved. Comparing SML/CML to ECML/EDML could help shade light on them:

  • SML/CML encompasses important and useful datacenter automation use cases.
  • Some level of standardization of cross-domain system design/deployment/management is needed.
  • SML/CML will be too late.
  • SML/CML will try to do too many things at once.

You can perform the same exercise with OVF. Why isn’t OVF based on SML? If you look at the benefits that could be theoretically be derived by that approach (hardware, VM, network and application configuration all in the same metamodel) it tells you about all that is attractive about SML. At the same time, if you look at the fact that OVF is happening while CML doesn’t seem to go anywhere, it tells you that the “from the very top all the way down to the very bottom” approach that SML is going after is very difficult to pull off. Especially with so many cooks in the kitchen.

And BTW, what is the relationship between ECML/EDML and OVF? I’d like to find out where the Elastra specifications land in all this. In the worst case, they are just an XML rendering of the internals of the Elastra application, mixing all domains of the IT stack. The OOXML of data center automation if you want. In the best case, it is a supple connective tissue that links stiffer domain-specific formats.

[UPDATED 2008/3/26: Elastra’s “introduction to elastic programing” white paper has a few words about the relationship between OVF and EDML: “EDML builds on the foundation laid by Open Virtual Machine Format (OVF) and extends that language’s capabilities to specify ways in which applications are deployed onto a Virtual Machine system”. Encouraging, if still vague.]

[UPDATED 2008/3/31: A week ago I hadn’t heard of Elastra and now I learn that I had been tracking the blog of its lead-architect-to-be all along! Maybe Stu will one day explain what a “private cloud” is. His description of his new company seems to confirm my impression that they are really focused (for now at least) on “public clouds” and not the Opsware-like “private clouds” automation capabilities. Maybe the “private clouds” are just in the business plan (and marketing literature) to be able to show a huge potential markets to VCs so they pony up the funds. Or maybe they really plan to go after this too. Being able to seamlessly integrate both (for mixed deployments) is the holly grail, I am just dubious that focusing on this rather than doing one or the other “right” is the best starting point for a new company. My guess is that despite the “private cloud” talk, they are really focusing on “public clouds” for now. That’s what I would do anyway.]

[UPDATED on 2008/6/25: Stephen O’Grady has an interesting post about the role of standards in Cloud computing. But he only looks at it from the perspective of possible standardization of the interfaces used by today’s Cloud providers. A full analysis also needs to include the role, in Cloud Computing, of standards (app runtime standards, IT management standards, system modeling standards, etc…) that started before Cloud computing was big. Not everything in Cloud computing is new. And even less is new about how it will be used. Especially if, as I expect, utility computing and on-premise computing are going to become more and more intertwined, resulting in the need to manage them as a whole. If my app is deployed at Amazon, why doesn’t it (and its hosts) show up in my CMDB and in my monitoring panel? As Coté recently wrote, “as the use of cloud computing for an extension of data centers evolves, you could see a stronger linking between Hyperic’s main product, HQ and something like Cloud Status”.]


Filed under Automation, CML, Everything, IT Systems Mgmt, OVF, SML, Tech, Utility computing, Virtualization

A sign of life from the CML working group

In a recent entry on this blog I remarked that “apparently restaurant owners are easy preys for incompetent Web site designers” because they often end up with stupid Flash-only web sites. Well, it’s not just restaurant owners apparently, it’s also leading technology companies like IBM, Microsoft, HP, Cisco, etc. For proof, have a look at the web site for the CML effort:

The only reason I would subject you to this awful site is that there is some news about CML. The group of companies involved in this effort has released a white paper to explain what CML is. You can spare yourself the Flash part by getting the white paper directly. If you want to spare yourself even more, you will also skip reading the white paper and just read my not-so-enthusiastic summary bellow. And you need neither Flash nor Acrobat to do so.

CML is going to solve parts or all of all problems related to IT management, and it will be based on SML. So much we can tell from the paper. Any other information that we glean there is contradicted somewhere else in the same paper.

No, really, isn’t CML a set of model elements expressed in SML? Yes, it says so:

“At its core, CML is a collection of models which are expressed as XML documents that describe IT entities and their relationships. As the basis for common modeling elements and semantics, the models describe information which can be exchanged between management tools and managed resources. This information is about IT systems and includes infrastructure (e.g., servers, application servers, Web services), logical entities (e.g., software license, incident reports, IT roles), and relationships (e.g., hosted, is hosted by, supplied by).”

But the next paragraph says:

“However, CML does not attempt to present a single model or single set of models which will ensure integration. Instead, CML provides a means for creating new models or extending, combining, or evolving existing models.”

We are also told that even though it provides a model of a server, it doesn’t supercede CIM. Oh, and it may not be just models either, it will also tell you about on-the-wire protocols:

“recommendations in the documentation, including the need to transmit models in an interoperable manner via an agreed upon set of wire protocols”

The “CML overview” picture leaves us with the same impression that it does everything and across the entire lifecycle at that. And I must admit that the nuance between “common modeling elements” and “shared modeling elements” escapes me, even after reading the definitions. I sounds like they are all reusable but some are more reusable than others…

If you are looking for a ray of hope, I found mine in the acknowledgement of the potential role of RDF/OWL which, combined with section 4.1.5, can be seen as hinting at an effort towards creating some simple ontologies for management integration. Which could be very useful if well-scoped.

If you are wondering about timelines, you’re out of luck. When referring to CML the white paper mixes present and future tenses, and also throws in some conditionals for good measure. Hard to guess how much is real at this point. And the next steps are? More scenarios and some guidelines. See you in 2009 (which BTW is consistent with my little theory about Oslo’s impact on CML).

All in all, this doesn’t mean nothing valuable will ever come out of CML. It just means that the group still hasn’t figured out what it wants to be when it grows up.

[UPDATED on 2008/01/24: Good news! They revamped the site to remove the stupid Flash interface. I hope my rant provided ammunitions to those inside the CML group who pushed for sanity. Also, they have put out a press release to announce, retroactively, the white paper. No surprise in the content of the press release and the associated vendor quotes. I wish that whoever wrote the quote for my ex-boss Mark Potts knew the difference between “compliment” and “complement” though.]

1 Comment

Filed under CML, Everything, Flash, Specs

Standards are good for customers… right?

Standards are good for customers. They avoid vendor lock-in. They protect the customer’s investment. Demanding standards compliance is a tool customers have to defend their interests when dealing with vendors. Right?

Well, in general yes. Except when standards become tools for vendors to attempt to confuse customers.

In the recent past, I have indirectly witnessed vendors liberally using the “standard” word and making claims of compliance with (and touting the need to conform to) specifications…

  • that have barely been submitted for standardization (SML),
  • that haven’t even been published in any form (CMDBF), or
  • that don’t even exist as a draft (CML – no link available, and for a reason).

Doesn’t something sound fishy when the logic goes through such self-negating statements as: “standards are good for you because they give you a choice of vendor. And we are the only vendor who supports standard X so you need to buy from us.” Especially when if it was true that the vendor in question implemented standard X, then it would not be their software that I would want to buy from them but their time machine.

All this doesn’t negate the fundamental usefulness of standards. And I don’t mean to attack the three specifications listed above either. They all have a very good potential to turn out to be useful. HP is fully engaged in the creation of all three (I am personally involved in authoring them, which is generally why wind of these exaggerated vendor claims eventually get back to me).

Vendors who are used to creating proprietary environments haven’t all changed their mind. They’ve sometimes just changed their rhetoric and updated their practices to play the standards game (changing the game itself in the process, and often not for the better). Over-eagerness should always arouse suspicion.

Comments Off on Standards are good for customers… right?

Filed under Business, CMDB Federation, CMDBf, CML, Everything, SML, Standards