This chapter is about virtualization usage. Developers and architects should not expect to implement all of these practices. Some will be implemented in third-party platforms and not by the users of the platform. Virtualization and clouds present opportunities for redesigning and building a new infrastructure for enterprise technology. These opportunities are also challenges that require expertise and foresight.

Whenever stepping into a new and large IT project like one involving shifting to or using a virtual platform for the first time, there is a decision: accept a third-party facility or build it yourself. Both alternatives have advantages and pitfalls. This is particularly true for virtualization projects. Virtualization is an active area of innovation. New products appear every year, and products are transformed and disappear as companies are acquired, merged, and close their doors. The ferment and churn make the “build or buy” decision more difficult. New and innovative products are tempting, but their future may be hard to predict. Building for yourself offers stability but has other issues.

An application or component developed in-house depends on the talent and resources of the enterprise to build, and even when the enterprise employs contractors for construction, the enterprise still must use in-house talent and resources for maintenance. Often, these projects support enterprise goals but are not central to core mission-critical objectives. Consequently, in-house applications or components are a continual drain on the core mission. Any application or component used by most businesses and organizations is likely to be available from a third party. This is especially true of technology such as virtualization, which has captured a great deal of interest. The enterprise should consider these products carefully before deciding to build in-house.

Architects and senior managers often forget that the cost of maintaining a service is frequently more expensive over the lifetime of the service than the cost of the initial build. Virtualized noncore basic applications, such as service desk and customer relations management, are good examples. These applications are likely to serve for many years. The cumulative cost of maintaining these applications is a good reason for avoiding developing these facilities independently and preserving enterprise development resources for areas that are exclusively in the enterprise’s core goals and competence.

There are several other factors to consider in deciding to build in-house. Many developers prefer to “roll their own,”¹ for the sheer pleasure of completing a challenging project. That is not a good reason for using enterprise development resources, but some circumstances may still warrant building in-house. One good reason is to avoid dependence on a third party for mission-critical technology. When the long-term viability of the third-party supplier is questionable or there is fear that a competitor may acquire the supplier, an IT team may be compelled to avoid the threat of an unsupported or hostile technology by building the technology themselves despite all cautions. In other cases, intellectual property or licensing issues may make using a third-party product undesirable. Applications built on virtual platforms can easily fall into the category of mission-critical technology. Enterprises may want to build virtual platforms and applications over which they retain complete control.

When a technology is mission critical but far from the enterprise core competency, an open source product supported by an industry consortium can be an excellent alternative. A strong consortium offers long-term stability and guards the technology from acquisition and control by a hostile competitor.

When a gap analysis reveals that a third-party technology only approximates the needs of the enterprise, there may be another good reason to build in-house. However, this situation requires scrutiny. Gaps can be in the eye of the beholder. Every enterprise thinks they are special, and most are, but that does not mean that every detail of their architecture will be different.

Third-party products are often more capable than they appear through the eyes of someone infatuated with the uniqueness of their situation. Second and third looks may inspire more ingenuity. Often, technologists discover that a third-party product can meet their special needs when they are prompted to revisit the problem.

Enterprises are often cautioned not to go beyond their core competency. This is good advice. Many organizations have regretted ignoring it, but there are exceptions. When an exception begins to appear desirable, it is time to double down on scrutiny. When a group decides to step outside its core competency, misjudgment is easy. But it can be the right decision. Virtualization technology differs from on-premises development in ways that many strategists, managers, and developers will find unfamiliar and beyond their core competency. They may venture into noncore areas without understanding the consequences.

This chapter examines some of the unique virtualization practices that a site should consider and use in evaluating decisions about whether to buy or build, which products to consider, and the architecture of the components the site decides to build for themselves.

Virtualized Integration

Virtualization separates the process from the hardware it runs on. Like security, traditional integration assumes that processes are tied to physical hardware.

The fundamental pattern for deploying virtual machines and reconfiguring virtual machines (VMs) causes issues for integration. When a physical server does not have the capacity to support a service, the service is often moved to another physical server with more resources available for the service. The second server could have a faster processor, have more cores, or simply be less heavily loaded than the first processor. A human operator working from a virtual infrastructure management interface may make the decision to move the service, or an automated process that detects overloaded physical devices may shift processing to less loaded devices. Moving processes is one of the basic activities of a clustered virtual system in which several physical machines support a collection of processes.

