Skip to content

Getting Giddy with the CMDB: REST, Cheap Spread, and Wet CIs

At the moment, the golden goose of the IT management world is the CMDB. Thus, as someone who is addicted to covering and thinking about systems management (I haven’t found the cure yet, though identity is getting close now-a-days), CMDB and I are always passing each other in the hall. We even get coffee from time to time. He like to lunch at much more pricey places than I — that guy who just stand there the whole time freaks me out! — so we draw the line there.

Along those lines, here are some disconnected mental notes on my friend CMDB:

CMDB + REST == Yuh!…?

CMDB Interfaces

Have you seen the CMDB Federation white-paper (from these folks)? Not too shabby, esp. since it’s just 10 pages; take the Skeptic’s advice as a bracer. My main thought: for those interfaces get REST in/on there! Why not ATOM too?

REST/ATOM is all about a standard and simple (!) API for creating, updating, reading, and deleting “resources” described by URLs. What’s a Configuration Item but a resource that’s always being created, updated, read, and, maybe, deleted. There’s relationships between CI’s as well which, my gosh, the REST world having coming out their eyeballs from the public web, which has — what? — 60 different answers for describing relationships, a handful of which have even been road tested over years and at scale.

More reasons:

  • Why come up with some horky WS-*/SOAP spec when you could just define the URL (ok, ok, “URI”…whatever) addressing of CI’s, how relationships are expressed, and then slap an ATOM interface on top of it?
  • More importantly, REST and ATOM are simple approaches to complex problems that developers actually like.
  • (Hint: REST and ATOM are web services, just not Web Services.)
  • With a REST/ATOM interface, the CMDB would be dead-easy to integrate with other systems, not just other CMDBs. Metcalf’s Law with your coffee, sir?

Sounds like a standard approach that’s completely doable and effective to me.

So: any CMDB geeks want a connect to some REST/ATOM geeks? If RedMonk is a lonely connector between any two groups, it’s those!

I know Mr. Twiggs would get giddy.

CMDB Federation Interop

To that point, isn’t the CMDB federation group (they don’t have an official title, do they?) more about CMDB interoperation than federation? I get that you need interoperation to enable federation, but actually cracking the nut of CMDB interoperation (standardizing the interfaces and somehow coming up a data model or semantics packaging) seems like the real and most difficult effort.

Low Barriers to Entry Needed

To that point, it seems like having proprietary interfaces and data models is what’s holding CMDB’s back from wider and easier use. SQL made RDBMS “work,” in this sense, and having an open standard for CMDBs should have a similar effect.

Now, for those same reasons I’m also suspicious of how much vendors charge for CMDBs. Wanting to maximize profits on a roach motel aside (go-go revenue!), a model where CMDBs are given away — or (gasp!) open source — to bring in revenue for the supporting tools seems much more reasonable for spreading and developing the CMDB at this point (selling scale and whiz-bang a la Oracle might fit later). But hey, I’m open-biased.

Put another way: do enterprises still want to subsidize the development of core technologies by paying for “1.0” products? The implication being that 1.0 products don’t, ahem, “work” so well and the customer is more doing a fancy dance to fund development than buying a finished product. See Oracle’s early history with the US Navy, CIA, and other large organizations.

Another nail: really, we know the value in a CMDB is setting up, “configuring,” and hooking it into an enterprise’s process and IT. It’s a services sale centered around a chunk of software. Gating that software with license sales just limits the number of much higher paying service engagements the vendor and SIs can do.

Skills as CIs

Do the skills required to maintain IT belong in the the CMDB? Peter points out a discussion in an IMS list about a lack of skill and (my re-wording) enterprises not treating that skill as mission critical to the business. It’s a wetware boundary problem. Sounds like a CI to me — A “Wet CI”? — but then that means hooking up to identity provisioning and de-provisioning.

It seems kind of ridiculous, but comprehensive.

(Thanks to Chip for kicking the rust off my mental CMDB gears yesterday.)

Disclaimer: several companies in the “CMDB space” are RedMonk clients: BMC, IBM, Microsoft, and probably others who’d benefit from the spread of CMDBs.

Categories: The Analyst Life.

Comment Feed

