TEC37 E13: Cisco ACI, VMware NSX or Both?

Please view transcript below:

Robb Boyd:                   Many organizations are looking to software-defined networking, SDN, for their data center network. Now there are two different leaders in this space, and they both have their champions in every enterprise. What's best for your situation? Cisco's ACI or maybe VMware's NSX or perhaps some combination of the two, assuming that's even possible. Well, I recently had a chance to dig into this topic with a couple of data center experts, because you got questions, and today, we are going to get some answers. So welcome to TEC37, your podcast for technology education and collaboration, from our friends at World Wide Technology. Today's episode is sponsored by Cisco.

                                    Well, two technical solutions architects from World Wide Technology join us to weigh in on these questions and draw upon their experience. Please welcome Matt and Eric. Guys, I'll have you introduce. Matt, let's have you start. Tell us a little about what you do and what brings you today on our guest panel. 

Matt Hilliker:                Yeah. Matt Hilliker. I'm a Technical Solutions Architect with World Wide. Like you said, I'm on our Global Engineering team at WWT, and I focus on data enter networking, so anything software-defined networking as it pertains to the data center, ACI, NSX and also traditional networking... things like that. 

Robb Boyd:                   Excellent. Excellent. Eric, how about you?

Eric Fairfield:                 Eric Fairfield. Part of our Global Engineering team. Peer of Matt's. Focusing on all things data center networking, as he said. Everything from your classical design to software-defined, with all things ACI and NSX or both. 

Robb Boyd:                   Well, I [inaudible]. Those are two big subjects, but that's just probably just touching the surface in terms of what you guys have experienced in terms of all kinds of things that would come up in the data center. You guys are both global. You're both, as I understand, assisting customers around the world for World Wide Technology in various situations. So I'm not going to force either one of you to pick a side, as would be more fun from a challenging perspective, but Eric, I'll just start with you since you were speaking last. Let me ask you. Let's start with a setup. Tell us, how would you describe to someone that may not be completely familiar, what is Cisco's ACI? Key points.

Eric Fairfield:                 Cisco's ACI, the primary factors of a ACI is it's a simple automated fabric to start with. That's one of the premise points of ACU. Again, it's the simple networking. It's a foundation that you can automate. And then, on top of that, we get into the security aspect of ACI. We're able to secure the applications and end within the data center much more effectively in the past with both macro and micro segmentation. 

Robb Boyd:                   Is it fair to also characterize, as we look to draw upon some just fundamental differences, is that ACI is a combination of both overlay and underlay, perhaps more tightly integrated, or certainly designed to be tightly integrated... I should say that. Is that fair statement? 

Eric Fairfield:                 Absolutely. I look at ACI as a hybrid software-defined network, where it owns the underlay, the traditional network underneath it and the overlay, and also extends into the Cloud and remote sites as well. 

Robb Boyd:                   All right. We'll dig into the details more in just a moment. So let's go over you, Matt, for NSX. How do you describe it to someone that may not be completely familiar with it? 

Matt Hilliker:                Yeah, so NSX is VMware's software-defined networking solution. A little bit different from ACI in that there isn't really any hardware component that you purchase from VMware as part of the solution. It all runs on either the vSphere or KVM hypervisor. So NSX does aim to be hypervisor agnostic, if you will, so supported on both be vSphere and KVM. But hey sort of take a different approach, but ultimately still trying to bring networking and security policy to your workloads, your applications, wherever they may live. 

Robb Boyd:                   Well, just to get this done right off the top, can I get either one of you two just go ahead and give me the answer on which one I should deploy? Nothing?

Eric Fairfield:                 Wow. That's a loaded question. 

Robb Boyd:                   No. I know. There's no right answer.

Matt Hilliker:                Yeah. [crosstalk].

Robb Boyd:                   There's nothing better than asking an engineer to making a, "This is always the right answer" kind of decision. Well, no, so how do we begin breaking these down? So I think they're both very worthy providers in the software-defined space. They both have a lot of champions and people that are familiar with them. But what are the kind of things... How do we how do you begin breaking this down, because I assume you've worked with a lot of customers in these deployments? You've deployed both. So what kind of things are important to understand, perhaps use cases or something, in terms of how people would look at these things differently? 