Figure 11-1 shows the response when the system determines that service A must be moved from physical server 1 to physical server 2. The first step is to quiesce² VM1 and take a snapshot, a file that contains everything in the memory and registers of the VM. The second virtual machine, VM2, is then started on the second physical server using the snapshot of VM1. Quiescing a VM stops all action, so the snapshot is an accurate picture without inconsistent images of moving parts. At this point, VM2 is an exact image of VM1, running service A. The final step is to direct consumers of the service to VM2 and possibly shut down VM1.³

This scenario works well when the environment is uniform, the service is stateless, and the service transactions are granular, but it begins to break down when the situation becomes more complex.

Environment

First, consider the environment. If physical server 1 and physical server 2 are the same architecture and hypervisor 1 and hypervisor 2 are from the same vendor, there is no problem. If the physical servers are different architectures or are running different OSs (say Linux and Windows), there may not be problem as long the hypervisor supports both physical server configurations. However, when hypervisor 1 and hypervisor 2 are different, problems are almost certain to appear. Although hypervisor vendors have been working toward compatibility, there are still challenges. Hypervisor vendors compete on features. Unique features are by nature incompatible. Coding to the lowest common denominator is a solution for hypervisor interoperability but is seldom desirable. Open Virtual Format (OVF) is helpful, but even OVF is not as simple as one would hope because of incompatible hypervisor features.

Stateless Services

Stateless services make scenarios like this much easier to manage. When a service is stateless, previous calls by a consumer to the service do not affect future calls.

For example, a request to the National Oceanic and Atmospheric Administration (NOAA) web service is stateless. A request for the current temperature in Blue Earth, Minnesota, will be unaffected by a previous request for the temperature in Bellingham, Washington. A stateless service is much easier for a provider to code and manage, although it can be more work for the consumer. A stateful service would allow the consumer to declare that Bellingham, Washington, will be the location for future requests and follow the declaration with requests for temperature, rainfall, and humidity on various dates without mentioning that the request is for Bellingham. When consumers shift their interest to Blue Earth, they could send a request to change their state from “location=Bellingham” to “location=Blue Earth” and repeat their queries exactly and get results for Blue Earth. A practice like this lends itself easily to writing scripts that return all the information for a location by specifying a single parameter. This becomes more significant as the data delivered or the actions performed by the service become more complex. It can become difficult to put together requests that contain all the information necessary to make the next stateless request in a sequence.

To a certain extent, stateful and stateless are a trade-off. In a stateful interchange, the server must retain information about the state of the sequence of transactions. In a stateless interchange, the client usually has to keep similar information. In the big picture, clients are in a better position to keep the state because a client has only its own state to track. A server with many clients has many states to track.

When a component or the network fails, a stateless interchange can recover easily. The client repeats its request. When a stateful interchange fails, recovery is more difficult. The server has to reconstruct the state prior to the last interchange, often by replaying the client’s messages. This involves tricky logic and a log of previous messages.

This issue is particularly important when VMs are stopped, started, and moved from hypervisor to hypervisor, as in Figure 11-1. When a stateless service is quiesced to clear its queues, snapshotted, and stopped, and then the snapshot is restarted, the service is ready for activity. Transactions interrupted in midflight (that is, sent by the client but not received by the server) need to be repeated by the client only when no reply is received.

Stateful servers have a somewhat different problem. Stateful servers must track their clients and their states. If the server clears its client state table when the service is quiesced, the client must start over on their transaction, which means they will have to unwind their stack to find their starting state. But clients ordinarily don’t need to keep a record of transactions, and it is quite likely that they will not be able to recover. Architects and developers usually can meet or circumvent stateful server challenges, but the service becomes more arduous to develop and maintain.⁴

Stateless processes are also important for scalability. A task divided into many stateless subtasks can be run in an arbitrary number of parallel processes to scale up the volume of data processed by the service. If subprocesses can be restarted without regard to state, the system is more resilient to errors and runs faster.

