Posted on

Open Virtual Format

Lately, a share of my time has been going into helping with the next release of OVF, the DMTF’s (Distributed Management Task Force) standard for packaging virtual appliances for deployment. The standard is vendor neutral, meaning that it is not “owned” by a single hypervisor provider. Instead, most hypervisor providers have participated in defining the standard. OVF was adopted as a US ANSI standard and then an ISO/IEC international standard several years ago. Version 2.0 and all other published versions are available for free on the DMTF OVF page. ISO/IEC charges for copies of their version, but the content is the same as the corresponding DMTF version.

What is OVF?

Although OVF comes up frequently in discussions, I am surprised at how few people know what it does and why it is important. Usually people think about virtual machines as an image of an installed physical computer that can be reproduced virtually by a hypervisor (more properly, a virtualization platform). That is correct as far as it goes, but the really interesting applications of virtualization involve many virtual machines installed with elaborate software that is all configured and wired up to work together. For anyone who has had the mixed pleasure of spending weeks installing and configuring a complex physical system, packaging up a complex configuration and reproducing it at will is close to a miracle.

Installing Complex Configurations

OVF shows its worth when installing complex configurations. The term “virtual appliance” refers to a simple or complex system packaged up and installable as a single appliance. Virtual appliances are what OVF is all about. By far the most notable application of OVF is packaging virtual appliances for cloud deployment. An OVF package consists of individual virtual machine images that can be in a range of formats, a security manifest for signing packages as authentic, and, most important, the OVF descriptor that describes how the images are intended to fit together. The descriptor is designed to be flexible and extensible, which means very complex systems can be described in as much, or as little, detail as needed to deploy as intended. Using OVF-packaged virtual appliances, deploying complex appliances on a cloud can be fast and dependable. No more errors from mis-typed URLs and cabling goofs!

The Challenges of Complication and Variation

One challenge faced by any packaging language is the staggering diversity of the systems that benefit from packaging as virtual appliances. How do you produce a machine readable description of anything so varied and complex?

Secret Weapon: Common Information Model

OVF uses the DMTF Common Information Model (CIM) for detailed descriptions. CIM is occasionally frustrating for its complexity, but it is a finely articulated and living model of IT management information developed by major IT vendors and published as an open standard by the DMTF. Its complexity reflects the complexity of the domain. It has been evolving for over ten years and continues to be added to. The latest version of CIM was released in January 2013.

OVF taps in to CIM for its rich model that is accessible as a public standard. Consequently, OVF descriptors can be interpreted by anyone, no matter what scheme they use for their internal representation of systems. Keep in mind that OVF does not impose CIM on anything but the terminology used in an OVF descriptor. By tapping into CIM, OVF takes advantage of CIM’s ready availability and its terminology for almost everything you can imagine in a data center. At the same time, the consumer of the OVF standard is not burdened with terminology that they may never use. The coupling between CIM and OVF is sufficiently loose that, for example, terms in CIM 3.0 can be used in an OVF 1.0 compliant package, even though OVF 1.0 was released years before CIM 3.0. The end result is a packaging description that is capable of great detail and reach, but remains comprehensible and usable.

The OVF standard is not the easiest standard to understand, but it has tremendous practical value and its value has been increasing with each release. As an international standard, it has wide exposure and growing acceptance. I expect that someday in the not-too-distant future, it will be recognized as a bedrock foundation for good cloud practice.

I’ve written more about OVF in my book Cloud Standards. I urge you to go there for more description of OVF and how it works.

Posted on

New Book, New Life

I have been neglecting this site, but I hope to change that.

I have begun a new book, Cloud Service Management, and a new stage in life. For the first time in close to thirty years, I am working for myself. Cloud Service Management will be published by CA Press and Apress, like my first book, Cloud Standards, but I no longer work for CA Technologies. CA reorganized this spring and my job evaporated.
I can’t say that I am upset with leaving CA. I worked there for a long time and had many great experiences, but eventually, everything loses its sparkle. I toyed with the idea of retirement for the last several years, but without this reorg, I probably would never get around to it. My only regrets are for the colleagues who have practically been my family for years. If something interesting turns up, I will no doubt take it, but I intend to be choosy.
I look forward to more books. Cloud Standards was a surprisingly difficult challenge, and an equally pleasant surprise. I hope Cloud Service Management will be a similar experience.
I am keeping my hand in. The Distributed Management Task Force (DMTF) has offered me an emeritus position and I am happy to take it. The honorary position will give me an opportunity to continue to contribute to DMTF standards and keep in contact with the IT management standards world. That is exciting stuff for me.