Eric Fairfield:                 I would say the first thing that I look at is, "Why are we having the discussion?" What's driving the change in your data center network? Is it simply a refresh? Is there something about how you want to deliver your applications differently? Stepping back and ultimately looking at what's keeping you up at night. How can we resolve that? And where do you want to be in the next three to five years in terms of delivering applications to the business? 

Robb Boyd:                   Well, are there specific things that a customer watching this, let's just say it that way? If a customer is considering these things, what are the big elements maybe that someone would be telling you in your consultative capacity that says, "Oh, that begins to tell me these are the things where you start to orient in one direction versus another." What are the what are the ones that tend to sway you? How about you, Eric?

Eric Fairfield:                 I would say the things that tend to sway me is, "What are we looking for in terms of environments? Are we looking at containers, Cloud, multiple data centers, our amount of physical work load versus virtualized workload?" Those are the things that we want to start looking at is, "What's that workload going to look like and where's it going to be and what's the connectivity requirements for it from a DR perspective, active standby versus active active, et cetera?" 

Robb Boyd:                   Matt. What do you think? 

Matt Hilliker:                I would honestly completely agree with Eric. It goes back to being use case dependent and, similar to what Eric said, I like to take a step back and really try to understand, "What are the initiatives of the business?" "What are the technical initiatives as well?" And then, "Where can a solution meet those initiatives in the middle?" And so, when you start to do that you tend to tease out a few more details from the customer as to what they're ultimately trying to accomplish, may uncover a much larger opportunity than just software-defined networking. It could be a much larger data center play overall. But you tend to really get to the root of, "What kind of requirements do they have of their data center from a networking and security standpoint?" 

Robb Boyd:                   Is it possible to get you guys to weigh in on what you think is better about certain solutions? And you can caveat it however you want, but I'm just kind of curious. Obviously, I think everybody's going to be good at some things, and it's not to say someone else is bad at it, but what kind of things would you hold up as one being ideal for? 

Matt Hilliker:                Yeah. So I think it's fair to say that, for a long of time, a lot of people have considered Cisco as the king of networking. Certainly, there's other vendors out there, but a lot of us in networking space, at World Wide especially, we've built our career on Cisco. And so, I think one area where Eric and I definitely agree that ACI as a solution is very good at is providing a very easy to provision underlay an overlay architecture. But then, what ACI is also very good at is the multi-location capabilities, and his is all encompassed under Cisco's ACI Anywhere marketing term, if you will. So you have capabilities like multi-site, multi-pod. You have Cloud extension and with the Cloud APIC and things like this. So Cisco has done a very good job in that area, I would say.

Robb Boyd:                   And is that an important element that a lot of people, when they're moving to SDN? Either they've already been doing something different, in a more traditional fashion, for multiple data centers and for security and things like this. When they're going to SDN, what do you think is a big driver? Why now? What would be a catalyst that may also help open up the discussion? 

Matt Hilliker:                Yeah, I think IT teams are constantly being asked to do more with less. Network architectures aren't becoming simplified. They're becoming more complex, even if some of that complexity is being abstracted away. But the size of the teams seem to be shrinking over time. So the needs of the business are increasing, but the sizes of the teams are going down. And so there's been this push to try to abstract away some of these more manual tasks and things like this, tasks that don't really add a lot of value to the underlying business. It doesn't really do anything for your apps and services. And so, if we can abstract that away through some type of software-defined networking solution, then the engineers, architects, et cetera, they can spend their time on tasks that actually do have a qualitative and quantitative impact on the business. 

Robb Boyd:                   That's always the dream. As busy as we are all, it's amazing often the discussion comes up around moving towards automation, and we're worried about not having a job. And I'm like "Who's been getting off early each day and somehow finishing their to-do list?" Because I have yet to ever encounter that. I want to make sure... I want hear some more positives from a VMware, NSX direction. Eric, what would you hold up as saying, "These are the things you love about what NXS is capable of doing?"

Eric Fairfield:                 Well, as Matt said, one of the big things... Cisco's been doing this a long time, so NSX is having to catch up. But one of the things that I'll say is, they've been catching up really fast. I mean, they've been changing things, adding new features, very consistently. Heck, they even completely changed architectures from NSX-v, which only worked on vSphere, to NSX-T, which has multi-visor support. It's got bare metal support. It's got container support and Cloud extension, much like ACI does. In fact, with NSX 3.0, federation support came. So they're starting to get into the multi-data center support game much more effectively than in the past. So really, they've been stepping up their game just as much as CISCO has. And, as Matt said, there's a lot of things that they both do really well. And it's a matter of stepping back and looking at, "What are we trying to accomplish?" "What one's going to check the most boxes?" And, "Are there going to be more boxes checked if we do both?"

Robb Boyd:                   Okay. Yeah. I want to ask you about both in just a second, but as a setup into that, let me ask you... Just stick with you for a second, Eric. Layer 8, so I feel like, there's a lot of times, there's a network team that probably has a lot of experience with Cisco and an understanding of exactly where things begin and end, perhaps even if they're not that familiar with ACI yet in this scenario. But then, the exact same thing could be said about your VMware fans that may be in a different part of the organization. And so, I can imagine you guys have to reorient your conversation, depending on who actually starts talking to you first, in terms of what angle they may be coming from. But could you highlight a little bit about the reality of how organizations are structured and how that has an effect on... Because we've seen this in other technologies, but how's that having an effect on these type of decisions?

Eric Fairfield:                 Oh, it absolutely... It's crucial to get both groups in the room together, working together. This reminds me of the old days in the early 2000s when I started doing voice over IP. Same problem. Having to get both the server and virtualization teams in the same room as the network people, as the security folks... And, again, getting away from... You'll see a lot of times where the network team brings Cisco, because that's what they know [crosstalk] and the OEMs target as such, where, again, it's getting them in the room and saying, "Let's talk about what the end game is, not about what this one does, that one does. What's the end game?" And figure out the best option.

Robb Boyd:                   Does that often require... Because I think back to even working in security, and then, you brought voice, and I've seen it happen in stores, as well, where sometimes you're like, "Wait. This can't be something that's going to be accomplished at the hands-on level." You need senior management support saying, "This is what we need to do." And they're the ones saying these people have to be present in the room. When it comes to that... So let's talk about both now. Going back over to you, Matt. Is it possible to do both?

Matt Hilliker:                It is absolutely possible to do both, whether it's a good idea or not, again, is entirely dependent on what you're trying to accomplish, like Eric was alluding to there.

Robb Boyd:                   Well, let's get into more details on that. Does it differentiate between... I don't think we've talked a lot about security differences, perhaps, micro segmentation and where these things happen. What type of differences are important from that perspective, because, I imagine, you get all the same people in the room, and you talk about being able to understand the long-term goals so that you can provide accurate device to where you are now to where you want to be, because it requires input and buy in from both, but, I guess from the security difference, going back to the earlier question of, not which one's better, but what kind of things become important in terms of how these are implemented? If you're looking at doing both, are you hobbling one versus the other or blinding one on the other when you're looking at those type of implementations?

Matt Hilliker:                You absolutely could, if you're not careful. So that's why we definitely encourage our teams to have a discussion with us and their customer when they start asking about bringing ACI and NSX together. They can absolutely work well together, but you ultimately need to understand, "What are you trying to accomplish," and then "With what solution, does it make sense to have that particular task or the piece that you're looking for?" So you mentioned security, for example. Does it make sense for you to build the majority of your security constructs and ACI with its capabilities, or does it maybe make more sense to spend more time on that aspect and NSX? It ultimately just depends on what you're trying to accomplish. Going back to what you were asking Eric about earlier with, "What is NSX good at?" One particular area that they're very well known for is this distributed firewall feature that has drawn a lot of customers to NSX over the years. [crosstalk]-

Robb Boyd:                   Can you talk more about that exactly, and define "firewall," just to make sure that we're all speaking from the same hymn book? What is your definition of "firewall" in this situation? And what is it that they're doing that's not easy to do or possible to do elsewhere? 

Matt Hilliker:                Yeah. So in the context of this discussion, when I say "firewall," I'm really talking about a stateful service, if you will, that can potentially look all the way up into the Layer 7 part of an IP packet. So that is something that you cannot do with ACI natively. You can do something like service insertion where you can intelligently redirect traffic to a firewall of some kind, regardless of what the vendor of that firewall is. But the neat thing with the distributed firewall, which is a truly distributed service within NSX-T from VMware, is that firewall lives at the workload level on every single NSX host. And so, that's really, really cool, because you're able to enforce security policy on a per workload basis. In fact, you're enforcing that security before that packet even hits the virtual switch. And so, if you talk about having a segmentation strategy or some kind of segmentation initiative with a customer, that tends to raises a lot of eyebrows, because being able to segment east-west tends to be very important to them. 

Eric Fairfield:                 Yeah. And one of the things I'll add to that, too, when you compare that function to ACI, a lot of customers look for having a solution that looks from a rule set perspective like a firewall, and that's big difference between ACI, is it doesn't have that firewall rule set look that a lot of security teams do look for. That's why a lot of people tend to gravitate towards the distributed firewall, is that capability, as well as, to them, it's a more natural approach in look and feel.

Robb Boyd:                   Well, I feel like ACI's got a... Granted, I'm not aware of its ability, and it makes sense that it wouldn't have the ability without a service insertion to be able to even see things at that level. And so, I'm always a big fan of keeping security both close to the workload or close to the user or both in those situations and having some defined boundaries. But what is ACI doing from this perspective? Because from a security perspective, one of the things I've always liked is the notion of being able to contract-based policy, grouping things together to be able to simplify policy. Is that stuff go out the door more security-oriented stuff on the VMware side or does it still have a play?

Eric Fairfield:                 No, it still has a play. It really comes down to how we're trying to do and what the service that you're trying to deploy. If people are requiring stateful firewall inspection, ACO in itself, the fabric is a stateless firewall that's based upon five 5-tuple type value for the contracts, so it's really good at doing that. You just have to know how to build out your contracts and have that application dependency mapping if you want to get that much detail to your application security. And again, that's a great... I don't necessarily call that "micro segmentation," but it's a great macro segmentation start. Not to mention, it has the macro segmentation capabilities of multi-tenancy and multiple VRFs, and that is something that just started with NSX in 3.0. So NSX just recently caught up to that, whereas ACI's had that since 1.0.

Robb Boyd:                   Yeah.

Matt Hilliker:                And so, that's something that could really work well together, too, because if you're bringing both ACI and NSX together, we like to think of security as like an onion. You wouldn't want to have just a firewall out at the perimeter of your network and that's all you have, because then if that device goes down or something like that and that's all your security, well, you're going to be fairly well exposed there. And so, what you can do, like Eric was saying, is use the contracts within ACI to have a little bit more macro approach, kind of pick off the low hanging fruit, if you will, from a threat standpoint, and then, get into more of your micro segmentation type stuff down at the NSX layer, if you'd like.

Robb Boyd:                   If I'm thinking of... I'm just saying this loosely, but whatever you'd call the team that's more in favor of VMware... What would you refer to people from that side of things? The virtualization team? People that are more [crosstalk]-

Eric Fairfield:                 Virtualization compute team.

Robb Boyd:                   Okay. Virtualization compute side versus network, in terms of Layer 8 issues that we talked about earlier, is it a plus or a minus? Because it sounds like, if you were doing both together, is there a Layer 3 boundary here that now keeps those divisions completely separated so that you always know, "This is your set of stuff to worry about. This is my set of stuff to worry about?" And if that's indeed the case, are customers jumping on this to preserve the easier path of not solving any organizational issues with a deployment and simply preserving status quo by doing both? Is that a reason that anyone would ever do that? 

Eric Fairfield:                 I've seen both approaches in how that dealt with and operated, where there might be an ownership line in the sand, let's say, where the compute and virtualization team own NSX from a deploying the segments and all that. And the network team owns the BGP peering on the NSX Edge and the rest of the network, the underlay, et cetera. And again, they hand off the compute team where they're going to run with everything. That's not unusual in a vCloud foundation environment, because at that point, you're handing off, hopefully, a range of IP addresses that really you're going to let that team dole out and swizzle however that they want to, and you're worried more about that Layer 3 handoff. And they can operate really in Cloud-like fashion, so you're not having to worry about all the networking of NSX.

Robb Boyd:                   Anything additional on that one, Matt?

Matt Hilliker:                I would just re-emphasize the fact that it's important, regardless of what path the customer goes down, that the network team at the server teams, they need to start communicating with each other. And if you start talking about bringing both NSX and ACI together, I would list it as a critical component. If they had a hard silo between them or if they don't have a good relationship, there's politics going on to whatever, to where they do not get along for whatever reason, in my opinion, it's going to be doomed to failure, because you need mutual cooperation.

