Most SDN OpEx benefits can be realized by automating existing use cases, Cisco says

Customers have less than 5% of basic connectivity automated, so benefits come quick. A Q&A with Cisco’s Frank D’Agostino

As Senior Director of Technical Marketing and Solutions Engineering at Cisco, Frank D’Agostino leads the development and technical go-to-market strategy for Cisco’s Application Centric Infrastructure (ACI), the company’s portfolio of Software Defined Networking tools. Network World Editor in Chief John Dix recently spoke with D’Agostino about what the company is learning as customers adopt SDN. (D’Agostino was formerly VP of WW Technical Operations for Nicira Networks, the company VMware bought to drive its SDN strategy.)

Is there a profile emerging of what a typical ACI customer looks like in terms of the types of challenges they’re trying to address?

frank dagostino

Frank D’Agostino, Senior Director of Technical Marketing and Solutions Engineering at Cisco

Clearly ACI is gaining traction and significant visibility in the industry. We have more than 585 companies that have adopted ACI and more than 2,650 are ACI-ready with Nexus 9K deployments. ACI is being adopted across all market segments, which include cloud providers, large enterprises, commercial, and public sector. Customers want cost-effective networks that are open, application relevant, and support all physical and virtual application delivery platforms in an automated model.

I think a lot of it has to do with, one, we’re a better network, two, we can be application relevant, and three, we’re allowing integration in an open way without limiting innovation. We’re actually allowing vendors that might be competitors in certain market segments to integrate into the operations model, and really it’s a win-win for customers as well as vendors and I think that is why we’re seeing such wide adoption.

People just want a better network that is automated, that has visibility and delivers all the “ity” words, if you will -- scalability, flexibility and agility. The key thing is to not overthink the rich capabilities of ACI and miss out on the immediate benefits of automation and visibility. About 80% of the operation savings come from enabling four basic functions:

  • Automating network connectivity, whether it’s a virtual NIC on a VM, whether it’s a physical port on a bare metal device or a switch, or a VLAN interface that we’ve carved out to be logically independent or secured off for one customer. Automating that basic connectivity is step one.
  • Next customers want to remove the access control lists they have on each device and move the rules up into a profile that can be deployed automatically with the APIC controller. We enable at every port a distributed stateless firewall that runs at wire rate depending on the profile configuration. Moving ACL’s from devices to profiles immediately enables the agility and allows the security profile to move wherever you enable the workload or service chain.
  • Application service chains can be complex and there are a number of physical and virtual devices that have implications for security and policy. Policy isn’t all within one device. It’s actually relevant everywhere the application is enabled, and Layer 4 – 7 services can be enabled anywhere in the fabric. This means that security doesn’t stop as traffic egresses a hypervisor. Security must be relevant and implemented at every hop as you direct traffic between two application endpoints whether physical or virtual, RedHat, Xen, Microsoft, VMware, Linux container, or whatever.
  • And the last one is in an SDN context, where you’re enabling overlays and want to be able to turn on monitoring at every point in the network, so you have a relevant monitoring capability as well as security.

Most customers have about 5% or less of basic connectivity automated. Customers can realize 70%-80% of the OpEx benefits by automating existing use cases as opposed to waiting to get into real deep granular policy. Policy will evolve from automating existing use cases to application models. So what I’m basically telling customers is don’t overthink all the capabilities. Focus on automating existing use cases. Maximize the automation benefits, maximize the visibility and the security, and once you understand what the models are for deploying automation, then move to a more application-driven, cloud-centric, DevOps model.

So we see both enterprise customers as well as cloud providers pursuing a crawl, walk, run model, automating existing use cases and then moving on.

Is there one use case that jumps out as being particularly sensible?

The big one, quite honestly, has to do with security. Everybody is afraid of touching security rules on a device-by-device basis, and that is one of the things limiting agility. VMs come in, or Linux containers come in, or you have a mix of Microsoft and VMware or Red Hat or Xen, and you want repeatability. This is tough given the complexity, so you want to use profiles, you want to get hands out of the operation so there are no keyboard errors, and you want to have security regardless of where the service needs to be turned up and do it automatically.

Does the adoption of container technologies complicate the picture at all?

No, I think it expands ACI’s value. Consistent policies can be applied across the board, further simplifying infrastructure and accelerating a customer’s ability to choose the best application delivery platform without sacrificing automation, policy and visibility. Application services can be chained with any delivery platform, and it shows why a model like ACI is much better than the first-generation SDN LAN emulation controllers.

Leveraging eVPN for VXLAN provides an open standard way of connecting multiple SDN & ACI domains, enabling multiple vendors to drive their own innovations without being limited by the controller of one vendor. Customers use well-known protocols already enabled in networks, like BGP, and connect SDN domains just as they do autonomous systems in the Internet today.

This removes the requirement to conform to a restrictive spec based on an imperative model, like forcing the controller to be in lockstep with the VXLAN Tunnel End Point (VTEP). The future is where application deployments express intent in a declarative model, thus enabling the Linux containers along side Red Hat today, Xen tomorrow, Microsoft the next day, and some combination thereof, including VMware.

Are you seeing customers shifting to containers?

