The future (2006 version), has arrived

Remember 2006? Things were starting to fall into place for IT management integration and automation:

  • SDD was already on its way to cleanly describe/package/manage the lifecycle of simple and composite applications alike,
  • the first version of SML came out to capture all the relevant constraints of complex and composite systems and open the door to “desired-state management”,
  • the CMDBf effort was started to seamlessly integrate all sources of configuration and provide a bird-eye view of your entire IT infrastructure, and
  • the WSDM/WS-Management convergence/reconciliation was announced and promised to free management consoles from supporting many resource discovery, collection and control mechanisms and from having platform/library dependencies between the manager and its targets.

It looked like we were a year or two from standardization on all these and another year or two from shipping implementations. Things were looking good.

Good news: the schedule was respected. SDD, SML and CMDBf are now all standards (at OASIS, W3C and DMTF respectively). And today the Eclipse COSMOS project announced the release of COSMOS 1.1 which implements them all. The WSDM/WS-Management convergence is the only one that didn’t quite go according to the plan but it is about to come out as a standard too (in a pared-down form).

Bad news: nobody cares. We’ve moved on to “private clouds”.

Having been involved with these specifications in various degrees (a little bit on SDD, a fair amount on SML and a lot on CMDBf and WSDM/WS-Management) I am not as detached as my sarcastic tone may suggest. But as they say in action movies, “don’t let sentiments get in the way of the mission”.

There is still a chance to reuse parts of this stack (e.g. the CMDBf query language) and there are lessons to learn from our errors. The over-promising, the technical misjudgments, the political bickering, the lack of concrete customer validation, etc. To some extent this work was also victim of collateral damages from the excesses of WS-* (I am looking at you WS-Addressing). We also failed to notice the rise of the hypervisor in our peripheral vision.

I tried to capture some important lessons in this post-mortem. For the edification of the cloud generation. I also see a pendulum in action. Where we over-engineered I now see some under-engineering (overly granular interaction models, overemphasis on the virtual machine as the unit of everything, simplistic constraint models, underestimation of config/patching issues…). Things will come around and may eventually look familiar (suggested exercise: compare PubSubHubBub with WS-Notification).

As long as each iteration gets us closer to the goal things are good.

See you in 2012. Same place, same day, same time.


Filed under Application Mgmt, Automation, Cloud Computing, CMDB, CMDB Federation, CMDBf, Desired State, Everything, IT Systems Mgmt, Manageability, Mgmt integration, Modeling, Protocols, SML, Specs, Standards, Utility computing, WS-Management

3 Responses to The future (2006 version), has arrived

  1. My two cents.
    First, your blog is great …
    Second, I’m not as expert as you are …

    I think what is missing in the approach is more a systemic approach of IT instead of a very focused technical vision of infrastructure Mgt.
    CMDBf should be reused, we may need more explanation of why it is interesting, and provide some open source around it (or at least free of charge implementations).
    The job of sysadmin is also changing, so it will take some time for them to move to cloud. That’s why I thing we need a more global vision of how it fits in new models.

  2. The major difference between the management ingetration efforts of 2006 and now are that the existing management objects(hypervisor, clouds) by itself enable a lot of management integration of the provision,monitor,re-configure cycles, whereas that integration was something that a third party effort which promised the integration, which didn’t really add much value. The other important difference is that management aspects are very much part of the solutions(hypervisors,cloud) rather than an after thought in the earlier days where it needed a third party vendor to close that gap. Fundamentally, management needs to be simple and self sustaining and should not get in between the real work. From that perspective, an overly simplistic view doesn’t hurt IMO.

  3. Stu

    Regarding that post-mortem and the lessons you draw from it.

    I agree the primary issue is a modeling problem, not a protocol problem. But (quelle surprise!), I disagree with your characterization that one can just “pick a protocol”. OK, if you are just talking about “bits on a wire”, then yeah, pick one.

    But I think the broader part of the “modelling problem” is the whole issue of data management: stewardship, provenance, governance, identification, lifecycle, etc. As you’ve suggested, we’ve been busy working on *mechanism* for manageability, and our industry’s attempts at management integration standards have usually devolved into more mechanism for manageability. Perhaps one reason is that these approaches have neglected that data management is an essential part of management integration.

    The SOA world saw this problem too, and it led to a twinkle of interest in customer data integration hubs, data services platforms, or master-data management (MDM) servers, but these solutions still seem to be relegated to the data warehousing and BI communities. And in the management space, CMDB’s solve this problem no differently from how a data warehouse solves the problem, i.e. reasonably well for some use cases, but at great expense to maintain.

    The main reason I am such a proponent of REST has little to do with HTTP, to the point that I almost bristle when we, as a community, too easily conflate the two. While 80% of the noise over REST is about HTTP, the real insight and excitement has to do with URIs and hyperlinking. These concepts bring data management to the forefront of networked application architecture. “Bits on the wire” are not the centre of the universe; the identifiable and/or referenced information resource is the centre. This industry has to evolve beyond message passing and “throw everything into a big database”, if we’re ever going to make major headway with integration problems.