Robb Boyd:                   And so I assume then we're still seeing that in the customer base these days. Are you seeing examples of where those subdivisions are still persevering and those differences are still something that has to be addressed? I guess you wouldn't bring it up if it wasn't still a reality.

Matt Hilliker:                [crosstalk].

Eric Fairfield:                 There's some reality to it here and there.

Matt Hilliker:                There is. I've seen both sides to it. Obviously, Eric and I, we split the customer opportunities. It just depends on how what person that goes to. But I've been encouraged by a few organizations that I've spoken to in that they have begun developing what they tend to call a "tiger team." So it's not necessarily a network team or a server team or a storage team. It's one team, but they've got representation from network, from security, maybe even up the application side, all working together very cohesively. And I'm sure to tell those customers, "That is very forward-thinking and that is the way forward," because that's going to kind of remove any of those real or perceived roadblocks to making these solutions work well together. 

Robb Boyd:                   When we were talking earlier... I can't remember which one of you brought this up. I think it was Eric. But you were talking about the ways in which NSX... And don't mean this in a negative way, but network-oriented folks may need to be on the lookout for ways in which NSX may sneak into an organization. Assuming I'm characterizing that correctly, can you restate it correctly and expand on it?

Eric Fairfield:                 Sure. Sure. A good example is you might have an environment that a customer has a ACI in place today, and all of a sudden, pivotal container system comes into the fold. That's going to be running NSX. Now the question is, "How do we integrate this?" And that's why it's always important when we do in ACI design workshop that we have that discussion of "what if" and "how do we plan for that 'what if,'" that a side care-like environment like this comes in where it's an environment that's going to connect to the ACI fabric, and how are we going to accommodate for that? And if it works well, you just have to know how to plan for it and operationalize that. Who's going to own that peering? How far can that network team own NSX? How far are they willing to? And if there's pushback on that, getting that tiger team mentality, that Matt referred to in place to, in place to avoid the Layer 8 and 9 issues. 

Robb Boyd:                   Okay. Is there any way that you would see that happening? Is there anything that gets triggered? Is there any failure scenarios that you need to be aware of or is it just something that kind of comes up and it would come up in conversation, and thus, you need to then dig in further? Just trying to think of it as a major... You know how sometimes you get something on the network suddenly that's just handing out addresses or something, and it becomes obvious that something bad is happening? But I don't think you're talking about that type of intrusion on the network.

Eric Fairfield:                 No. Usually, it's the, "Oh, by the way, in the next six months, we're putting in PKS." And the network team goes then, "How are we doing that?" And-

Robb Boyd:                   Or, "What's PKS?"

Eric Fairfield:                 Yeah, what is, right? But [inaudible] it's having those discussions when we do these design workshops or these briefings, giving people a little forward thinking about, "How do we address this if it needs to happen," and "Don't be scared about it." There's nothing technical that says you cannot and will not integrate these two environments. It's educating them on how it can be done, the different options. Because there's multiple ways to do NSX on ACI, it's just a matter of, "What's the right way for what we're putting in?" And it's not one way or the other. Both ways can integrate at the same time. So it's just getting people to step back and not worry about, "Is it even going to work?" It's, "How do we make it work?" "How do we deliver what the business needs?"

Robb Boyd:                   Talk a little bit about... I don't think we've gotten into this... but single overlay versus double overlay.... Whoever wants to take that. It seems like that that's the potential also that you get into. And I remember back for my Cisco experience, it felt like VMware is always willing to say, "We don't care what's underneath." In reality, I think we all do. And so, it's not something you're going to leave to chance. But is there an issue with single or double overlays and a choice to be made there in terms of when you're looking at these deployments? 

