Since I started with Riverbed in the Stingray Business Unit, many customers have been asking me about SSL offload, and why they would want to move away from their existing hardware ADC's with SSL offloaded into dedicated silicon. It would seem that many vendors of legacy hardware ADC appliances have zeroed in on this in their defence of their install bases with customers who are looking seriously at the benefits of a software of virtualised ADC solution.
With the advent of virtualisation and the push into elastic computation environments whether "on-premise" or into private or public clouds, much focus has shifted to the conversations of infrastructure automation to provide varying levels of elasticity. All of this is essentially aimed at a couple of key objectives:
- Reducing the time to deploy new initiatives
- Allowing applications to scale up and down as needed to meet demand
- Drive better economies by meeting demand when it is needed without having to over provision from the start
So how does this map to SSL acceleration being performed in CPU or on dedicated hardware? It all comes down to the basics of where this elasticity is coming from: Network and Compute capacities, when virtualised, become commodities that can be consumed dynamically and on demand. Now this level of commoditisation is not just about virtual machines or networks being provisioned, scaled or de-provisioned - it is more fundamental than that:
By moving SSL offload onto commodity (v)CPU on a soft/virtual ADC, it means the whole pool of compute is available to service your total ADC workload - regardless of whether it is SSL offload, Web Application Firewall, compression, complex L7 content rewrites or any other of a host of things that ADC's can do for your application.
Now this statement on the surface might seem vague and non specific, so let me nail this down with a specific customer example.
Last week one of our Cloud Service Providers had an opportunity laid in their lap to take on the hosting for an iPhone application that had started to grow in popularity and had hit severe scalability issues in their previous cloud hosting provider. The team did a great job of spinning up the capacity and helping the end user migrate their application in a very short time. All assisted of course with the Stingray Traffic Manager that was front ending the application and allowing it to scale onto a large pool of resources.
Now this might not seem incredible - ADC's have been "saving the day" in these kinds of use cases for a long time now. What sets this story apart is what happened next.
The application grew in popularity again, and the Stingray ADC was able to scale for the end users workload without costing any more money. The customers Stingray Traffic Manager had a sufficient license to meet their throughput requirements. What they needed was more "grunt" in the ADC they had for a combination of elements: more SSL, more caching, more buffering and more L7 Application handling smarts.
So what did they do? They Quadrupled the vCPU and memory allocations to their Stingray Traffic Managers almost instantaneously - this gave them an immediate boost to their whole ADC workload - SSL, Caching, Buffering and L7 functions all at once.
If they had been using a hardware ADC, while the SSL might have been offloaded into silicon, the scalability of the rest of the solution would have meant upgrading the *whole hardware ADC* to get at more compute power and memory. There was no ability to "re-route" the unused SSL hardware offload capacity to make more Compression or Application Firewall throughput. No using it to help with L7 content rewrites, no tapping into the dedicated hardware compression chips to help with content switching...
Any un-used SSL or compression hardware processing power is essentially "lost".
As you can see, by moving to a (v)CPU centric ADC model, the deployment is much more flexible and offers better value for the customer's dollar - the ADC will service the whole workload efficiently - not just elements of it. You have elastic capacity *inside* your ADC too now.
So do you still think you want to do SSL offload or compression in hardware?