Service Granularity

Granular services perform poorly over high-latency networks, but a more granular service will transition more smoothly from one hypervisor to another. A highly granular service is a service that interacts in small steps. This is good and bad. It is good because an interruption in a highly granular service will cause only a small amount of backtracking. On the other hand, highly granular services are chatty; they send a message, get a message, send a message, and get a message with only a little data processing in between. A less granular service sends fewer messages to accomplish the same activity with less latency.

Typically, each message requires two traverses of the network: one request and one reply. A service that uses two messages for an activity will require four traverses. A service that uses six messages will require twelve traverses. See Figure 11-2. Since each traverse of the network takes roughly the same time, a service that uses two messages will expend only a third of the latency of a service that uses six messages. Unless a service is highly compute intensive, network latency is usually the lion’s share of service response time.

If the network is fast, as it usually is on a virtual network or a LAN, latency may be too small to matter. The difference between one-tenth and three-tenths of a millisecond latency may be negligible. However, a more granular service may be able to transfer from one hypervisor to another much more quickly than a less granular service, and that difference could be significant.

Many variables are involved. Message latency varies considerably depending on the environment. When the client is many routers and switches away from the server, latency is usually large. In an internal network, it’s not so large. Some services lend themselves well to high granularity; others are awkward without large transactions.

The biggest disadvantage of low granularity is lack of control. Compare a food-ordering service that lets you enter a dish and immediately sends back the price for the item and the total for the meal. As you add dishes, the total keeps current. It’s easy to decide when you have met your per diem for lunch. A less granular service might give you the total only after you have selected your entire meal and you have to start over if you go over. The first method may be more convenient, but the second method will take less time on a slow network. The best decision often requires both testing and educated guesses.

Another aspect of granularity is microservices. As opposed to granular services that act in many small steps, microservices are services that provide single-purpose generic functionality that can be combined into a larger service. This philosophy harks back to the early days of UNIX, which was based on many small functions that could be composed into complex applications. UNIX typically ran on a single processor, minimizing the latency between function calls. Often, reliable and efficient applications could be built quickly by stringing together stock functions in a script that controlled the logic.

Microservices can be used to quickly build reliable applications just like UNIX functions. The significant difference is the addition of the network into the system. Microservices are subject to the same latency issues as granular services, and decisions must be made on the same basis.

Addressing in Virtualized Environments

Addressing is another issue when dealing with the VM moving scenario in Figure 11-1. Unless special provision is made, VM2 will have a different Medium Access Control (MAC) address⁵ and a different IP address from VM1. Most hypervisors can start a VM with a static MAC and IP addresses that will remain the same when the VM is stopped and restarted, but the addresses are lost when the VM is deleted rather than stopped.

MAC addresses of physical devices are determined when a physical device is manufactured. Its MAC address is burned in a chip and cannot be changed. Virtual devices have MAC addresses assigned. This adds complexity to managing virtual devices.

In Chapter 9, tracking and managing process addresses was a major topic. Virtualization increases this challenge because virtual network addresses are more fluid than physical addresses. Until virtualization became popular, an IP address in a distributed system referred to a physical device connected to a network. Routers and switches direct packets to devices, not processes. Identifying processes on a server is dependent on the IP address of the server, which in turn is connected to the MAC address of the device.

In theory, running on a virtualized system is seamless: whether physical or virtualized hardware, everything works the same. Moving from one physical server to another physical server and hypervisor should not affect operation of the service. For an isolated VM, this principle generally holds, but when VMs communicate with other VMs on the same hypervisor or with VMs on a different hypervisor or a physical host, special provisions need to be made.

A traditional integration challenge is to make integrated application addressing and routing as flexible and reliable as possible, but behind the efforts to meet this challenge, there usually lurks an assumption that addresses will be in some sense constant and change slowly.

Virtualization invalidates many assumptions that traditional integration relies upon. An unsophisticated integration assumes that two communicating processes will be stationary; the process addresses can be hard-coded into application code, and the processes will always be able to exchange information. Integrations that are more sophisticated do not assume that addresses will never change, but they do assume that every address change will accompany a configuration change that will track changing addresses. When the address of a communicating process changes, the code of the processes will not need to change, but a configuration file or something similar will change.⁶