Matt Hilliker:                It's definitely something you have to consider, especially when you will always want to just understand how the technology is working underneath. You're absolutely right. And with an NSX-only design, VMware, being software only, they have the luxury of saying, "Oh, we don't care about what the physical network infrastructure looks like." In reality, that's not quite true. It does not absolve you from good network design. But when you bring ACI, NSX together, you've got a really strong, resilient and robust underlay right there waiting for you. 

                                    Now, as far as single overlay or double overlay is concerned, ACI is both an underlay and an overlay solution. That's the way it's always going to work. You cannot choose to just not use the overlay if you don't want, so it's always going to be there. But with NSX, it's not exactly the same thing. So you can deploy NSX in a couple of different ways, but you have the option of whether or not you want to use the software overlay capabilities. And so, that's where this whole single underlay... or a single overlay, excuse me, versus double overlay debate comes into play is the real question is, "Are we going to use the overlay capabilities of NSX or not?" And so, if you're not, you just going to have to make some considerations for how that's going to be deployed on the ACI side. You're also going to be forgoing certain feature and capabilities that NSX has, because there are some capabilities within NSX that relies on that overlay capability.

Robb Boyd:                   Here's one I just thought of that I don't we talked about in advance as we were planning in this conversation, so I'm just curious [inaudible]. What does it.... You always worry about the old ... I always got this thing on my wall is, "It's not the network's fault..." but this notion of when it comes to troubleshooting and something like this, if you're in a dual environment like this, how high is the chance that it's more difficult to discern exactly where your issues are coming from, and does your vendors support suddenly get different, because they feel like, "Well, you didn't deploy NSX in the way in which we recommend and you're doing it in this situation?" Is there any finger-pointing issues or something to worry about there in your day two beyond scenarios?

Matt Hilliker:                Thankfully that doesn't seem to be a problem, at least not one that I've heard of. Both VMware and Cisco have come to the realization that customers are going to do this and with or without their help.

Robb Boyd:                   [crosstalk].

Matt Hilliker:                And that's really a great position for a corporation like World Wide to be in, because we sit in the middle, and we're able to explain the facts to the customer of how exactly they need to do and what they need to look out for. But both VMware and Cisco have design guys for bringing the two solutions together. That doesn't mean they necessarily see eye to eye, but to, my knowledge, there hasn't been any supportability issues or anything like that. To ACI, the encapsulated packets is just another service riding on top of the fabric, so it shouldn't really interfere. 

Eric Fairfield:                 Yeah. Some of that will come down to you single overlay versus double overlay, where do you start looking then? And usually if it's a single overlay, people start looking in ACI in its tool set versus NSX. When double overlay, they'll start looking in the NSX tool set. 

Robb Boyd:                   Okay. Let me ask you about this, another potentially... I don't want to say "dangerous question." I want to talk learning curve. So I know going from traditional data center understanding of how things work to AC was a big turn for me, and I've never had to deploy it. So I can't imagine what someone going through that from a deployment perspective is looking at. So I know there's a learning curve and a different head space to be in with terminology and equating things on the Cisco ACI side. My assumption is, is there some similar thing on the VMware side or, if I'm a vSphere expert, and I've worked in this for years, am I going to get NSX like that? What's the learning curve to be aware of in either of these? 

Eric Fairfield:                 Both sides have learning curves. There's simply no way around it. ACI's got its nuances and NSX has its own set of nuances. How NSX routes between different layers, Tier-0 and Tier-1 is very different than what a traditional Cisco networking person is used to. So regardless of which technology or both you're going to, you're going to have new skills and learning those skills is going to be incredibly important. And then, on top of that, they both do automation, so you're going to be getting new skills there anyhow, because if you're sitting in the CLI or the GUI all the time, you're probably not spending the time best there versus learning some of the good basics of automation.

Robb Boyd:                   Yeah. Does either direction that you choose to go in, do you feel like either side has any limitations in terms of where people are going next, whether it be Cloud adoption, automation and DevOps tool sets, anything like that? Are they both kind of working in that direction and seem none of these decisions are going to affect that negatively or anything to be aware of there? 

Matt Hilliker:                I mean, Cisco has definitely done an outstanding job of embracing the idea of automation and [inaudible]. Most people are probably familiar with Cisco DeadNet. There's an enormous community there, an entire line of professional certification. So both Cisco and VMware, as far as ACI and NSX are concerned, both have a very robust and well-documented API, so you'd be able to interact with that API directly if you'd like or consume a tool like Ansible or Terraform, things like that. If you're [crosstalk]-

