First take on Embrane heleos

Filed in OpenFlow, SDN by on December 12, 2011 23 Comments

Embrane came out of secrecy today and announced their solution that virtualizes the deployment of network based services.  In the context of how this affects network virtualization, here’s my initial thoughts on Embrane’s announcement..

My first take is that Embrane heleos is a positive thing for the network virtualization movement. (Read: good for Nicira, good for Big Switch) To be clear, Embrane isn’t virtualizing the network like Nicira or Big Switch.  For Embrane to say they’re “virtualizing the network” is a stretch.  Rather, Embrane is virtualizing network based services, and taking down one of the key barriers to adoption of full network virtualization … deploying network services.

Prior to Embrane, discussions of SDN, Open vSwitch, NVGRE, VXLAN, etc, was all fun and high fives until the topic of load balancers and firewalls came up, lobbing a cold bucket of ice on all the fun.  Routing traffic to a classic physical appliance and back was ugly and so non-multi-tennant, and services deployed on a single virtual machine simply did not scale, with either way creating bottlenecks.  Embrane has fixed that.  Services deployed in virtual machines can now scale out — that was the big hurdle.

A quick thought on workload mobility with Embrane heleos:  “How does Embrane work with workload mobility, vMotion”?

From what I can tell (based on reading the Embrane architecture paper) the workload consuming network services is going to have a session with one of the “Data Planes Dispatcher” CUs that provides the standard network traffic interface to their “virtual appliance” (DVA).  So as I see it, a workload can transparently move with vMotion and still maintain its session with the virtual appliance, provided the Workload-to-Dispatcher logical network topology doesn’t change during the move — typical vMotion considerations.  And this needs to work at scale for SPs.  So all the things Nicira and Big Switch can do with SDN, OVS, NVGRE, VXLAN, etc. in making the logical network consistent and transparent at scale all apply here.

In a nutshell, Embrane is helping to virtualize to network, by providing a better platform for virtualizing network services.

Note that while I’m focused here on the Embrane impact to SDN and network virtualization, Embrane’s technology is agnostic of any physical or virtual network architecture.  It doesn’t require SDN, OpenFlow, VXLAN or any such related technology.  Embrane heleos should work fine on your existing infrastructure using traditional L2/L3 network topologies and protocols.

Verdict: Cool stuff.  If  you’re at all interested in how your infrastructure will evolve in the coming years to the brave new world of SDN and network virtualization, you should definitely check out Embrane heleos and test it out.

Cheers,

Brad


Disclaimer: The author is an employee of Dell, Inc. However, the views and opinions expressed by the author do not necessarily represent those of Dell, Inc. The author is not an official media spokesperson for Dell, Inc.

About the Author ()

Brad Hedlund is an Engineering Architect with the CTO office of VMware’s Networking and Security Business Unit (NSBU), focused on network & security virtualization (NSX) and the software-defined data center. Brad’s background in data center networking begins in the mid-1990s with a variety of experience in roles such as IT customer, systems integrator, architecture and technical strategy roles at Cisco and Dell, and speaker at industry conferences. CCIE Emeritus #5530.

Comments (23)

