No More Installers: Converting to a Virtual Machine

A few of our customers were previously building and selling their application to enterprises, as an installer-based solution. They were riddled with problems, so we switched them to virtual machines (virtual appliances), and it’s quite clear: Our solution is a thousand times better.

Installers have been the de-facto way to provide on-premises software, and have been supported for many years by products such as Flexera InstallAnywhere, BitRock InstallBuilder, InstallShield, etc.

The sad truth is those technologies are absolutely terrible.

The problems with Installers

• The first, most obvious issue with Install builders is their millions of configuration options. Given enough options, people tend to freeze and not choose anything. Why burden your customers with this many fields and options? Just look at this © Copyright Flexera screenshot.
  

You can easily spend months in that software without producing anything relevant.

• Another issue for customers: you never know what the Installer is doing behind the scenes. “One minute remaining” yet you have no idea why or what’s going on. It installs files all over the place, and customers find it almost impossible to uninstall or try a different version (often due to conflicting files).
• At GitHub, we previously provided GitHub::Fi (behind the firewall install) using an Installer. The experience was not good. There were issues of customers having a different versions of the same database, or wacky system configurations which prevented the software from working correctly. A solution to that was bundle all the required dependencies, but that still revealed frequent issues we couldn’t predict, because we had no access to the customer’s system.
• You were forced to support either a specific OS, or try and target  various versions of Windows, Linux, and MacOS. Of course, for the Installer companies, it’s bling bling because they know the changing OS landscape will guarantee repeat business for them.
• If an update failed, it was almost impossible to debug and find out why. The answer was usually “sorry we can’t reproduce that” (for obvious reasons).
• With Installer-based deployments, you’re stuck in an endless loop of supporting software which is not even your core business. Rather than focusing on your app, the Installer turns you into a “professional almost-certified Installer configuration expert”. Maybe you should pivot ;)

Converting advantages

Remember when you had to maintain your own RPM, DEB, MSI and PKG packages, on top of maintaining your installers, and handling migrations of MySQL, Postgres, SQLite? Remember when you had to do all that stuff unrelated to your actual application?

All that complexity becomes obsolete with a virtual appliance; you only need to support one package format, one database, and zero installers. The appliance can be doubled-clicked and imported in a few seconds. Your customers can be up and running in your application just 10 seconds after downloading it.

“Sorry we don’t support that” goes out the window. For example, if your customers previously wanted to use your software with two network adapters, that was very difficult to support (due to variety in each OS). With a virtual appliance, you can ship it pre-configured with two network adapters, and you can easily tweak your application to work with them, since you have full control and knowledge of the underlying stack.

Another great advantage of converting to a virtual appliance: the ability to provide updates which you know are guaranteed to work for your customer. If the update works in your test environment, you can be almost certain it will work for them (well, assuming you’re using Jidoteki’s update system ;)).

Converting challenges

Virtual appliances are a godsend for people familiar with deploying Installer-based software. Our customers are very appreciative of the lowered support burden, the speedy build/test/ship loop, and the consistency and simplification of their customer’s experience.

Converting, though, is not necessarily the easiest thing. Virtual appliances introduce new challenges which need to be considered:

• Rather than telling your customer “it’s your job to keep openssl up-to-date”, that now becomes your responsibility. Security updates to the entire OS and its dependencies become your job.
  
• You need to ensure your virtual appliance runs equally well on multiple hypervisors, such as VMware, VirtualBox, Xen, Hyper-V, and even QEMU.
  
• Your update process will need to be revised and improved (with the advantage of a better overall customer experience).
  
• You still have no control of the appliance once it’s in your customer’s hands, so you need to figure out how to retrieve debug, logs, and usage information.
  
• Building and testing virtual appliances which contain your application requires a different process than simply testing your application locally.
  
• If your application is desktop-based, you need to ensure it works in an X-Windows environment.

How to convert

If you’re enterprising and have a lot of time on your hands, you can opt to download popular open source tools such as Veewee, Vagrant, and Packer. They let you build and manage virtual appliances according to a defined recipe. The downside of that approach is you’ll need to familiarize yourself with a new set of tools, and create all the automation around it.

Of course, I don’t personally recommend it unless building virtual appliances is your core business. You will spend way too much time and expertise doing things you shouldn’t be doing. You’ll find yourself starting from scratch again, and your job title will change to “professional almost-certified Virtual Appliance build expert”. Hey, maybe you can work for us afterwards ;)

We believe if your company is providing Installer-based software to enterprise customers, you should offload the virtual appliance conversion process to us.

That’s our job. We are professional almost-certified Virtual Appliance build experts. We’ve been doing it for over 7 years, and have an incredible amount of experience in this domain (ex: GitHub Enterprise). Moreover, we’ve seen all the little edge-cases and issues which you’ll likely encounter if you choose to do it yourself. We have the answers and solutions to the challenges listed above, and our approach is probably the best in the industry.

We also provide a very simple Management Interface for building virtual appliances. The defaults have been carefully selected to make the process as quick and easy as possible. We call it Jidoteki Meta (Jidometa). It’s flexible behind the scenes, and allows you to build your virtual appliances in-house, with just a couple clicks. You can even launch your builds automatically using Jenkins and the Jidometa REST API, while sitting in Slack waiting for the build status and download links to be posted.

We strongly support, build on top of, and contribute to Open Source Software - so there’s no worry of vendor lock-in when working with us (unlike every other Installer software out there).

Contact us

If you have an Installer-based application and it drives you completely nuts, please contact us. We feel your pain, and we’ll be more than happy to handle the virtual appliance conversion and integration process. We’ll provide you with a simple way to build your enterprise appliances on your own moving forward.