Network Address Translation

Network Address Translation (NAT) often helps in this situation. NAT is usually implemented on a router or a switch, and it is used to map one IP address space into another. NAT can be either “one-to-one” or “one-to-many.” One-to-one NAT maps an address in one space to a single address in another space. It used to be used as part of bridges between networks with incompatible addresses, such as IP and mainframe networks. This use is not so important now because IP addresses are almost universal. Another use of one-to-one NAT is to continue to use old addresses after a network has been physically reconfigured. The real addresses follow the physical configuration of the network. The old addresses are translated by NAT to the new addresses so the old addresses can continue to be used.

One-to-many NAT maps a single address to many addresses and is used for different purposes than one-to-one NAT. Most one-to-many NATs map a single publicly exposed IP to many private hosts. See Figure 11-3. A home wireless router is a typical example. The router has a public IP address assigned by the Internet service provider. Within the local wireless LAN, individual PCs, laptops, tablets, and phones are assigned private IP addresses that are not routable on the public network.

When a device within the private network directs a request to an address outside the network, the request goes to the NAT router, which appears to be an ordinary external gateway. The packets sent by the internal device have the device’s private IP address as the source and the public address of the target as the destination address. The NAT switches the internal source address to an external public address assigned from the NAT’s address pool and records the internal and external addresses in a binding table. Then the NAT sends the packet to the public network, where it finds its way to its destination. The destination device has no clue that the packet has passed through a NAT. If the destination device replies, it will place the source address of the incoming packet into the destination address of the outgoing packet and place its own address into the source address of the outgoing packet. When the packet arrives back at the NAT, the NAT will replace the destination address with the value in its binding table that matches the incoming destination address. At this point, the destination address is the private internal address of the originating device, which will receive the packet. Thus, the internal private address of the device never appears on the public network. One-to-many NAT used in this fashion is so common now that it is usually what is meant by NAT.

Under the typical one-to-many NAT practice, all traffic coming into the private network must be a reply to a previous outgoing request from inside the network. This is acceptable for typical users because typical computer users do not offer services for public access. In fact, NAT is often considered useful for security since it discourages intrusion from outside.⁷ Nevertheless, some applications require a public address. Any application that acts as a server to other devices on the public network or communicates with peers on the public network requires a public address. For home networks, games are the most common applications that require public addresses. Applications that require a public address in order to act as a server on the public network are more common in enterprises. Most NAT implementations have provisions to support a limited number of devices with public addresses.

NAT is a “shim” technology. A NAT device can be put in place between a public and private network without disturbing processing on either its input or output side. This makes NAT easy to deploy. There are a number of criticisms of NAT as an easy but incomplete or short-term solution. For example, one important use of NAT is to combat depletion of the IPv4 address space. IPv6 is a long-term solution with benefits beyond an expanded address space. However, critics point out that NAT has taken away the urgency to convert to IPv6, which is holding up improvement of the Internet. Other critics are concerned that NAT violates a basic principle of the Internet: every device has a unique identity characterized by its network address.

NAT and Virtual Systems

NAT can be an important tool for managing virtual systems. Using NAT, hypervisors can assign private addresses to VMs without regard for the requirements of the public network, which could be onerous, given the short lives and constant churn of VMs in many environments. These VMs are still able to communicate externally, although they cannot act as servers to the outside world.

VMs managed by a NAT implementation can move from physical server to physical server and be assigned new addresses. As long as the NAT implementation is aware of the change and keeps its binding tables updated, the outside world will not be aware of the shifts. When a VM with a public address changes private address, only the NAT binding table that binds the internal to the external address must be changed.

Scaling

Most successful services scale well. Scaling well means that the capacity of the service easily and smoothly changes to match the load placed on the service. Most services eventually need to scale up. Loads get larger as a successful enterprise expands and the service must scale up. Often, services also need to scale down, shrinking when the need for the service declines during off-hours or off-seasons. Scaling down is often a prudent use of resources. The strengths of virtual implementations are especially well-suited to scaling, and virtual implementations can be designed to scale exceptionally well.