13 Responses

  1. You are absolutely correct, but I agree with James – fat chance any big vendor is going to jump on this …

    In any case any of them do, count me in as a REST geek available for hire.

  2. Those are all excellent points, as usual, Mark. There'd definitly be some transactional considerations. And, as you anticipated, the REST camp reply would be the re-orient the requirements to remove two phase commit.

    Also — and to be fair to the Federation folks — as I got to one of the other points, the major interest I have is in creating an open interface for CMDBs that (hopefully) could be used for federation as well. But, if the implementation of federation doesn't work with the less than transactionally perfect nature of REST (at the moment, hopefully), then other stuff would be needed.

    In that case, I'd hope the idea of having a REST interface on CMDB's could be moved to a more appropriate forum, or just CMDB's in general.

    I don't know if anyone has looked to map WS-Man and WSDM to REST. I'm guess not. It'd certainly be a fun exercise and, speaking personally, a good excuse to read those specs 😉

  3. you are awesome. sad fact – i bet you hear dick from the BigCos on this.

  4. I’m afraid I see a gap – the CMDBF white paper doesn’t spell out what kind of operations are going on between these components. Without this, it’s hard for me to evaluate whether a REST/ATOM model would be the best.

    E.g., if the operations were limited to
    get properties of a specified configuration object
    set properties of a specified configuration object
    get notified of a change of properties

    then a REST model seems viable, but then so does SNMP.
    SNMP is widely deployed, easy to implement in everything from a toaster to a data center, etc.

    But what if the operation is a two-phase-commit? If foo is split across two CMDBs, and an application says “increment foo’s counter bar”, it might cause causes this federation component to have to negotiate managing separate transactions on the CMDBs. Distributed Transaction Controller advocates would argue that existing protocols for 2PC should be leveraged for this operation; REST advocates might argue that the operations should be changed to avoid the need for 2PC.

    > Why come up with some horky WS-*/SOAP spec when you
    > could just define the URL (ok, ok, “URI”…whatever)
    > addressing of CI’s, how relationships are expressed,
    > and then slap an ATOM interface on top of it?

    I would have assumed that a WS-* spec from CMDBF would
    leverage the already-existing WS-Management and/or WSDM
    for some of the heavy lifting of data and protocol

    Has someone analyzed the abstract operations of
    or WSDM
    to look at the efficiency and ease of implementation of
    a REST-encoded equivalent protocol for the same operations?

  5. Do you know if any of the open source CIMOM projects, e.g.
    or SNIA, have or are adding a REST alternative to their WBEM? There’s a recent spec for assigning a URI to each element in the CIM repository,
    If this were occuring, would be a possible starting point.

  6. Dunno off the top of my head, Mark. But, obviously, it's something to start to paying attention to. Any findings yourself? I'm glad you've taken such interest in the topic here 😉

  7. Cote, what do I say, its hard to mount an arguement to the contrary, but the vendor community will continue to build the hype and their proprietory interfaces just as long as the debate continues about standards and the maturity of ITIL. Its the utopian view of the world. Having an operations management background the information I require is a little different from the guys at the Ops Centre Flightdeck, and different again from the Change Managers. I need to know costs per device and service levels, etc. Take a quick look at for the details of an Open Source Framework for a CMDB. There are lots of functional tools in there, such as Nagios, Nmap, OCS Inventory, Oreon, etc. The only way there will be a set of standards emerge is to take the development of an industry standard within the Open Source Community. The REST and ATOM standards are an interesting debate, but under current capabilities I use Nmap, if something is on my network and its running an IP Stack, it can be found and further interogated in all sorts of ways. To progress on working towards standards, one requires a functional framework. Check out what is included in the stable build specs. BTY Great Blog. Cheers

  8. Yes, I’m giddy!

    If my upper management were as giddy as me, then shit would start happening. Alas, I don’t think it will, but I’ll continue to talk it up.

  9. Brendan: thanks for the commentary and pointers. I've been keen to see the open source CMDB(s?) pan out.

    Mr. Twiggs: indeed. Too bad there isn't more slack time to try out new things 😉

Continuing the Discussion

  1. […] And I’ll throw a crazy one out there (crazy based on it’s revenue as I understand it): how about the CMDB? Could one come up with a plan where-in open sourcing it would actually be more profitable than keeping it closed source? It’d certainly be mud in the eye of the rest of the Big 4 and CMDB vendors. In BMC’s case, there’s the AR system, the runtime framework underpinning many of BMC’s highly successful products like Remedy and the CMDB. Less dramatic, I suspect the CMDB Federaton would benefit from an open source project or two. Here’s one idea. […]

  2. […] (Related, see my short note and the resulting reader comments on the CMDB Federation standard effort.) […]

  3. […] to have anything to do with REST. Not that it didn’t cross the mind of a bunch of people, lead by Michael Coté when CMDBf first emerged (read the comments too). But as James Governor rightly predicted in the […]

  4. […] to have anything to do with REST. Not that it didn’t cross the mind of a bunch of people, lead by Michael Coté when CMDBf first emerged (read the comments too). But as James Governor rightly predicted in the […]