There’s a Dirty Little Secret of Virtual Appliances
Nearly all innovative products start as appliances. There are many good reasons for this, but two stand out. One is that an appliance controls the environment the product has to live in. This saves a significant amount of quality assurance testing against multiple different types of environments, but more importantly ensures that the product has the right blend of resources to perform as expected. The second is viability of the company as a start-up. The truth is that a software only product is hard to make enough revenue on to “make it” as a company. So by bundling in hardware and charging more for the total package, margins can be increased to keep the company going in the early days, when it is needed.
Both of these reasons are accepted by most customers as long as the product offers enough value to pay for that additional cost. If the product strikes well in the marketplace, two things happen that drive towards dumping the appliance for virtualized versions of the product. First, now that there is a demand, lower margins can be accepted because economies of scale can still bring enough revenue. Second, competition will come in and offer a virtualized version if the innovator doesn’t.
But there is a dirty little secret that many don’t know about in this transition. You see, many times those original appliances are not just COTS (Commercial Off The Shelf) products running x86 software. It’s cheaper to embed a specially designed ASIC that performs some hard functionality than to write an optimized code for a start-up innovator. It’s not their fault; it’s just a fact of life. So by building an appliance with an ASIC, a startup is able to lower their and boost the performance of their product. Unfortunately, this does not translate when the same code is put in a standard x86 virtualized system.
This is a bit unfair, because it is completely understandable for the innovating start-up to do this, but requires re-engineering the product for Virtual Appliances. New competitors can start from day one investing extra software development to perform optimally on standard x86 architectures because the original innovator built the demand that they didn’t have to and therefore have an advantage. Don’t feel too bad for the original startup, though, because it doesn’t mean that every start-up innovator can’t foresee this issue and invest to eliminate it, but many don’t. They rely on their name brand to get by.
I’ve seen this many times over the years and recently ran into this with Palo Alto Next Gen Firewalls. They are one of only a select number in a recent DoD test that actually delivered true application awareness and not “fake” application awareness in NGFWs. The problem is that Palo Alto relies on an ASIC in their appliance and when you run their virtual version, it cannot keep up and a customer is going to be forced to turn off functionality that makes them special in the market place. One of the other NGFWs that was confirmed to compete in true application awareness? McAfee’s NGFW. And yes, it works the same with the same resources supplied to it that their appliance does because they run software code that is designed for x86 architectures and don’t rely on a special ASIC. McAfee thanks Palo Alto for the groundwork laid down by them, by beating them in virtual performance. You can see a report on it in our resources page HERE.