There are two fundamental approaches to scaling: vertical and horizontal.

Vertical Scaling

Vertically scaling a service means replacing one computer with a computer that has more capacity or enhancing an existing computer using methods such as adding a faster or more efficient processor, increasing the speed and capacity of the data bus, and providing faster memory or storage. See Figure 11-4.

Vertical scaling is limited by the availability of more powerful hardware. Vertical scaling is typically easier than horizontal scaling because software usually changes little, or not at all, when higher-capacity hardware is put in place. When a site that already has top-of-line high-capacity hardware needs to scale up, a crisis occurs. Unless higher-capacity hardware can be found, the site has few alternatives. They can set up another identical system and move some of their clients to the new system. This solution works, but when the service is based on sharing between clients, this may be rather awkward to implement satisfactorily. Another possibility is to redesign the service to scale horizontally. This is often the best solution, but it is seldom easy.

Horizontal Scaling

Horizontal scaling increases the capacity of a service by adding computers, (often called nodes), each performing the same task. The common alternative to horizontal scaling is vertical scaling.

Converting a service from vertical to horizontal scaling is difficult because horizontal scaling usually requires a more complex and carefully planned design than a vertically scalable service. Fundamentally, a monolithic vertically scalable application may be complex, but it simply executes a request from beginning to end. A horizontally scalable application decomposes a request into segments that can be executed in parallel. These tasks are then distributed among available processing nodes. At some point, or several points, individual tasks may have to merge to exchange data or to deliver the result to the client. In addition, there probably needs to be code for picking up execution when a processing node fails since economical horizontal scaling usually assumes that hardware will use redundancy to achieve reliability. All of this is support for the logic of the task itself, which must be implemented in the decomposed segments.

Developing horizontally scalable services generally requires more coordination between developers and development teams, more experienced developers, and a more sophisticated development group. Consequently, developing horizontally scalable applications is usually substantially more expensive than vertically scalable applications.

There are several critically important advantages to horizontal scalability. The first is that horizontal scaling does not have the kind of limit that vertical scaling faces. In theory, a horizontally scalable service just keeps adding processing nodes to match the load on the service. There are limits to horizontal scalability that come from the necessity of maintaining coordination of the processing nodes, but those are far higher than vertical scaling limits.

Another advantage to horizontal scaling is that a production service can scale up or down easily. A vertically scaling service cannot scale down unless spare resources can be diverted to another service when they are not needed. Scaling up a vertically scaling service involves a hardware change that often disrupts production.

Horizontal scaling is suited well to virtual systems. Adding VMs to a virtual system to scale up a service is a simple process. When the virtual system is on a cloud, scaling up in this way may even be transparent to the enterprise owning the service. When properly designed, the service can be robust enough to failover transparently when a disaster strikes. The issues discussed earlier relating to Figure 11-1 are usually dealt with in the design of the service and present fewer problems than appear in vertically scalable designs. Vertical scaling can be a problem for virtually implemented services; the capacity of VMs supported by a hypervisor is often limited. Most virtual systems focus on many small VMs rather than a few large virtual devices.

Horizontally scaling services can often easily take advantage of automatic scaling, often called elastic scaling, available on many public clouds. When this feature is available, new VMs are automatically launched when threshold conditions are met and shut down when use declines.

Failover and Performance

Failover and performance may seem like an odd juxtaposition. Failover is the ability for a service to withstand a component or equipment failure or other disaster without interrupting the service by shifting to other equipment or facilities or using redundant resources. Performance is quite different. A service that performs according to specifications responds with appropriate speed to all queries. Failover and performance may seem disconnected, but when designing virtual applications, they are in opposition. Without careful design, a service that fails over well may not perform well.

