SDN Startup Creates Distributed Virtual Appliances
July 22, 2013
In the software-defined networking space, I've noticed a number of vendors who label their product as SDN, when all they've really done is virtualize their hardware appliance offering. While a virtual appliance arguably offers an infrastructure more design flexibility, that's a far cry from SDN.
In contrast, startup Embrane has achieved what I believe is true SDN in the network services space. On Monday, the company announced new features and functionality in its heleos product. Let's take a look at Embrane's technology.
- Smarter Process: Five Ways to Make Your Day-to-Day Operations Better, Faster and More Measurable
- Bring Salesforce.com Alive with Your Key Business Processes: Register Now
- Virtualization and Cloud Computing : Optimized Power, Cooling, and Management Maximizes Benefits
- Part 1 Whitepaper - Why Use Big Data for Cyber Security? A Practical Guide Big Data Security Analytics
Since coming out of stealth in December 2011, Embrane has been delivering software-defined networking services by abstracting hardware into what it calls Compute Units, and then using those Compute Units to create Distributed Virtual Appliances (DVAs) on top of its heleos platform. Heleos DVAs include a load balancer with SSL offload and a firewall with VPN termination. While heleos sounds a bit like a hypervisor, it's not a hypervisor on its own. Rather, it works with the hypervisors you already have, with support for VMware ESXi 5.1, 5.0 and 4.1, plus Citrix XenServer 602. DVAs run as virtual machines.
The big idea is that with heleos, you can create DVAs as needed, and then grow or shrink them in an elastic manner by adding or subtracting Compute Units; the underlying complexity of the network and server hardware is hidden. The software heleos operators interact with is the Elastic Services Manager. ESM is the orchestration tool for Embrane services, and the software that does the work of instantiating DVAs and assigning Compute Units. Targeting IaaS and cloud service providers, Embrane has equipped heleos with granular RESTful APIs. In that way, shops with an orchestration system already in place can leverage the API to automate spinning up DVAs. For those not interested in using the APIs, heleos also offers access to ESM via a GUI and CLI.
[Read how Cisco's SDN strategy is taking shape in "Cisco Accelerates SDN Strategy With Dynamic Fabric Automation."]
From my perspective, Embrane's value proposition is clear enough. In a virtualized world, physical network appliances are old and broken. Embrane goes beyond mere creation of virtual appliances by creating distributed virtual appliances with on-demand, non-disruptive elasticity.
Licensing is handled through subscription, usage or a combination of the two. DVAs are not individually licensed, giving customers the flexibility to deploy what they need, when they need it. The programmability of heleos is an obvious attraction, as shops are trying to provide more resources for their customers while not adding headcount. The heleos model scales well, too; as your computing power grows, heleos can grow with it.
The new helos features Embrane announced Monday include a Layer 3 overlay the company calls vTopologies. My reaction to this was, at least at first, confusion. Why does the world need yet another overlay? We've got VXLAN, NVGRE and STT in various states of adoption, and the IETF's NVO3 working group is active and making some headway.
According to Embrane's co-founder and CEO Dante Malagrino, vTopologies was not meant to be a replacement for VXLAN. Rather, it provides Embrane customers with a lightweight alternative to VXLAN. Also, an Embrane deployment can be fully integrated with a VXLAN deployment.
At that point, it started to make more sense. vTopologies allows Embrane customers to stitch together DVAs into a cohesive Layer 3 environment that's completely isolated from other vTopologies (like any overlay). DVAs are vTopology overlay tunnel endpoints, so there's no dependency on a hardware or software switch to perform the encapsulation. ESM acts as the control plane for the mapping of endpoints, so that DVAs know where to send encapsulated traffic to.
Along with vTopology comes vLinks. vLinks are, simply stated, facilitators for service chaining. vLinks allow vTopology users to link DVAs together in a particular order to force specific traffic patterns (that is, flow through the firewall before the load balancer).
Aside from the mechanics of what vTopologies are doing, it's key to consider that vTopologies are managed by ESM--not by yet another tool. For a shop that invested in heleos already, Embrane is now giving them a way to deploy a total customer environment--complete with a secure, isolating overlay--through one piece of software.
For some companies, this could be a compelling ease-of-use choice, but vTopologies might not be for everyone. The overlay encapsulation format is straightforward IP-in-IP over UDP, but is Embrane-proprietary. And as Malagrino pointed out, it's intended as a lightweight solution. While VXLAN has gained enough traction to see broad support in both hardware and software from many vendors, vTopology works in one context--that of an Embrane shop that's providing Embrane-only network services to its customer base. I suppose one way you could view it would be as multitenancy-lite.
In its latest update, Embrane has responded to the rise of OpenStack. Heleos hooks into Neutron (formerly Quantum) such that a DVA can be inserted into an OpenStack domain. To me, this is natural functionality for Embrane to add. Considering the huge volume of activity around OpenStack, Embrane is making it easy for the many shops taking a serious look at it to include heleos in the mix.
I'm hoping to get heleos into a nearby lab soon.
Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations.