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!…?
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.
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.
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 😉
you are awesome. sad fact – i bet you hear dick from the BigCos on this.
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
expression.
Has someone analyzed the abstract operations of
WS-Management
http://www.dmtf.org/standards/published_documents/DSP0226.pdf
or WSDM
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
to look at the efficiency and ease of implementation of
a REST-encoded equivalent protocol for the same operations?
Do you know if any of the open source CIMOM projects, e.g.
http://www.openpegasus.org/manual/CIMOperationsoverHTTP.html
http://wbemservices.sourceforge.net/
http://openwbem.sourceforge.net/
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,
http://www.dmtf.org/standards/published_documents/DSP0207.pdf
If this were occuring, would be a possible starting point.
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 😉
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 CMDB.info 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
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.
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 😉