Robb Boyd:                   Yeah, it feels like when we get into the Ansible, Terraform and, especially, APIs, now we're starting to get a language that's potentially working across more than even just Cisco and VMware. And so, maybe that goes to your point of saying if you're spending too much time in the UI of any one of those things then you're probably not doing your job correctly, because you need.... Because a lot of that stuff  that's happening at that level is going to be more of the grunt work that you really want automation to take over, I would assume, and that's generally the goal of moving to STN is to make things easier and get to a point where we're doing less of the mistake-prone manual intervention. 

Eric Fairfield:                 Oh, absolutely, because when you're deploying Vms, you're going to be doing API calls to vCenter. You're going to be doing API calls to NSX or ACI. You're going to be hitting multiple environments from, let's say, an Ansible playbook or something like that or within Terraform. You're going to be hitting multiple environments anyhow.

Robb Boyd:                   Interesting. All right. Well, guys, as we wrap up here, I tell you what, tell me a little bit about what resources you might have available, because I know you guys are always good at this and you've already been hammering on me that education never stops, and a lot of this sounds like... It sounds like anyone watching this, if this is truly a question someone in our audience has a mind, trying to figure out which direction to go, I think the only real way you could probably help them, I would assume, is to know something a little bit more about their architecture, and it feels like it's a more personal interactive discussion. What kind of things have you guys started doing or have you been doing, I should say, at World Wide, to offer more assistance in this area?

Matt Hilliker:                Yeah. So at World Wide, we're very proud of what we call our "Platform," the "WWT Platform." You can go out to wwt.com to check it out.  But we have a variety of resources, divided up by a solution area there. So the area that Eric and I obviously focus on is data center networkings. So we have a variety of workshops that we could give for a customer and also both schedulable and on-demand labs, so lots of different resources to get a customer up and running there. 

Eric Fairfield:                 Yeah, absolutely. In this particular area, we have briefings that are available that talk about ACI and NSX, NSX on ACI. Really just talking about the technology, digging into what you're trying to do. And then, we have workshops that can be anywhere from four hours to maybe a day, two days, depending on size and complexity on those same topics and really getting into being design workshops around those three topics... One, ACI, NSX or both.

Robb Boyd:                   And then, I assume that's where... And that indeed when you talk about getting into design workshops, this is where you're going to get into... Let me understand a little bit about, you mentioned at the top and throughout, what are you trying to accomplish. So it's not enough for them to say, "I want to do SDN," whatever that means. You want to know both where they want to go long term, a little bit more about the organization if you don't already understand them, because you guys have a lot of good relationships. And then also, I would assume, where they are in terms of what's been deployed, what's been attempted, perhaps, and things of that nature to account for the recommendations that would then follow from there. So I assume, because this is not a decision. No one cuts over to this kind of thing overnight. This is something that requires a strategic rollout or extension as you slowly retire old ways of doing things, adopt new ways or perhaps bring up new sites and such as you do this, I would assume. 

Eric Fairfield:                 Absolutely. Everyone kind of chuckles that my mantra is, "SDN is not a project. It's a journey."

Robb Boyd:                   Okay.

Eric Fairfield:                 It's a crawl, walk, run type of engagement. You're always bringing in new apps. It doesn't stop. 

Robb Boyd:                   Yeah. It's funny how fast. Can we still remember the point where we were arguing about whether SDN, in terms of.... Granted every vendor, and I'm guilty of this, has over hyped the latest POT acronym, but obviously, the fundamentals of what we mean when we're talking about centralized control in these type of situations, that's obviously taken root. I don't think there's any question about that being the way to go long term in terms of efficient scaling and efficient operations. So I assume there's no argument to be made there, and I think that's fine. Let's move on forward. So it sounds like this question still gets resolved. We got either, or, or both. 

                                    And it sounds like the best way to address this obviously is to engage with you guys. And then, as I enjoyed visiting you in St Louis, neither which are you guys are in St. Louis, but you both travel a lot or at least you used to, but this is all stuff that can be online as well, so someone doesn't necessarily have to come out. It doesn't matter where they're located in the world. This is still something that you guys could provide assistance and support for, correct?

Eric Fairfield:                 Correct.

Matt Hilliker:                Absolutely. 

Robb Boyd:                   Excellent. Well guys, thank you so much. I appreciate you weighing in. I do hope we get to get on planes again and get back in front of customers physically, face-to-face, as soon as possible. But let's all stay safe until then. Thank you to our audience. Appreciate you watching. My name is Robb Boyd. Thank you so much. We'll see you on the next one.