How is OVF different?

The number of standards, open source implementations, and de factor standards for cloud management is growing. CIMI, OCCI, TOSCA, Open Stack, Open Cloud, Contrail. OVF (Open Virtual Format) is a slightly older standard that plays a unique role, but architects and engineers often misunderstand its role.

Packaging Format

What is OVF and how is it useful? OVF is a virtual system packaging standard. It’s easy to get confused on exactly what that means. A packaging standard is not a management standard and it is not a software stack. The OVF standard tells you how to put together a set of files that clearly and unambiguously define a virtual system. An OVF package usually has system images of the virtual machines that will make up the virtual machines in the package. A package also contains a descriptor that describes virtual configurations that will support the images in the packages and how the entire system should be networked and distributed for reliability and performance. Finally, there are security manifests that make it hard for the bad guys to create an unauthorized version of the package that is not exactly what the original author intended.

A packaging format is not designed to manage the systems it deploys. To expect it to do that would be like trying to manage applications deployed on a Windows platform from the Control Panel “Uninstall A Program” page. There are other interfaces for managing applications. The OVF standard also does not specify the software that does the installation. Instead it, is designed as a format to be used by many virtualization platforms.

Interoperability

OVF is closely tied to the virtualization platforms on which OVF packages are deployed. The DMTF OVF working group has members from most significant hypervisor vendors and many significant users of virtualized environments. Consequently, an OVF package can be written for almost any virtualization platform following the same OVF standard. The standard is not limited to the common features shared between the platform vendors. If that were the goal, OVF packages would be inter-operable, that is a single OVF package would run equally well on many different platforms, but because platform features vary widely, the package would of necessity be limited to the lowest common denominator. In fact, OVF packages can be written that are interoperable, but they seldom are because most OVF users want to exploit the unique features of the platform they are using.

An OVF Use Case

Is an OVF package that is not interoperable among platforms useful? Of course it is! Let’s look at a use case.

Here’s an easy one. I have a simple physical system, let’s say a LAMP stack (Linux, Apache, MySQL, and Perl, Python, or PhP) that requires at least two servers (one for an http server, the other for a database).  I this configuration use over and over again in QA. If I want to go virtual, an OVF package for this LAMP stack implementation is simple. After the package is written, instead of redeploying the system piece by piece each time I need a new instance, I hand the OVF package to my virtualization platform and it deploys the system as specified, exactly the same, every time. This saves me time and equipment as I perform tests every few weeks that need a basic LAMP stack. When the test is over, I remove the LAMP stack implementation and use the physical resources for other tests. Then I deploy my LAMP stack package again the next time I need it.

Of course, I could do all this with a script, but in most similar environments, formats and tools have supplanted scripts. Look at Linux application deployments. I remember writing shell scripts for deploying complex applications, but now most applications use standard tools and formats like installation tools and .deb files on Debian. .deb files correspond fairly closely to OVF packages. On Windows, .bat files have been replaced with tools like InstallShield or Windows Installer. Why? Because scripts are tricky to write and hard to understand and extend.

OVF provides similar advantages. With an OVF package, authors don’t have to untangle idiosyncratic logic to understand and extend packages. They don’t have to invent new spokes for a script’s wheel and they can exchange packages with other authors written in a common language.

Interoperability between virtualization platforms would be nice, but I still get great benefits without it.

An International Standard

It is also important to realize that OVF has significant visibility as an international and international standard. OVF has been through a rigorous review by national standards body (ANSI) and an international standards body (ISO/IEC). You may ask if that is significant. Who cares? After all, don’t hot products depend on cool designs and code, not stuffy standards? Maybe. The next hot product may not depend on OVF, but I’ll guarantee that if not today, sometime in the near future, you will interact with some service that is more reliable and performs better because it has an OVF package or two in the background. Hot prototypes may not depend on OVF, but solid production services depend on reliable and consistent components, which is exactly what OVF is for.

Every builder of IT services that run on a cloud or in a virtual environment should know what OVF can do for them and consider using it. They should look at OVF because it is a stable standard, accepted in the international standards community, not just the body that published it (DMTF), and, most of all, because it will make their products better and easier to write and maintain.

BYOD- The Agreement

BYOD, Bring Your Own Device, is important, but it has its growing pains.

BYOD is, in a sense, a symmetric reflection of enterprise cloud computing. In cloud computing, the enterprise delegates the provision and maintenance of backend infrastructure to a cloud provider. In BYOD, the enterprise delegates the provision and maintenance of frontend infrastructure to its own employees. In both cloud and BYOD, the enterprise and its IT team loses some control.

BYOD has issues similar to the basic cloud computing and out-sourcing problem: how does an enterprise protect itself when it grants a third party substantial control of its business? For cloud, the third party is the cloud provider, for out-sourcing, it is the out-sourcer. For BYOD, it is the enterprise’s own employees.

Nevertheless, enterprises have responded to BYOD and cloud differently. When an enterprise decides to embark on a cloud implementation, it is both a technical and a business decision. On the technical side, engineers ask questions about supported architectures and interfaces, adequate capacities, availability, and the like. On the business side, managers examine billing rates and contracts, service level agreements, security issues and governance. Audits are performed, and future audits planned. Only after these rounds of due diligence are cloud contracts signed. Sometimes the commitments are made more casually, but best practice has become to treat cloud implementations with businesslike due diligence.

