6 Reasons to Deploy Software as a Virtual Appliance

Managing IT infrastructure is a more complex proposition than it used to be. The age of on-premises servers and monolithic applications is giving way to a new hybrid reality: Legacy, on-premises infrastructure is mixing with a cacophony of cloud-based, virtual, and modular database and app technologies. It's changing the way businesses host, provision, and deploy software.

One of the catalysts in this paradigm shift is the rise of virtual appliances (VA). Built on cloud-based virtual machines (VMs), a VA is a preconfigured tool to set up and run virtual apps without worrying about any manual installation, provisioning, or deployment. Kit Colbert, CTO of VMware's Cloud Platform Business Unit, said to think about VAs like any other appliance: You don't need to know how your refrigerator works, it just works.

Colbert has spent 14 years at VMware. He has worked across much of the enterprise software company's portfolio—from the VMkernel operating system (OS) and vSphere server virtualization to the vRealize IT operations manager and VMware AirWatch platform for mobile device management (MDM)), among other roles. PCMag spoke to Colbert about what VAs are and why they're useful in practical business scenarios. We discussed how you can leverage VAs, along with emerging developer-side technologies such as containers and microservices, as part of a next-generation software stack and IT infrastructure.

What Are VAs?

VAs are growing more common in data centers and virtual servers, running as part of Infrastructure-as-a-Service (IaaS) clouds. To understand what VAs are and how they're important in cloud computing environments, Colbert said the key word is "appliance."

"Think about an appliance in your house: ovens, microwaves, refrigerators. You plug them in and they work," said Colbert. "The inner workings are complex—and now with the Internet of Things (IoT) many of them have Wi-Fi. But how many of us actually know how a refrigerator or an oven works? We don't have to. I turn the knobs to control a very complex device with a very simple interaction. An appliance contains that complexity to make it easier for a user to get value. A virtual appliance does the same thing inside a VM in a data center."

As Colbert explained, a VA essentially provides a software abstraction to take a complex virtual system and focus it into a specific, tightly controlled configuration for both the independent software vendor (ISV) selling the product and a business IT department buying and deploying that software. For ISVs, VAs reduce the number of configuration and deployment options. The more options and settings and OSes you support, the more difficult it is to ensure that software will work properly in different environments. On the business side, VAs let IT department spend less of their time setting up the app, and configuring the network and compliance settings, etc. Colbert said it's about simplicity and time-to-value.

"Traditionally, when you install software, there's a litany of things you need to do to get that application stood up. The goal with a virtual appliance is to preconfigure everything and just start using it," said Colbert. "Look at an operating system like iOS. It's one set of software that only works for this set of Apple devices. Compare that to Android where you have a highly configurable OS running on hundreds of thousands of different devices. It's a lot more work for manufacturers to customize on different devices whereas, with the iPhone, it's just built once."

VAs vs. VMs

VAs and VMs are often mixed up but simply put: VMs are the packaging and deployment mechanism for a VA. Colbert explained that a VM itself is more or less a blank canvas with a broad range of uses. A VA built atop a VM is a way to tailor and customize that VM for use in a very specific way. Going back to the home appliance metaphor, it packages up all of the complexity of the VM and gives the user some simple knobs, so to speak.

"A virtual appliance is a VM that's deployed in a very specific way that makes it really simple to deploy and limits the options to configure a million different things," said Colbert. "With a general purpose VM, you can install the server software and OS you want, and that's useful in some cases. What we're talking about here is a customization and optimization on that more general VM pattern."

6 Tips for Deploying VAs

VMware is far from the only enterprise software provider working with VAs but the company says it has deeper expertise than most. VMware has spent years developing VMware vApp, which runs on the standardized Open Virtualization Format (OVF). The VMware vApp platform packages VMs together into VAs that work across different OSes and cloud-computing architectures. Colbert offered five recommendations that businesses should keep in mind when considering, setting up, and deploying VAs.

1. Know When to Use a VA, Not a VM

Once you understand the difference between a VM and a VA, it's important to know when it's more beneficial to use one over the other. When deciding whether to leave a VM as-is or to deploy it along with a preconfigured VA, Colbert said to think about the business process you're trying to solve.

"If you find you have this pattern where one application or process is commonly used by a lot of different employees and other folks in the company, that's a good target for a VA. Applications that are deployed and redeployed where you want to contain that complexity," said Colbert. "Instead of having all these different instances where each user is configuring things slightly differently, you can take control of that situation and only give them the right set of knobs on their oven."

2. Build a Data Center App Store

