Manageability, management integration and WS-Management

It is pretty clear by now that, whether or not it becomes ubiquitous, WS-Management will be around for quite some time as a protocol for resource manageability. Its inclusion in a large number of manageable products with long development cycles (servers, devices, operating systems…) ensures this. But I wonder whether it will also be useful for management integration.

The difference between manageability and management integration may not seem obvious, but it is important. To simplify, a manageability protocol is something that allows you to remotely manage a resource without having to deploy an agent on it. It lets you read the CPU load on a server. It lets you retrieve a list of instances running in a process engine. It lets you reboot a machine. It lets you access the logs of an application. It lets you receive alerts about a resource. Management integration, on the other hand, lets you create management solutions. For example, it’s what you do when you create a management dashboard that presents information aggregated from several management data repositories (e.g. a CMDB, a metrics store and a SOA registry). Or when you run system-wide validation rules to govern a complex system. Or when you perform automated root cause analysis.

Here is another way to illustrate the difference: CIM is useful for manageability. The more recent standardization efforts in the management world (SML, CMDBf) have been focusing on management integration. To some extent, you can even use that difference as the shortest answer to the common question “what is the relationship/difference between SML and CIM”: CIM is designed for manageability and SML for management integration.

The difference between manageability and management integration isn’t alway clear-cut. There are scenarios that could be argued to fall in either category. And management integration scenarios often involve manageability interactions. But if you try to implement management integration scenarios by working at the manageability level, you very quickly get bogged-down. And even if you fight your way to completion, the resulting integration is too brittle to be of any long-term use. You need a level of abstraction over manageability. This is very similar to integration problems in other domains, and this is where SOA comes in, as a design approach to provide resilience and flexibility for management integration. SOA doesn’t help much in manageability scenarios. It can be useful for management integration.

People working on using Web services for management never had a shared understanding of this distinction. If you look at Microsoft’s early scenarios for WS-Management (and their partner list), it is clear that they were focused on manageability, mostly of the Windows OS, the computers it runs on and the devices connected to these computers. On the other hand, when my colleagues at HP Software and I produced WSMF and later worked on WSDM and WS-Management, it was management integration that we cared most about. We didn’t really care much to put a SOAP wrapper around manageability operations. But we understood that this was also happening and it made sense to share tools and expertise between the two sets of scenarios, especially since, as mentioned above, they overlap.

What happened is that manageability is the only place where WS-Management took hold. One reason is that Microsoft was the main force pushing this adoption and this is where they were pushing it. Another is that, with CIM/HTTP and SNMP, the use of standard protocols for manageability was understood (and the prospect of better tools and better alignment with mainstream distributed software technologies was mostly welcomed by that community).

But in my mind, the use of SOAP made by WS-Management is mostly suited for management integration scenarios. In the manageability case, it’s mostly overhead. You don’t really need security beyond what SSL offers. You don’t really need routing through intermediaries. You don’t really need reliable messaging or the flavor of “transactionality” that the WS-* specifications provide. You don’t really need asynchronous messaging. You don’t really need fine-grained get/set operations (when dealing with one resource, operations at the level of the entire representation are often sufficient). Which is why I can’t help shaking my head when I see WS-Management used for manageability and not for management integration. Kind of like using an SUV that can carry eight people over mountains to carry one person to the hairdresser. Crazy, I know.

Leaving the SUV analogy aside, it’s not that WS-Management is perfectly designed for management integration either, not by a long shot. Which takes us to a third reason (and there are more) why WS-Management is not being used in management integration scenarios: it has technical deficiencies as do many of the other specifications recently created for management integration. That’s the topic of the next post.

[UPDATED 2009/6/26: EMC’s Chuck Hollis explains “management versus manageability” (he calls management “service orchestration” and manageability “element management”) in a much simpler way than I was able to. And he hints at upcoming management orchestration software from EMC (time will tell whether they missed out on BladeLogic and Opsware or made the right choice to let others acquire them). It will be interesting to see which of the 7 roads to IT automation middleware they take.]