The Open Virtual Format standard has useful terminology. OVF refers to affinity and availability. Affinity relates to performance, and availability ties to reliability and failover. They are two principles used for choosing where to locate virtual machines. When two VMs are located with a preference for affinity, they are located as close as possible. Close can mean various things in OVF terms, but the fundamental idea is that close VMs communicate quickly and less close VMs have greater communication latency. Availability is an opposing locating principle. VMs that are located for availability are as distant as possible. Like affinity, availability can have various meanings, but VMs that are more distant will be less affected by failures in the proximity of the other VM. In general, VMs with high availability will not have high affinity. See Figure 11-5.

Some examples will help understanding. Suppose a service must perform well. The application design might call for horizontally scaling processes to run on up to eight VMs on four physical servers available. If those VMs were designated to run with affinity, they might be located on a single rack in the datacenter with inter-server communication through a single rack-top switch connecting the devices on the rack. This configuration supports fast communication. However, if a fire were to break out close to the rack and the sprinkler system turned on, every server on the rack could go down simultaneously and recovery could take hours.

On the other hand, if the service were deployed with availability, each VM might be deployed in widely separated, even globally separated, datacenters. A failure, such as a fire, in one datacenter would be a minor blip as processing transferred to a remote and unaffected VM. However, the cost of this level of reliability would be performance because communication between the services’ VMs would almost certainly involve several switches and routers, resulting in much greater latency than the VMs all located on the same rack.

This presents a basic trade-off. A highly reliable system requires more resources to perform well. A highly performant system requires additional resources to be reliable.

The trade-off is often surmountable, but it requires analysis of the available resources and the nature of the consumers of the service. For example, if consumers are divided geographically, between Australia and North America, for example, one group of servers could support Australia, and another could support North America. Each of the groups can be organized for affinity—close together for optimum performance. If a disaster occurs in Australia, the Australian consumers could failover to North America. Performance would drop for the Australian customers because of greater network latency, but service would not be interrupted. In many cases, this will be an acceptable compromise. Often, the segmentation of the consumer base will not be so clear-cut; in North America, East Coast and West Coast segments are common, but it is difficult to decide which segment is right for consumers in Denver.

Virtualization makes these issues easier to cope with because shuffling VMs is easier than moving physical servers, which typically involves re-cabling and manual reconfiguration. Starting a VM on a different hypervisor is much simpler and can probably be accomplished from a single console.

Open Virtual Format

Open Virtual Format (OVF) is a standard that is supported by major hypervisors. It is a packaging format standard for virtual systems. An OVF package contains the images that a hypervisor will deploy and a descriptor that describes how the images fit together. OVF packages can be large. The standard does not limit the number of virtual machines that may be part of the package. The descriptor is hierarchical, and the standard places no limits on the complexity of the hierarchy. The virtualization platform determines those limits.

Packaging Format

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 defines 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 to create an unauthorized version of the package that is not exactly what the author intended.

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

The OVF package consists of several files. See Figure 11-6. The only required file is the descriptor, which is written in XML and contains the description of the system that the virtualization platform uses for deployment. The manifest and certificate are optional, but when present, they provide assurance that the contents of the package have not been tampered with and are from a certified source. The image files are images of the objects the virtualization platform will install. The formats of image files are not specified beyond requiring that they follow a publicly available format. The packager and the user must determine that the virtualization platform will accept the format. Resource files are additional resources to be installed in the package. These are often installable images of applications. The files in an OVF package can be compiled into a single file using a Portable Operating System Interface (POSIX) tape archive (tar) format or can be left as individual files.

Interoperability

OVF is closely tied to the virtualization platforms on which OVF packages are deployed. The Distributed Management Task Force (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, all OVF packages would be interoperable; that is, a single OVF package would run equally well on many different platforms, but because platform features vary widely, the capabilities of the package would necessarily be limited to the lowest common denominator among virtualization platforms. In fact, interoperable OVF packages can be written, but they seldom are because most OVF users want to exploit the unique features of the platform they are using.

An OVF Use Case

Here is an example of an OVF package that is not interoperable between virtualization platforms but is still valuable.

Consider a simple physical system; let’s say it’s a LAMP stack (Linux, Apache, MySQL, and Perl, Python, or PHP) that requires at least two servers, one for an HTTP server and the other for a database. Suppose QA uses this LAMP stack system repeatedly. If QA wants 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 QA needs a new instance, QA hands the OVF package to their virtualization platform, and it deploys the system as specified, exactly the same, every time. This saves QA team time and equipment because they perform tests that need a basic LAMP stack every few weeks. When the test is over, they remove the LAMP stack implementation and use the physical resources for other tests. When QA needs the LAMP stack implementation again, they pass the OVF package to the virtualization platform to deploy it, and they have a fresh installation in minutes with no error-prone manual configuration.

Of course, a developer could do all this with a script, but in most similar environments, formats and tools have supplanted scripts. Linux application deployments are an example. Decades ago, developers wrote shell scripts for deploying complex applications, but now most applications use standard tools and formats such as installation tools and .deb files on Debian distributions and .rpm files and tools on other Linux distributions. .deb files correspond closely to OVF packages. Scripts still play a role, but the overall control of the installation comes from the installation tool. On Windows, .bat files have been replaced with tools like InstallShield. The results are increased reliability and ease of development and maintenance.

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.

An International Standard

OVF has significant visibility as a national and international standard. OVF has been through a rigorous review by a national standards body (ANSI) and an international standards body (ISO/IEC). The next revision of Twitter may not depend on OVF, but many services are more reliable and perform better because they have 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 why OVF exists.

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. OVF is a stable standard, accepted in the international standards community and not just the body that published it (DMTF), and it makes products easier to write and maintain.⁹

Conclusion

Virtualized systems are fluid. They can change quickly in response to changing workloads and physical conditions. But fluidity also generates challenges. Processes are no longer barnacles attached to a physical server; they are movable but only with planning and effort. In a virtual environment, processes are more like fish that flit freely from node to node in the form of images that can be stopped on one device and immediately reappear on another.

Traditional networking relies on addresses that are assigned to physical devices with an assumption that address changes will be a rare event. But with virtual devices appearing and disappearing, addressing becomes a challenge.

In a virtual environment, the natural means of scaling up is to increase the number of virtual machines processing the workload. In a nonvirtual environment, the scaling up is often via increasing the capacity of the physical machine, which means many applications must be redesigned to scale horizontally rather than vertically.

The opportunities for failover and performance optimization are different in a virtual environment. This requires rethinking the physical distribution of the environment.

Finally, taking full advantage of virtualization requires a means of conveniently packaging and deploying complex systems so they can easily be replicated and managed.

The next stage in the progress to cloud service management is use of clouds, which are largely impossible without virtual systems but add new dimensions to virtualization.

_______________

¹This is a developer’s phrase for coding for yourself rather than using a standard library, an off-the-shelf component, and so on.

²Quiesce means to become still or cease activity.

³Some virtualization products streamline the movement from server to server using proprietary technology to take a snapshot of memory and quiescing the original VM when the snapshot is stable. The rest of the process is the same, but it is automated so there is no human latency.

⁴The scenario described here is not the migration of processes from one physical device or hypervisor to another. The memory snapshots used for migration hold state, and the state is reproduced in the target VM. For state recovery to become an issue during migration, something would have to happen to interrupt the migration and cause the snapshot to be damaged or lost. This is not impossible but unlikely.

⁵Medium Access Control (MAC) addresses are globally unique strings that are assigned when hardware is manufactured. The global uniqueness of MAC addresses is a fundamental assumption of computer networking. When VMs are not exposed outside the virtualized space, MAC addresses can be assigned and changed by the hypervisor, which follows its own rules. When a VM can communicate with the outside, MAC addresses must be assigned more carefully.

⁶One way of accomplishing this is with a reverse proxy. A reverse proxy acts as a front end with an address that does not change. The proxy keeps track of the real location of services and forwards the message to the real target. When the target replies, it sends the message to the reverse proxy, which then passes the message on to the originator. This is similar to Network Address Translation described in the next section.

⁷Be cautious. The security benefits of NAT are a side effect, not part of its design. It is irrelevant to most common exploits. No one should ever assume that because NAT is in place, their network is safe.

⁸See http://dmtf.org/standards/ovf for further information on the OVF standard.

⁹OVF is supported by most major hypervisor manufacturers, including IBM, VMware, Microsoft, Oracle, and Citrix.