Posted on

Service in Business, Computing, and the Cloud

I am a longtime enthusiast of the IT Infrastructure Library (ITIL). I was first introduced to ITIL in the mid-nineties by a support architect from the Netherlands. Their practices seemed overly complex, but I was pleased to see that the ITIL approach to service desk management was similar to the methodology built into the Network Management Forum trouble ticketing standard that I had worked on a few years before.

Business Services

ITIL places a heavy emphasis on managing IT as a system of services. Service is an important concept in both business and computing architecture.  In business, a service comes into being when a buyer purchases an action, often contrasted with a transaction in which the buyer purchases goods, i.e. things. Hence the phrase “goods and services.”  An important part of the notion of “service” in business is that services always have a buyer and a seller. There are always two participants in the transaction. I can wash my clothes myself, or I can purchase laundry service from a laundry. When I wash them myself, it is just me grabbing a box of detergent. When I subscribe to a laundry service, it is me and the laundry.

In an IT department, I can acquire help desk software, hire support analysts and managers, and run my own help desk, or I can subscribe to a help desk service. This is exactly like choosing to subscribe to a laundry service.   In both cases, I have decided to have something done for me instead of doing it myself. This is a business decision, not a technical decision, although deciding between  building a help desk or subscribing to a service involves a choice between technologies.

Software Services

I can do the same thing in software. Suppose I want to perform arithmetic calculations in a program. I could write a function to do it. Or I might find a library with a function to link into my program. In both cases, my program would be doing the calculation on my machine. Alternatively I could use a different software architecture and call the Google calculator web service. If I chose the service, my program would become a consumer of a Google cloud service and the calculation would be done in one of Google’s warehouse scale computers. I could choose to call Google’s REST API or SOAP API, but no matter which I chose, my program would still be a consumer of Google’s service.

Cloud Services

Cloud computing is based on a great divide between consumers and providers, both in a business and a programmatic sense. A great divide between customers and vendors can lead to conflicts and severed relations, but the divide between consumers and providers  is division by choice for more efficient  allocation of resources and may well result in improved relations.

Posted on

Managerial and Functional Interfaces To Services

In writing Cloud Standards, I  spent more time than I expected working on a good description of the distinction between functional and managerial interfaces to services. I referred to management and functional interfaces recently in a blog on the CA Cloud Storm Chasers site. I’ll say a little more here.

Functional versus managerial are clearly separate in my head, but stating the difference succinctly is to not so easy.  I’ve got it down to “a managerial interface manages the delivery of a service to the consumer and a functional interface delivers the service functionality.” I say much more about it in the book.

Distinguishing functional from managerial is important because  standardization of managerial interfaces plays differently than standardization of functional interfaces.

Word processing functional interface

There is no limiting or predicting functional interfaces as they change and respond to technology and consumer taste. For at least a decade, word processors sported a narrow strip menu on top of a big more-or-less WYSIWYG (What You See Is What You Get)  entry pane. There were minor variations between the contenders, but that was what a word processor looked like.

If it isn’t broke, don’t fix it, right?

So what did the leading word processor development team do to their 2007 version? They switched to a ribbon menu at the top. Not a big change, but enough to generate confusion and grumbling from experienced users. New functionality? Not much. I certainly uttered a few choice words about gratuitous change when the CA IT department installed a copy on my work laptop. But that’s the way with functional interfaces. Somebody always has a sleeker, jazzier idea.

And that is as it should be.  A few years later, I am used to the ribbon and have grown to prefer it. When I switch to an open source word processor on Linux, I miss that once-hated ribbon. Redmond scores! I hope the ribbon is not tied up tightly in patents because I want the open source word processors to adopt it. Then I can install a ribbon menu word processor on my Linux boxes.

Managerial interfaces

Management interfaces are different. Often they are APIs. They tend to change only when technology changes and they are often  held in line by standards organizations that intentionally tamp down variations that do not confer clear benefits. This prevents unnecessary breakage of other applications that use the managerial interfaces.  We are less likely to see the equivalent of an apparently quixotic change to ribbon menus on the managerial side.

Distinguishing functional from managerial encourages both innovative functionality and stable integration. It makes life easier for everyone.