VAs are easy to use and they should also be easy to find and get. Traditionally, Colbert explained, to get access to an app, you need to submit some sort of ticket-based request to IT and then the admin manually provisions it for you. Over the past few years, this has become more automated through curated service catalogs or a managed app store offering IT-approved apps for download. However you make VAs available, users shouldn't have to jump through hoops.

"You want to leverage the simplicity of virtual appliances and give them directly to the user while still managing requirements from an IT perspective," said Colbert. "In tools like AirWatch, you have an end-user app store with apps to set up on your devices. But what we're talking about here is more of a data center app store. If a user needs to provision an app to a server somewhere, they'd come to this sort of secondary self-service portal."

3. Use Flexible Network Configurations

One of the most challenging aspects to getting a VA deployed is integrating with a customer's networks. Allocating storage and deploying the underlying VM are relatively straightforward and easy to automate, but Colbert said networking is where it gets interesting.

"The person building the application needs to be able to give the user enough knobs to properly configure the network. Some networks use HTTP, others may have a static set of IP addresses, and others may be using third-party tools for IP address management. So there's a lot of variation that can trip you up," said Colbert. "It's worth spending some extra time making sure you expose the right set of options for users to configure. And make sure your VA is flexible in the network configurations it can support."

4. Don't Sleep On Security

VAs run primarily on Linux OSes. One of the issues you can run into there is with OS-level security issues. Whether you're using application performance management (APM) or network monitoring software, or you have a team monitoring Linux Common Vulnerabilities and Exposures (CVEs) within the open-source software packages your business is leveraging, Colbert said there should be a procedure set up to get patches out quickly.

"One thing you do as a creator is take responsibility for the security of a VA and everything inside it. Whether it's Shellshock or Heartbleed or what have you, it's on you as a VA developer to quickly react when these sorts of problems hit," said Colbert. "This is one of the things that can limit VAs if the customer doesn't trust the vendor to apply patches. Most ISVs have a whole security team monitoring Linux CVEs. When VMware sees a new CVE drop, there's a whole process set up to execute on that and get patches out in a few hours or days at the very worst. You need those teams watching and ready to react, and the delivery mechanism to get those changes down to end-users."

5. Know How VMs and Containers Fit Together

We started off this piece by talking about a new age of virtualized software and app technology, and much of that is owed to developer and IT revolution brought about by containers and microservices. Colbert explained how containers are a natural fit with VAs and VMs.

"We're seeing a proliferation of technologies in the space that have a lot of different trade-offs and capabilities. Generally speaking, this is a good thing, but it can create some confusion about what's best to do," said Colbert.

"There are two aspects to focus on with VAs and containers: the packaging and the runtime," he continued. "VMs abstract at a hardware level whereas containers abtract at an OS level. But they both have a packaging level to build an image. What folks like Docker have done really well is integrate them with the development workflow. Containers and VMs are both generic mechanisms, so what you'll typically see is either a normal app directly packaged in a VM, or sometimes a container and a VM together directly deployed into their infrastructure as a single application."

That's not the end of the story, though. When experimenting with VMs and containers, Colbert said it's critical to keep in mind how the containerized and virtual apps will plug into the rest of your infrastructure, and all of the other logistical, compliance, and security concerns that come with it.

"As customers start to modernize, you need to solve for Day Two operations. As you build all these solutions around VMs and virtual appliances and extend those solutions to containers, you have to think about monitoring, backup, security, login, disaster recovery. You need to answer all of those questions," said Colbert. A lot of customers ask when to containerize stuff, and I think it makes a lot of sense to drive a faster, more consistent process between development and production. Containerization is pretty easy to do…the challenge is when you get into refactoring an application to become more distributed with a microservices architecture. That's a huge, huge effort."

6. Decide If You'll Use Microservices

How microservices architectures factor into this is a more complicated proposition. Within a container, you can run either a traditional monolithic app or a microservices app broken up into modular services. In relation to VAs and VMs, Colbert says the decision on whether to move to a microservices architecture depends on a few factors.

"The application has to be extremely important to your business and driving top-line revenue. If not, leave it as is and get to it later," said Colbert. "The revenue-driving applications are the ones you want on a more distributed architecture. Either that or anything with really large scale where a lot of users are connecting to and interacting with it, or if you want really fast updates."

Microservices let you update individual components of an app frequently and independently of each other. Because individual services are largely decoupled, developers can update them independently without coordination. Colbert said you get a lot of benefits from microservices, but that customers underestimate the work involved and the challenges of re-architecting, even if the app is already running on a VM or in a container.

"Microservices are great, but don't go off on that journey until you're sure there's a compelling business reason," said Colbert. "If this is a complex top-line application with great levels of scale that needs agility and rapid updates, go for it."

This article originally appeared on PCMag.com.