On the BYOD side, similar due diligence should occur, but the form of that due diligence has yet to shake out completely. A casual attitude is common. BYOD is a win on the balance sheet and cash flow statement and a spike in employee satisfaction. This enthusiasm for BYOD has meant that BYOD policy agreements, the equivalent of cloud contracts and service level agreements, are not as common as might be expected.

This is understandable. The issues are complex. BYOD becomes safer for the enterprise as the stringency of the BYOD policy increases. However, a stringent policy is not so attractive to employees. It can force them to purchase from a short list of acceptable devices with an equally short list of acceptable apps, accept arbitrary scans of their device, and even agree to arbitrary total reset of the device by the enterprise. With this kind of control, employees may not be so enthusiastic about BYOD. At the same time, privacy issues may arise and there is some speculation that some current hacking laws might prevent employers from intruding on employee devices.

There are also complex support issues. Must the employer replace or repair the employee’s device when the device is damaged on the employer’s premises while performing work for the employer? This situation is very similar to a cloud outage in which the consumer and provider contend over whether the cause was the consumer’s virtual load balancer or the provider’s infrastructure that caused the outage. In the cloud case, best practice is to have contracts and service level agreements that lay down the rules for resolving the conflict. BYOD needs the same. The challenge is to formulate agreements that benefit both the enterprise and the employee.

In my current book and in this blog, I talk about some of the complexity of BYOD, how it complicates and challenges IT management. BYOD is a challenge, but it does not have to be the tsunami.

Some key questions are

  • How much control does the enterprise retain over its data and processes?
  • What rights does the enterprise have to deal with breaches in integrity?
  • What responsibility does the enterprise have for the physical device owned by the employee?

There are reasonable answers for all these questions although they will vary from enterprise to enterprise. When the answers take the form of signed agreements between the enterprise and the employees, IT can begin to support BYOD realistically. Security can be checked and maintained, incidents can be dealt with, and break/fix decisions are not yelling matches or worse.

With reasonable agreements in place, BYOD support can get real. There is more to say about real, efficient BYOD support that I hope to discuss in the future.

BYOD and TCO

One reason enterprises are readily accepting BYOD is they see an opportunity to reduce the TCO (Total Cost of Ownership) of computing equipment. The thinking goes that if employees pay for their laptops, tablets, and smartphones themselves instead of using company equipment, the company saves a bundle in TCO. Of course that is not as straight forward as it may appear because the initial purchase cost of a piece of equipment is often only a small fraction of the TCO.

Nevertheless, BYOD does eliminate a large item from capital expenditures. Cloud also promises to reduce capital expenditure by shifting capital equipment purchases to operational cloud service fees. That is a true benefit, but it is still a paper transaction. Unlike cloud, BYOD capital savings is real money that will never have to be spent, not a shift from a capital column to an operational column. Operational expenses are generally easier to manage than capital expenses, but no expense is easiest of all.

And it gets better. If an employee dumps a can of coke on his company laptop at lunch, the company usually ends up paying for a replacement, but when the laptop belongs to the employee, the employee buys a replacement. The service desk and the IT department will not burn hours trying to revive the dead soldier and the IT department probably will not be responsible for reimaging a hard drive and restoring backups.

Put another way, traditional break/fix service is not the same in a BYOD environment, and service desks may someday completely drop that aspect of support. But hold it! A fellow employee in the office once inadvertently bumped over cup of coffee on my laptop. As I remember it, my productivity zeroed out for a few hours while IT services delivered a loaner to me and acquisitions expedited a replacement. If I had owned it and had to replace it myself, I would have been out of commission for at least a day while I shopped around for a good buy on a new laptop and worked on restoring the system as best I could. Not only that, I would have been a pretty grumpy employee, who might even think the company owed me for placing me in a laptop-destroying environment.

This leads to a question: what kind of enterprise support is needed in the BYOD age? What are the legitimate limits? A major clue comes from the way these devices are supported outside the enterprise now. We all know that iPhone and Android apps are supported differently than traditional software. Do service desks need to take a lesson from the app stores? I think so. I’ll talk about this more in a future post.

BYOD Service Desk?

This week, thanks to my friend and technical reviewer, Efraim Moscovitch, I listened in on a webinar on service desk software designed to support Bring Your Own Device (BYOD) devices such as tablets, smartphones, and personal laptops. I was struck by how little has changed in the service desk realm in the last twenty years. When the ITIL books came out in the 90s, the big things in service desk design were support processes and integration with infrastructure management tools. In those days, we scrambled to support ITIL incident and problem management processes and to integrate with network management tools like Unicenter and Sun Net Manager. A blink of an eye later, we worried about moving the service desk interface closer to the analysts and users; in other words, browser based clients. Now, to support BYOD, developers are scrambling to support mobile device management tools, incident and problem management processes tailored to BYOD, and service desk apps for mobile devices. The wheel keeps turning.

This state of design and development both disappoints and encourages. It is disappointing because you would think that someone would come up with something really innovative in service desks instead of churning the same old ideas. It is about time.

But it is also encouraging. The innovations of the 90s successfully tamed the wild distributed system environment where mission critical servers sat under the receptionist’s desk and networks were cabled after hours by accountants and sales managers. The chaotic BYOD environment has similarities to the distributed system wilderness; tailoring traditional service desk tools to BYOD promises to be equally successful.

In working on my coming book on service management in the cloud era, I have been thinking a lot about service desk support for BYOD and I have developed some ideas about it. Service desk architects and managers may find them valuable. I hope to write about some of them here.