Trackback URL | Comments RSS Feed

  1. Dmitri Kalintsev says:

    Brad,

    Do I understand it right that from day one the only EVAs compatible with the Embrane’s architecture are the Load Balancer and Firewall/VPN, created by Embrane?

    If this is so, I wonder what will it take to the get the leading vendors to release compatible versions of their wares.

    Cheers,

    — Dmitri

    • Brad Hedlund says:

      That’s right. The load balancers, firewall, and VPN distributed virtual appliances (DVA) are made by Embrane.

      Interesting thought. Begs the question: What’s more important to you? Brand preference? Or the architecture?

      • Dmitri Kalintsev says:

        > What’s more important to you? Brand preference? Or the architecture?

        Robust value-adding functionality, I guess; no matter which brand delivers it.

        If I’m not mistaken, building load balancers and firewalls isn’t Embrane’s core business, therefore there’s a chance that _functionally_ their appliances will be less advanced then those that could be built by the likes of F5, Checkpoint, Cisco, Juniper, etc.

        Please let me know if I’m missing some key point here?

        — D

  2. One point rarely raised is the L2-L4 performance bottleneck triggered by the virtual appliances adoption.

    I clearly see benefits of having L4-L7 dynamic services but what about all the IPSEC, VLAN-Tagging, L2TP, IP forwarding performance issues when deploying virtual appliances running on top of x86/hypervisor?

    • Brad Hedlund says:

      David,
      If the “performance issues” you are referring to are related to CPU capacity, according to Embrane, you can dynamically spin up more “Data Plane Compute Units” distributed across more x86 machines. Sessions are then hashed across the pool of CUs for load sharing and affinity.

      Is there some other “performance issue” you are referring to?

      • David says:

        Yep, L2-L4 performance issues bound to CPU which limit both throughput and I/O.
        And as you correctly described the way for multiplying data plane compute units, we have a similar approach along with optimized L2-L4 protocols but afterwards it is all the discussion on how much resources do you need to perform expected performances while keeping affordable costs…

  3. CK Kong says:

    What’s the performance number of “Data Planes Dispatcher” ? Any load balancing for ” Data Planes Dispatcher”? It could be the bottleneck in this architecture.

    • Brad Hedlund says:

      CK,
      I don’t see why you couldn’t scale out the Dispatchers with GSLB, just like you would with physical load balancer appliances. You could have an F5 GTM or Cisco GSS distribute traffic across multiple Dispatchers.

  4. Matt Nabors says:

    We are looking to roll out a private cloud within our enterprise in 2012. This looks very interesting. Although, I am uncomfortable with the firewall/VPN support as one of our LLC’s is a government contractor and subject to countless audits. I am not sure how this technology platform would fair in an audit of DISA STIG compliance because there is no STIG written for it.

    The real key to cloud, in my humble opinion, is provisioning. The networking is the easy part :) I want a provisioning tool that is vendor agnostic, can make changes on the fly, tracks resources and reports on utilization. This sounds like it will do that. New stuff scares me ;)

  5. Brad,
    Your post is spot on. The objective of the Embrane platform is to offer more flexibility than the existing virtual appliance form factor, while maintaining a look&feel consistent with physical appliances, both in terms of data center application designs and day-to-day management. The focus is on ease of provisioning aligned to existing best practices. As you correctly observe, Embrane is not attempting to redefine L2 connectivity: DVAs present individual interfaces in very specific topological locations, so that any form of switching and routing can target the DVAs’ MAC addresses and IP addresses easily. Once deployed, each DVA interface is in a fixed location (to ease configuration and/or traffic engineering), but new interfaces can be added to existing DVAs in new locations, morphing DVAs connectivity “on the fly”. And yes, if you exceed the throughput of one interface, you can use a GSLB solution to expand throughput across multiple interfaces, as you would do if you exceeded capacity of a physical interface in a physical appliance.
    Each interface then represents an ingress/egress point to L4/7 stacks that are deployed on a farm of computational capacity that can be tuned up and down to serve each individual use case.

    While we do call these “Data Plane compute units”, the main point remains that all the compute units inside a DVA are designed to be zero-touch entities. Like you manage physical appliances and not the individual cores inside each appliance, you manage DVAs, and not the individual cores/compute units inside each DVA. You just have the ability, unlike physical appliances, to pour more cores inside each DVA, if the workload requires.

    • Dmitri Kalintsev says:

      Marco,

      Would you be willing to share anything around planned/future integration with other market players’ Virtual Appliances?

    • Dmitri Kalintsev says:

      Just to clarify further a bit – while LB/FW/VPN GW is good, but IPS/IDS is missing, for example. As is WAN accelerator, WAF, etc.

  6. Dmitri,
    While we don’t share our roadmap plans publicly, we have architected the platform to support any L4-7 stacks/services, including the ones you reference. The initial services are developed by Embrane, but the value of the platform approach we’ve taken is that we can open it up to others over
    time. We just launched, but we’re paying very close attention to the demands of our customers and we’ll fill out the roadmap for additional services over time.

  7. Joe Smith says:

    Brad, what is Dell’s strategic vision with regard to data center networking? How do they plan – or do they plan – on differentiating themselves? Cisco has the whole Nexus/ UCS cluster of technologies; Juniper has Q-Fabric; Brocade has VCS clusters with intelligent fabrics – what does a Dell network (or will look like) in the future?

    • Brad Hedlund says:

      Joe,
      This may not be the answer you are looking for right now, but .. Consider for a moment that the examples you cite; Cisco UCS/Nexus; Juniper QFabric; Brocade VCS — all are either network only or network centric strategies. Think about that for a second. Take your network hat off for just a minute and consider the data center as a whole. Is the network at the center of the data center universe? Or is network the piece that facilitates the convergence of compute and storage? Is the physical data center network trending toward a feature/performance discussion, or price/performance?
      Yes, Dell now has a Tier 1 data center network offering with Force10. And with Force10, Dell can (and will) win in network only conversations. Now consider for a moment what Dell represents as a whole .. a total IT solutions provider of Compute, Storage, Network, Services, and Software. And now consider Dell’s heritage of providing solutions that are open, capable, and affordable.

      • Mark Benigo says:

        Brad;
        Interesting that you are saying Dell solutions are so wonderful that now that you have left Cisco for Dell. I wonder if you will say the same a year from now when you move back to Cisco. I searched your blogs during the duration that you were employeed by Cisco and never found a good word about Dell. Seems like advertisement to me. I used to value your blog when you talked about FCoE but now I doubt the site will be much value.

        • Brad Hedlund says:

          Hey Mark,
          You submitted this comment from a Cisco owned IP address 64.102.249.x
          If you want to bash my blog, that’s fine. Just be honest about your biases by disclosing your competitive vendor employment.

          Cheers,
          Brad

      • eric says:

        Brad,
        Wow! Did you just reference “open, capable and affordable”. That did not take long for you to pick up. What was it the late Steve Job’s said…”woe to those who compete on price”.

        I do agree with you that is will be a software driven market moving forward. But if that is the case what does Dell have to offer…AIM? how many deployments does Dell have? How complicated is AIM to set up? At what cost? Also, take a look at your VIS strategy. How is that working? Does Dell even own any of the IP around that stack? No! Dell does not innovate. They aquire. You can have the cheapest stuff but it does not mean you can compete for lion share of the data center. And if you aquire companies like force 10 and put little R&D into them, what good will they be in two years (look at equal logic. How much R&D has gone into that now that Dell has compellent). What good is “open, capable and affordable” if a customer has to integrate everything to make it work. I can buy pieces of a car cheaper than I can buy the car. But the pieces won’t get me where I need to go. Contrast that to Cisco (who you know well). An integrated fabric compute model from the switch to the dumb server end points. Couple that with an open interface and Cisco’s IP around cloud orchestration and …well it becomes a pretty solid “integrated stack”. The difference between Dell and Cisco can be summed up in very simple terms….”Dell is integratable”….”Cisco is Integrated”

        • Brad Hedlund says:

          Eric,
          Not sure what your point is about EqualLogic, where the YoY growth is around 66%. Yes, Dell acquires intellectual property, so does Cisco. Again, your point?

          I’m glad you bring up the analogy of a car. The car, like a data center, has a few key systems that make it work: engine, transmission, wheels … servers, network, storage.

          When all components are put together at the factory and sold from one dealership, *that* is an “Integrated” system, like a car. If the customer doesn’t want the factory wheels they can bring their own. That’s a choice. On the other hand, when you can only put together the servers and network (with no storage), you’re selling a car with no wheels. You’ll need to buy the wheels somewhere else and “Integrate” them yourself. No choice.

          Cheers,
          Brad

  8. Marcus Dandrea says:

    The world at Dell sounds very interesting but if you look at the overall direction of Cisco I think that software defined networking with be a very big component of the conversation as the company moves forward. The network centric approach that many vendors have today will shift into software based stratgies. If you look at the latest posting by forbes it clearly defines where Cisco is headed.

    http://www.forbes.com/sites/greatspeculations/2011/12/20/cisco-cloud-efforts-can-carry-stock-to-21/2/

    The movement on open standards is clearly where Cisco is really headed but you still have things that will need to go to the IEEE. Cisco innovates much faster on certain technologies and it just makes sense to release those new features that will be compatible with the IEEE standard when it’s released. If you look at TRILL and the approach we took with FabricPath this is a great example.

  9. stefan avgoustakis says:

    **Disclaimer – I work for Cisco, comments do not necessarily reflect Cisco’s opinion and are entirely mine **

    Hi Brad,

    Again an interesting post which did bring up a few questions at my part. I agree with you that the Embrane solution/architecture is indeed cool stuff. However, I struggle to find the answers within their architectureto those challenges tat really need to be addressed when it comes down to L4/L7 services in a “cloud” environment:

    1. How will the latency challenges be addressed when inserting services ? – admit this is not a a cloud issue only but I can’t see how this will be addressed with an architecture like Embrane
    2. Do we go for best of breed services or do we go for an architecture ? I don’t think Embrane’s services have the capabilities that you would expect from the likes of Juniper, Cisco, F5 etc…so we go for good enough and eat the architecture cake ?
    3. If we are able to introduce 3rd party services in the architecture – are customers going to trust the relationship between Embrane and 3rd parties when it comes down to providing Embrane access to the API’s of the service boxes ? ref. VMware Vsafe API and the challenges

    Again.very cool stuff…I do like the architecture but there are still some challenges ahead.

    just my 2 cents..btw…Marco, I think you’re a brilliant guy :)

    Cheers
    Stefan

  10. Derick Winkworth says:

    Great article, I think this is a step in the right direction as well…

    This actually represents a realistic and constrained use case for OpenFlow. These appliances could sit in hosts attached to an OF access/distribution layer. Through the SDN controller you can selectively direct traffic to the appliances as required thus (partially) resolving the topological constraint typically suffered by DC architectures today.. The traffic doesn’t have to to go through the appliance if there isn’t a reason to put it through.

Leave a Reply

Your email address will not be published. Required fields are marked *