One of the great opportunities that came from being a JavaOne exhibitor was the chance to meet a variety of people: everyone from business managers to day-to-day developers. Many had a story to tell about their dev-to-ops problems.
One visitor to our booth introduced me to two acronyms I hadn't heard before but they certainly reflect the philosophy that drives the development of our open source software projects. When guiding him through the demo of our Workbench CMDB tool, he pointed out that was the "WIRSB" aspect of our tool. Next when I showed how our execution framework and automation modules were driven by the CMDB data, bringing the environment in line with the model state he exclaimed that was the "WIRI".
WIRSB? WIRI? These were two acronyms that were new to me and I stopped and asked him what those meant.
WIRSB: What It Really Should Be
He explained how a tool that changed the state of an application - either its topology, configuration, or runtime state - should be based on an integrated model. This model should include information about the machines, software packages, essential configuration settings, as well as, a model for how the change will actually be done. It's the specification for how things should be.
WIRI: What It Really Is
With the specification described by WIRSB in hand, one can imagine that management tools should be able to compare the current reality to the idealized form described by the specification. Difference represent cases of non-compliance. Additionally, it should be the job of other management tools to transform the environment to match the specification.
The ultimate goal is a minimal difference between WIRSB and WIRI pictures at any point in time. If you look at emerging next generation solutions, they each seem to incorporate the paradigm of WIRSB vs WIRI to some extent. Solutions that don't adopt this paradigm will eventually become scaling bottle necks that really do slow down innovation.
Of course, anyone familiar with model-driven architecture will perceive this WIRSB/WIRI idea as the same concept. What I found encouraging is this thinking is penetrating into the operations world, too. Perhaps we are seeing an evolutionary step away from traditional administration tools that too often assume a two dimensional static state, or the
stone axes hurriedly made in house.
Datacenter WYSIWYG
Maybe the end state is a graphical tool that allows a service operations manager to define the WIRSB model. The management tools would then be driven by the model to transform, maintain and monitor the environment, always ensuring that WIRSB == WIRI.
Wednesday, May 21, 2008
One step closer to Datacenter WYSIWYG?
Subscribe to:
Post Comments (Atom)
2 comments:
What's the problem with the good old terms "desired state" and "observed state" that we need new acronyms?
But whatever you call them, experience has made me more skeptical of model-based management than I used to be. If your model is too abstract, you end up with systems that meet your "desired state" and yet don't perform as you expect. If they are too specific, you end up with a programmatic API that masquerades as a model view. There is plenty of value in modeling systems, but models are just one aspect of IT systems management.
Hi William,
What impressed me most about hearing of the WIRSB and WIRI acronyms wasn't so much that somebody had bothered to coin these terms. Rather, it was the fact that I was having a conversation with a regular dev-to-ops guy about model driven management in operations. He wasn't the only one either and I'm not including conversations with enterprise architect types.
This year marks the first where I can say there is growing awareness that traditional "script hodge podges" and "enterprise systems management platforms" aren't necessarily seen as the desired or even the right solutions.
What one's vision of "model-based management" looks like will surely vary, too. I can imagine someone picturing lots of UML in Rational, others seeing various XML documents, and finally some coding to a nascent model that organizes their software. I do believe that in order to find the right level of abstraction versus concreteness we need practical experience in the operations domain using next generation tools that are fundamentally data driven.
Incidentally, I agree with you that in general it is better to use simple english descriptions like "desired" vs "observed" state instead of inventing new buzzwords. That said, it made the conversation a bit more colorful :)
Post a Comment