The Anatomy of Automation: Q&A With Cisco's Roland Acra

SS: How have you gone about bringing automation to life inside the data center?

RA: The first manifestation of automation in the data center was Cisco's Application Centric Infrastructure (ACI) intent-based networking framework. Before ACI we built things like network forwarding paradigms, access control and policy implementations around this static view of where the applications were on the network. You knew that behind this Ethernet port was the database, behind this other one was a web server or what have you -- and you manually created your policy based on this information.

The problem with doing things that way is that today's applications are much more fragmented; they have a multi-point footprint, and it changes over time because of virtualization and containerization. What we think of as a database at ten in the morning might have nine VMs implementing it on three servers, but by noon it will probably peak to 23 VMs on a whole bunch of other servers. And yet we still want our policy to follow that mobile, nomadic and elastic workload.

So, this was the genesis of ACI, which replaces this model with a programmatic paradigm that allows users to define a contract that they want to initiate with their network; one which defines which applications can talk to what databases; issues those instructions to the network using the kind of abstractions that an application developer is familiar with; and goes on to ensure that the network continues to enforce that policy regardless of whether the database expands, shrinks, or moves around because of things like containers.

And that's the genesis of ACI. Simply, it's a new, expressive language for you to declare what you would like the network to do for you, and we've had a ton of success with that. Today we have upwards of 4,000 customers with big ACI fabrics.

Step two happened about a year ago, when we brought Tetration Analytics to market. The purpose of Tetration is to answer the questions that came up when customers implemented ACI and realized that, while it was wonderful to be able to define intent on the network, they lacked the level of visibility into what was running where in their data centers to be able to take advantage of it and formulate their intent in the first place.

So, that's what Tetration does: delivering broad, pervasive visibility. Not a single packet gets missed. Not a single communication element gets missed across all the applications that are running. More importantly, it automatically creates the intent, expressed as a white list of what is allowed, using this pervasive visibility and behavioral observation of the applications over the network as well as within their host operating system. It does an amazing amount of work by sitting there and listening to what the network is doing, and what workloads are doing, teed up through observation and machine learning.

So, this is a new concept. Increasingly the industry is using the term "intent-based networking." And there are lots of definitions. To me, in the data center, intent-based networking is about creating the ability for programmers to formulate what they would like the network to do for them in way that is expressive, that a programmer relates to. A coder, not a network admin.

But Tetration is more than that. It gives you the whole life cycle of everything running in your data center; the inventory and footprint [of the applications]; how these change over time; how they talk within each cluster to one another, and how they talk across clusters; it gives you graphs of connectivity on who's calling who when, on which port, and in which direction; and ultimately it results in a suggested white list that you, with ultimate human agency, correct or agree with, or complement with context that we can't infer from observation of telemetry, and then lock it down as your unique policy, and make sure that it is honored and enforced in a way that the network can support.

And the exciting thing is that Tetration works both with Cisco switches, at line speed, if you happen to have a Cisco nexus switching network, or via a software agent that travels with the workload regardless of underlying switching infrastructure. This means it can work in a Cisco environment, a non-cisco environment, or where you have a mix. And it can work in a cloud infrastructure, so customers can use it with Amazon or Azure or whatever.

SS: Which means you can get the benefits of this whether you have your own private cloud or whether you're transitioning across a public cloud?

RA: That's right. Or if you're straddling both, which is often the case.

SS: A hybrid cloud.

RA: That's right; a multi-cloud footprint. And this is really where the majority of our customers are today. They like some attributes of Amazon, they like some attributes of Google or Azure, but there's a lot that they continue to do on premise, and they don't want to have a fragmented policy and compliance model. They're saying "I have to prove that my consumer data was treated with the utmost care... we can't have an Equifax situation. I want to prove that I've protected the databases from not talking to strangers or not being exposed to more connectivity than they have to."

We're moving on from how we used to build IP networks, and enterprise networks, which was "anything goes," with one or two exceptions. Today, the prevailing model for security and for compliance -- known as "zero trust" -- is to say "Nothing goes, except where I open the veins for the blood to flow through." The new paradigm is "don't talk to strangers."

Next page: Hand me my Kevlar jacket