Are Virtual Machine Servers Better Than Bare Metal?

Part of a Windows® ISV’s application hosting strategy is choosing between running their application on a bare metal or virtual machine (VM) server on their provider’s cloud service.

What’s the Difference Between Bare Metal and VM Servers?

Bare metal servers are dedicated physical machine resources offered by a cloud service provider. The entire machine is dedicated to the ISV. The operating system is loaded directly onto the machine, the ISV’s app runs on that OS, and the app has exclusive access to all the computing resources on that machine.

In contrast, virtual machine (VM) servers run on a physical machine but require a hypervisor to be installed on the machine in addition to the operating system.The hypervisor partitions the physical machine into multiple VMs, each running its own operating system. While each VM runs independently, all VMs on a physical machine share that machine’s computing resources.

When an ISV delivers its app to users from a VM server, the hypervisors required to partition the physical machine into VMs consume 5 to 10% of the server’s resources, resulting in a very slight latency. For most ISVs, this latency makes a negligible impact on the user experience.

But—if the ISV is also using a virtual desktop solution like Citrix® to deliver its application, latency is going to be more problematic. Why?

Citrix complexity creates latency.

Here are just a few examples:

• Out of the box, Windows is not optimized for Citrix—experts count 100 or more possible optimizations that can be done to reduce latency.
• In addition to installation and setup of Citrix itself, implementing a Citrix environment requires coordination of many subsystems, including SQL, storage, and Microsoft® Active Directory. Any miscoordination affects latency.
• Issues in the overall design, even small ones, can add latency; for example, a VM that’s even slightly undersized.
• Misconfigured user profiles will adversely impact application performance.
• Citrix Gateway physical placement—to minimize latency, the Gateway should be placed close to the server.
• Citrix NetScaler can slow network traffic due to misconfiguration, or issues out of IT’s control, like CPU or memory spikes and retransmission timeouts.

Why not just choose a bare metal server, then?

Money.

Bare metal servers are considerably more expensive than VM servers, even if the servers have identical workloads. First, if an ISV has opted for bare metal, they will pay for that entire machine whether or not they use all the resources on the machine. To add salt to the wound, if the ISV needs a cold standby server for disaster recovery (for example, an ISV who needs a standby server for regulatory compliance), they will pay for that machine whether they need it or not.

How much money are we talking about? As of this writing, an Amazon Web Services (AWS) t3 large virtual instance (the largest t3 virtual instance offered by AWS) is $.10 per hour. In contrast, an AWS dedicated t3 instance (i.e., a dedicated physical server) is billed at $5.50 per hour.

So, in a 30-day billing period (720 hours), an ISV will pay $720.00 for one t3 large virtual instance and $3,960.00 for one dedicated t3 instance. While this isn’t necessarily an apples-to-apples comparison—for example, we lack details about how many users can be supported on each instance—it’s a jaw-dropping difference in cost.

{{CTAEMBED_IDENTIFIER}}

Flexibility, Agility, and Scalability

In addition to extra cost, ISVs using bare metal servers do not get the flexibility and agility that VM servers deliver. A new VM server can be set up and deployed in minutes. VMs can also be quickly moved to a new environment or physical machine. In contrast, a new bare metal server setup can take hours or even days if the ISV has unusual requirements. ISVs using bare metal servers need to plan and predict their resource needs carefully; ISVs using VM servers can be much more reactive and agile.

VM servers have a considerable scalability advantage over bare metal machines due to their inherent flexibility. ISVs can adjust their application environment by resizing VMs up or down,  splitting dynamic workloads between machines, and moving workloads, apps, and data from one VM to another. In contrast, when an ISV begins to outgrow a bare metal server, the only option is to add more hardware, which takes time and careful planning.

Real-World Example

Here at GO-Global, we encountered this situation with a new ISV customer using Citrix to deliver their apps to financial institutions from a public cloud service. Due to the nature of the software, this ISV’s customers expected near-zero latency, which led to Citrix recommending bare metal servers to deliver on that expectation.

After years of the absorbing the cost of using Citrix plus bare metal servers to provide cloud access to customers, the ISV’s infrastructure management team started to search for ways to save—and found GO-Global®.

Since GO-Global is an application publisher, not VDI like Citrix, it does not require a hypervisor, eliminating one of the causes of latency at the server level.

At a more fundamental level, GO-Global reduces latency due to its proprietary and patented RapidX Protocol (RXP), used for all GO-Global client-host data communications. Rather than transmitting screen bitmaps over the network, RXP transfers individual drawing commands, delivering faster transmission and better data compression than other solutions. The RXP display protocol is almost entirely asynchronous, which means the host and the client are rarely waiting for a response from its peer. In comparison, Citrix transmits keystrokes to the application server, which redraws the screen with each keystroke.

Additionally, unlike Citrix, GO-Global does not duplicate public cloud infrastructure components and scalability features. Instead, GO-Global leverages a cloud services’ existing infrastructure and scalability features to deliver similar functionality with less complexity and less latency.

The ISV mentioned above is currently preparing to launch their new application delivery infrastructure using GO-Global and VM servers.Switching to GO-Global cut their application delivery licensing costs and will enable them to keep latency low to satisfy customer expectations. Moving from bare metal servers to VM servers has also significantly reduced their costs.

In answer to the question “Are Virtual Machine Servers Better Than Bare Metal?” most ISV’s find themselves choosing between less cost with VM’s or less latency with Bare Metal. But for the ISV covered in this post, by moving to GO-Global with VM’s they didn’t have to choose one or the other, they got both affordability and a great user experience.

If you are a Windows ISV looking for an application publishing solution that makes highly efficient use of computing resources, eliminates unnecessary complexity, and reduces latency, consider GO-Global. GO-Global is an application publishing solution purpose-built to publish Windows applications from any cloud—simply, easily, and cost-effectively.

To learn more about GO-Global, request a demo here or download a free 30-day trial.