Absolutely. In fact, that’s one of the largest shifts that I see, and we have whole cloud deployments that are going in with no x86 virtualization whatsoever. It’s all container based.

What kind of change have you seen early adopters make based on ACI capabilities?

There are a number of interesting shifts. Network teams realize they are the ones that must securely manage every endpoint of an application service chain. Applications dynamically enabled over multi-pathing in the fabric, with disparate devices supporting different functions, require rich expertise today shared by three teams in the data center – application, security and network. Network teams become more valuable to the organization, to the application teams, when it comes to capacity planning and control and monitoring and troubleshooting.

Everything in the chain is an application delivery point, in some sense. So whether it’s a hypervisor or a VM or a security application or device, operations develop a model to automate delivery of functions horizontally and that one of the larger transitions that happens. And that’s where the majority of the gains are. That’s why crawl, walk, run. Build an automation model that makes sense, simplify security, simplify the repeatable tasks, get the great OpEx benefits and then expand beyond there.

In terms of the crawl aspect, where are customers starting, with a particular application or a certain domain or what?

It varies. Some customers are going all in and building new data centers and supporting this from day one. Other customers are trying to integrate it into the existing infrastructure. If, for example, they have Layer 2 services they want to extend up into a Layer 3 switching or routed point, and then extend the automation and visibility capabilities down into existing domains, they can take their existing VLAN configuration and move that into a Layer 2 bridge domain and then ACI lets them extend profiles and security roles down into those domains.

In other cases we see customers building a pod and moving connectivity over to the pod and then start migrating services. But the ones that seem to be moving the fastest are the ones that are looking at their existing use cases, simplifying security and driving automation.

Do you see companies making any organizational changes when they adopt ACI?

We’ve been used to a cadence of software delivery measured in multiple months, whether it’s three months or six months.   Even in parts of the industry that are claiming to be software only and innovating fast, we still see the three to six month range.

Customers are really getting into the idea of continuous integration. But continuous integration, with code drops every four weeks, new features or functions being brought in, requires very consistent policies and lots of visibility into the network. It’s nothing new. I still turn on a port, I still enable a service, I still connect to a security device or enable a security profile, but the cadence and the frequency are changing, which is forcing the organization to move faster.

Customers are demanding a move to automated models connecting multiple functions from multiple vendors, but doing it in a way where they’re not being limited by one vendor or another. Open choice and automation is really about bringing in any vendor you want, allowing them to maximize their value and not being limited to the lowest common denominator set of features. I think the cadence and how you absorb the complexity and all the change in the application chain is really where the big shift is happening.

How have you had to tweak ACI as you started to gain real world experience?

All products evolve over time. All of the architecture elements we’ve developed and are marketing around ACI -- EVPN leaving the platform, all of the group based policy being moved into Open Stack and now being up-streamed into Linux, the publishing of the APIs, making OpFlex completely open to any vendor (including third-party switch vendors) -- all of that has evolved. It’s the maturation of an architecture driving functions based on wide-scale customer production deployments driving features, timelines, and scale requirements.

Can you quantify the acceptance of OpFlex at all?

There are more than 35 ecosystem partners driving OpFlex, so there’s been a lot of work going on in that area. You can see why some third-party hardware switch vendors may be hesitant about doing integration, but it’s totally open and published. The benefit to everybody that’s participating is OpFlex is it is a declarative southbound protocol, and that basically means we’re declaring that we want you to do this function. Please turn on something or please do something to the greatest of your capacity. It doesn’t say you have to be blue, red or green.

As an example, John, you might be able to bench press 1,000 pounds and I can bench press 500. Well, if I’m the controller you shouldn’t be limited to benching 500 because that’s my limit. I should be able to say to you, “John, lift the maximum weight you can.” That’s what we’ve done with OpFlex and that’s what’s really driving this declarative model. It gives all of the vendors a tremendous advantage.

In fact, as you look across the vendors that are part of the ecosystem, you’ll see we have competitors that realize the value of being part of the model. Shame on Cisco if we can’t win every market segment we’re in for every customer, but the reality is that happens and if our model allows competitors to innovate, that basically allows the customer to get the benefits of the automation model they’re looking for.

Speaking of competitors, you mentioned that security is a compelling use case, and VMware is finding that too. Does that surprise you at all?

VMware prefaces conversations about security with “… in an all virtual environment.” As everybody knows, in real world environments application service chains contain a mix of heterogeneous devices and lots of different platforms, physical and virtual, from many different vendors in a range of topologies.

While there are a lot of OS instances being virtualized, all packets egress the hypervisor and at that point VMware has zero relevance to security. The thing people need to understand is that security is applied at every place in the network across multiple vendors and it needs to be done in a way that’s driven through centralized policy and automation, whether the endpoints are physical or virtual, and that is something VMware is not addressing.

VMware needed a way to move the conversation beyond basic functions of networking because they struggled to implement and get good traction with our customer base, and so they’re leveraging micro-segmentation and security. VMware is the only hypervisor vendor restricting who has access to their APIs and who can innovate in their platform, an effort to control that part of the market.

How is competition with NSX going?

1 2 Page 1
Download the CIO October 2016 Digital Magazine
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.