(upbeat music) >> Let's kick things off. We're here at Mike Capuano the CMO of Pluribus Networks, and Ami Badani VP of Networking, Marketing, and Developer of Ecosystem at NVIDIA. Great to have you welcome folks. >> Thank you. >> Thanks. >> So let's get into the the problem situation with cloud unified networking. What problems are out there? What challenges do cloud operators have Mike? Let's get into it. >> The challenges that we're looking at are for non hyperscalers that's enterprises, governments Tier 2 service providers, cloud service providers. And the first mandate for them is to become as agile as a hyperscaler. So they need to be able to deploy services and security policies in seconds. They need to be able to abstract the complexity of the network and define things in software while it's accelerated in hardware. Really ultimately they need a single operating model everywhere. And then the second thing is they need to distribute networking and security services out to the edge of the host. We're seeing a growth cyber attacks. It's not slowing down. It's only getting worse and solving for this security problem across clouds is absolutely critical. And the way to do it is to move security out to the host. >> With that goal in mind, what's the Pluribus vision how does this tie together? >> So basically what we see is that this demands a new architecture and that new architecture has four tenets. The first tenet is unified and simplified cloud networks. If you look at cloud networks today, there's sort of like discreet bespoke cloud networks per hypervisor, per private cloud, edge cloud, public cloud. Each of the public clouds have different networks, that needs to be unified. If we want these folks to be able to be agile they need to be able to issue a single command or instantiate a security policy across all of those locations with one command and not have to go to each one. The second is, like I mentioned distributed security. Distributed security without compromise, extended out to the host is absolutely critical. So micro segmentation and distributed firewalls. But it doesn't stop there. They also need pervasive visibility. It's sort of like with security you really can't see you can't protect you can't see. So you need visibility everywhere. The problem is visibility to date has been very expensive. Folks have had to basically build a separate overlay network of taps, packet brokers, tap aggregation infrastructure, that really needs to be built in to this unified network I'm talking about. And the last thing is automation. All of this needs to be SDN enabled. So this is related to my comment about abstraction. Abstract the complexity of all these discreet networks whatever's down there in the physical layer. I don't want to see it. I want to abstract it. I want to define things in software but I do want to leverage the power of hardware to accelerate that. So that's the fourth tenet is SDN automation. >> Mike, we've been talking on theCUBE a lot about this architectural shift and customers are looking at this. This is a big part of everyone who's looking at cloud operations, NextGen. How do we get there? How do customer customers get this vision realized? >> That's a great question. And I appreciate the tee up. We're here today for that reason. We're introducing two things today. The first is a unified cloud networking vision. And that is a vision of where Pluribus is headed with our partners like NVIDIA long term. And that is about deploying a common operating model SDN enabled, SDN automated, hardware accelerated across all clouds. And whether that's underlay and overlay switch or server, any hypervisor infrastructure containers, any workload doesn't matter. So that's ultimately where we want to get. And that's what we talked about earlier. The first step in that vision is what we call the unified cloud fabric. And this is the next generation of our adaptive cloud fabric. And what's nice about this is we're not starting from scratch. We have an award-winning adaptive cloud fabric product that is deployed globally. And in particular, we're very proud of the fact that it's deployed in over 100 Tier 1 mobile operators as the network fabric for their 4G and 5G virtualized cores. We know how to build carrier grade networking infrastructure. What we're doing now to realize this next generation unified cloud fabric is we're extending from the switch to this NVIDIA BlueField-2 DPU. We know there's. >> Hold that up real quick. That's a good prop. That's the BlueField NVIDIA card. >> It's the NVIDIA BlueField-2 DPU, data processing unit. What we're doing fundamentally is extending our SDN automated fabric, the unified cloud fabric, out to the host. But it does take processing power. So we knew that we didn't want to do we didn't want to implement that running on the CPUs which is what some other companies do. Because it consumes revenue generating CPUs from the application. So a DPU is a perfect way to implement this. And we knew that NVIDIA was the leader with this BlueField-2. And so that is the first, that's the first step into getting, into realizing this vision. >> NVIDIA has always been powering some great workloads of GPUs, now you got DPUs. Networking and NVIDIA as here. What is the relationship with Pluribus? How did that come together? Tell us the story. >> We've been working with Pluribus for quite some time. I think the last several months was really when it came to fruition. And what Pluribus is trying to build and what NVIDIA has. So we have, this concept of a blue field data processing unit, which, if you think about it, conceptually does really three things, offload, accelerate, and isolate. So offload your workloads from your CPU to your data processing unit, infrastructure workloads that is. Accelerate, so there's a bunch of acceleration engines. You can run infrastructure workloads much faster than you would otherwise. And then isolation, So you have this nice security isolation between the data processing unit and your other CPU environment. And so you can run completely isolated workloads directly on the data processing unit. So we introduced this, a couple years ago. And with Pluribus we've been talking to the Pluribus team for quite some months now. And I think really the combination of what Pluribus is trying to build, and what they've developed around this unified cloud fabric fits really nicely with the DPU and running that on the DPU and extending it really from your physical switch all the way to your host environment, specifically on the data processing unit. So if you think about what's happening as you add data processing units to your environment. So every server we believe over time is going to have data processing units. So now you'll have to manage that complexity from the physical network layer to the host layer. And so what Pluribus is really trying to do is extending the network fabric from the host from the switch to the host and really have that single pane of glass for network operators to be able to configure, provision, manage all of the complexity of the network environment. So that's really how the partnership truly started. And so it started really with extending the network fabric and now we're also working with them on security. If you sort of take that concept of isolation and security isolation, what Pluribus has within their fabric is the concept of micro segmentation. And so now you can take that extend it to the data processing unit and really have isolated micro segmentation workloads whether it's bare metal, cloud native environments, whether it's virtualized environments, whether it's public cloud, private cloud, hybrid cloud. So it really is a magical partnership between the two companies with their unified cloud fabric running on the DPU. >> You know what I love about this conversation is it reminds me of when you have these changing markets. The product gets pulled out of the market and you guys step up and create these new solutions. And I think this is a great example. So I have to ask you how do you guys differentiate what sets this apart for customers? What's in it for the customer? >> So I mentioned three things in terms of the value of what the BlueField brings. There's offloading, accelerating and isolating. And that's sort of the key core tenets of BlueField. So that, if you sort of think about what BlueField what we've done, in terms of the differentiation. We're really a robust platform for innovation. So we introduced BlueField-2 last year. We're introducing BlueField-3 which is our next generation of blue field. It'll have 5X the ARM compute capacity. It will have 400 gig line rate acceleration, 4X better crypto acceleration. So it will be remarkably better than the previous generation. And we'll continue to innovate and add, chips to our portfolio every 18 months to two years. So that's sort of one of the key areas of differentiation. The other is that if you look at NVIDIA, what we're sort of known for is really known for our AI, our artificial intelligence and our artificial intelligence software, as well as our GPU. So you look at artificial intelligence and the combination of artificial intelligence plus data processing. This really creates faster, more efficient secure AI systems from, the core of your data center, all the way out to the edge. And so with NVIDIA we really have these converged accelerators where we've combined the GPU, which does all your AI processing with your data processing with the DPU. So we have this convergence really nice convergence of that area. And I would say the third area is really around our developer environment. One of the key, one of our key motivations at NVIDIA is really to have our partner ecosystem embrace our technology and build solutions around our technology. So if you look at what we've done with the DPU we've created an SDK, which is an open SDK called DOCA. And it's an open SDK for our partners to really build and develop solutions using BlueField and using all these accelerated libraries that we expose through DOCA. And so part of our differentiation is really building this open ecosystem for our partners to take advantage and build solutions around our technology. >> What's exciting is when I hear you talk it's like you realize that there's no one general purpose network anymore. Everyone has their own super environment, super cloud or these new capabilities. They can really craft their own I'd say custom environment at scale with easy tools. And it's all kind of that again this is the new architecture Mike, you were talking about. How does customers run this effectively, cost effectively? And how do people migrate? >> I think that is the key question. So we've got this beautiful architecture. Amazon Nitro is a good example of a SmartNIC architecture that has been successfully deployed but, enterprises and Tier 2 service providers and Tier 1 service providers and governments are not Amazon. So they need to migrate there and they need this architecture to be cost of effective. And that's super key. I mean, the reality is DPU are moving fast but they're not going to be deployed everywhere on day one. Some servers will have have DPUs right away. Some servers will have DPUs in a year or two. And then there are devices that may never have DPUs. IOT gateways, or legacy servers, even mainframes. So that's the beauty of a solution that creates a fabric across both the switch and the DPU. And by leveraging the NVIDIA BlueField DPU what we really like about it is, it's open and that drives cost efficiencies. And then, with this our architectural approach effectively you get a unified solution across switch and DPU, workload independent. It doesn't matter what hypervisor it is. Integrated visibility, integrated security and that can create tremendous cost efficiencies and really extract a lot of the expense from a capital perspective out of the network as well as from an operational perspective because now I have an SDN automated solution where I'm literally issuing a command to deploy a network service, or to deploy a security policy and is deployed everywhere automatically saving the network operations team and the security operations team time. >> So let me rewind that 'cause that's super important. Got the unified cloud architecture. I'm the customer, it's implemented. What's the value again, take me through the value to me. I have a unified environment. What's the value? >> I mean the value is effectively, there's a few pieces of value. The first piece of value is I'm creating this clean demark. I'm taking networking to the host. And like I mentioned, we're not running it on the CPU. So in implementations that run networking on the CPU there's some conflict between the DevOps team who own the server, and the NetOps team who own the network because they're installing software on the CPU stealing cycles from what should be revenue generating CPUs. So now by terminating the networking on the DPU we create this real clean demark. So the DevOps folks are happy because they don't necessarily have the skills to manage network and they don't necessarily want to spend the time managing networking. They've got their network counterparts who are also happy the NetOps team because they want to control the networking. And now we've got this clean demark where the DevOps folks get the services they need and the NetOps folks get the control and agility they need. So that's a huge value. The next piece of value is distributed security. This is essential I mentioned it earlier, pushing out micro segmentation and distributed firewall basically at the application level, where I create these small segments on an application by application basis. So if a bad actor does penetrate the perimeter firewall they're contained once they get inside. 'Cause the worst thing is a bad actor penetrates perimeter firewall and can go wherever they want in wreak havoc. And so that's why this is so essential. And the next benefit obviously is this unified networking operating model. Having an operating model across switch and server, underlay and overlay, workload agnostic, making the life of the NetOps teams much easier so they can focus their time on really strategy instead of spending an afternoon deploying a single VLAN for example. >> Awesome, and I think also for my stand point I mean perimeter security is pretty much, that out there, I guess the firewall still out there exists but pretty much they're being breached all the time the perimeter. You have to have this new security model. And I think the other thing that you mentioned the separation between DevOps is cool because the infrastructure is code is about making the developers be agile and build security in from day one. So this policy aspect is huge new control plan. I think you guys have a new architecture that enables the security to be handled more flexible. That seems to be the killer feature here. >> If you look at the data processing unit, I think one of the great things about sort of this new architecture it's really the foundation for zero trust. So like you talked about the perimeter is getting breached. And so now each and every compute node has to be protected. And I think that's sort of what you see with the partnership between Pluribus and NVIDIA is the DPU is really the foundation of zero trust and Pluribus is really building on that vision with allowing sort of micro-segmentation and being able to protect each and every compute node as well as the underlying network. >> This is super exciting. This is illustration of how the market's evolving architectures are being reshaped and refactored for cloud scale and all this new goodness with data. So I got to ask how you guys go into market together. Michael, start with you. What's the relationship look like in the go to market with NVIDIA? >> We're super excited about the partnership. Obviously we're here together. We think we've got a really good solution for the market so we're jointly marketing it. Obviously we appreciate that NVIDIA's open that's sort of in our DNA, we're about a open networking. They've got other ISVs who are going to run on BlueField-2. We're probably going to run on other DPUs in the future. But right now we feel like we're partnered with the number one provider of DPUs in the world and super excited about making a splash with it. >> Oh man NVIDIA got the hot product. >> So BlueField-2 as I mentioned was GA last year, we're introducing, well we now also have the converged accelerator. So I talked about artificial intelligence our artificial intelligence software with the BlueField DPU, all of that put together on a converged accelerator. The nice thing there is you can either run those workloads, so if you have an artificial intelligence workload and an infrastructure workload, you can work on them separately on the same platform or you can actually use you can actually run artificial intelligence applications on the BlueField itself. So that's what the converged accelerator really brings to the table. So that's available now. Then we have BlueField-3 which will be available late this year. And I talked about sort of, how much better that next generation of BlueField is in comparison to BlueField-2. So we'll see BlueField-3 shipping later on this year. And then our software stack which I talked about, which is called DOCA. We're on our second version, our DOCA 1.2 we're releasing DOCA 1.3 in about two months from now. And so that's really our open ecosystem framework. So allow you to program the BlueField. So we have all of our acceleration libraries, security libraries, that's all packed into this SDK called DOCA. And it really gives that simplicity to our partners to be able to develop on top of BlueField. So as we add new generations of BlueField, next year we'll have another version and so on and so forth. DOCA is really that unified layer that allows BlueField to be both forwards compatible and backwards compatible. So partners only really have to think about writing to that SDK once. And then it automatically works with future generations of BlueField. So that's sort of the nice thing around DOCA. And then in terms of our go to market model we're working with every major OEM. Later on this year you'll see, major server manufacturers releasing BlueField enabled servers, so more to come. >> Awesome, save money, make it easier, more capabilities, more workload power. This is the future of cloud operations. >> And one thing I'll add is we are, we have a number of customers as you'll hear in the next segment that are already signed up and will be working with us for our early field trial starting late April early May. We are accepting registrations. You can go to www.pluribusnetworks.com/eft. If you're interested in signing up for being part of our field trial and providing feedback on the product >> Awesome innovation and networking. Thanks so much for sharing the news. Really appreciate, thanks so much. In a moment we'll be back to look deeper in the product the integration, security, zero trust use cases. You're watching theCUBE, the leader in enterprise tech coverage. (upbeat music)

(upbeat music) >> Okay, we're back. I'm John Furrier with theCUBE and we're going to go deeper into a deep dive into unified cloud networking solution from Pluribus and NVIDIA. And we'll examine some of the use cases with Alessandro Barbieri, VP of product management at Pluribus Networks and Pete Lumbis, the director of technical marketing and video remotely. Guys thanks for coming on, appreciate it. >> Yeah thanks a lot. >> I'm happy to be here. >> So a deep dive, let's get into the what and how. Alessandro, we heard earlier about the Pluribus and NVIDIA partnership and the solution you're working together in. What is it? >> Yeah, first let's talk about the what. What are we really integrating with the NVIDIA BlueField the DPU technology? Pluribus has been shipping in volume in multiple mission critical networks, this Netvisor ONE network operating systems. It runs today on merchant silicon switches and effectively it's standard based open network operating system for data center. And the novelty about this operating system is that it integrates distributed the control plane to automate effect with SDN overlay. This automation is completely open and interoperable and extensible to other type of clouds. It's not enclosed. And this is actually what we're now porting to the NVIDIA DPU. >> Awesome, so how does it integrate into NVIDIA hardware and specifically how is Pluribus integrating its software with the NVIDIA hardware? >> Yeah, I think we leverage some of the interesting properties of the BlueField DPU hardware which allows actually to integrate our network operating system in a manner which is completely isolated and independent from the guest operating system. So the first byproduct of this approach is that whatever we do at the network level on the DPU card is completely agnostic to the hypervisor layer or OS layer running on the host. Even more, we can also independently manage this network node this switch on a NIC effectively, managed completely independently from the host. You don't have to go through the network operating system running on X86 to control this network node. So you truly have the experience effectively top of rack for virtual machine or a top of rack for Kubernetes spots, where if you allow me with analogy, instead of connecting a server NIC directly to a switchboard, now we are connecting a VM virtual interface to a virtual interface on the switch on an niche. And also as part of this integration, we put a lot of effort, a lot of emphasis in accelerating the entire data plan for networking and security. So we are taking advantage of the NVIDIA DOCA API to program the accelerators. And these you accomplish two things with that. Number one, you have much better performance. They're running the same network services on an X86 CPU. And second, this gives you the ability to free up I would say around 20, 25% of the server capacity to be devoted either to additional workloads to run your cloud applications or perhaps you can actually shrink the power footprint and compute footprint of your data center by 20% if you want to run the same number of compute workloads. So great efficiencies in the overall approach. >> And this is completely independent of the server CPU, right? >> Absolutely, there is zero code from Pluribus running on the X86. And this is why we think this enables a very clean demarcation between compute and network. >> So Pete, I got to get you in here. We heard that the DPU enable cleaner separation of DevOps and NetOps. Can you explain why that's important because everyone's talking DevSecOps, right? Now, you've got NetSecOps. This separation, why is this clean separation important? >> Yeah, I think, it's a pragmatic solution in my opinion. We wish the world was all kind of rainbows and unicorns, but it's a little messier than that. I think a lot of the DevOps stuff and that mentality and philosophy. There's a natural fit there. You have applications running on servers. So you're talking about developers with those applications integrating with the operators of those servers. Well, the network has always been this other thing and the network operators have always had a very different approach to things than compute operators. And I think that we in the networking industry have gotten closer together but there's still a gap, there's still some distance. And I think that distance isn't going to be closed and so, again, it comes down to pragmatism. And I think one of my favorite phrases is look, good fences make good neighbors. And that's what this is. >> Yeah, and it's a great point 'cause DevOps has become kind of the calling car for cloud, right? But DevOps is a simply infrastructures code and infrastructure is networking, right? So if infrastructure is code you're talking about that part of the stack under the covers, under the hood if you will. This is super important distinction and this is where the innovation is. Can you elaborate on how you see that because this is really where the action is right now? >> Yeah, exactly. And I think that's where one from the policy, the security, the zero trust aspect of this, right? If you get it wrong on that network side, all of a sudden you can totally open up those capabilities. And so security's part of that. But the other part is thinking about this at scale, right? So we're taking one top of rack switch and adding up to 48 servers per rack. And so that ability to automate, orchestrate and manage its scale becomes absolutely critical. >> Alessandro, this is really the why we're talking about here and this is scale. And again, getting it right. If you don't get it right, you're going to be really kind of up you know what? So this is a huge deal. Networking matters, security matters, automation matters, DevOps, NetOps, all coming together clean separation. Help us understand how this joint solution with NVIDIA fits into the Pluribus unified cloud networking vision because this is what people are talking about and working on right now. >> Yeah, absolutely. So I think here with this solution we're attacking two major problems in cloud networking. One, is operation of cloud networking and the second, is distributing security services in the cloud infrastructure. First, let me talk about first what are we really unifying? If we're unifying something, something must be at least fragmented or disjointed. And what is disjointed is actually the network in the cloud. If you look wholistically how networking is deployed in the cloud, you have your physical fabric infrastructure, right? Your switches and routers. You build your IP clause, fabric leaf and spine topologies. This is actually a well understood problem I would say. There are multiple vendors with let's say similar technologies, very well standardized, very well understood and almost a commodity I would say building an IP fabric these days, but this is not the place where you deploy most of your services in the cloud particularly from a security standpoint. Those services are actually now moved into the compute layer where cloud builders have to instrument a separate network virtualization layer where they deploy segmentation and security closer to the workloads. And this is where the complication arise. This high value part of the cloud network is where you have a plethora of options that they don't talk to each other and they're very dependent on the kind of hypervisor or compute solution you choose. For example, the networking API between an ESXi environment or an Hyper-V or a Zen are completely disjointed. You have multiple orchestration layers. And then when you throw in also Kubernetes in this type of architecture, you are introducing yet another level of networking. And when Kubernetes runs on top of VMs which is a prevalent approach, you actually are stuck in multiple networks on the compute layer that they eventually ran on the physical fabric infrastructure. Those are all ships in the knights effectively, right? They operate as completely disjointed and we're trying to tackle this problem first with the notion of a unified fabric which is independent from any workloads whether this fabric spans on a switch which can be connected to bare metal workload or can span all the way inside the DPU where you have your multi hypervisor compute environment. It's one API, one common network control plane and one common set of segmentation services for the network. That's problem number one. >> It's interesting I hear you talking and I hear one network among different operating models. Reminds me of the old serverless days. There's still servers but they call it serverless. Is there going to be a term network-less because at the end of the day it should be one network, not multiple operating models. This is a problem that you guys are working on, is that right? I'm just joking serverless and network-less, but the idea is it should be one thing. >> Yeah, effectively what we're trying to do is we're trying to recompose this fragmentation in terms of network cooperation across physical networking and server networking. Server networking is where the majority of the problems are because as much as you have standardized the ways of building physical networks and cloud fabrics with IP protocols and internet, you don't have that sort of operational efficiency at the server layer. And this is what we're trying to attack first with this technology. The second aspect we're trying to attack is how we distribute security services throughout the infrastructure more efficiently whether it's micro-segmentation is a stateful firewall services or even encryption. Those are all capabilities enabled by the BlueField DPU technology. And we can actually integrate those capabilities directly into the network fabric limiting dramatically at least for east west traffic the sprawl of security appliances whether virtual or physical. That is typically the way people today segment and secure the traffic in the cloud. >> Awesome. Pete, all kidding aside about network-less and serverless kind of fun play on words there, the network is one thing it's basically distributed computing, right? So I'd love to get your thoughts about this distributed security with zero trust as the driver for this architecture you guys are doing. Can you share in more detail the depth of why DPU based approach is better than alternatives? >> Yeah, I think what's beautiful and kind of what the DPU brings that's new to this model is completely isolated compute environment inside. So it's the, yo dog, I heard you like a server so I put a server inside your server. And so we provide ARM CPUs, memory and network accelerators inside and that is completely isolated from the host. The actual X86 host just thinks it has a regular niche in there, but you actually have this full control plane thing. It's just like taking your top of rack switch and shoving it inside of your compute node. And so you have not only this separation within the data plane, but you have this complete control plane separation so you have this element that the network team can now control and manage, but we're taking all of the functions we used to do at the top of rack switch and we're distributing them now. And as time has gone on we've struggled to put more and more and more into that network edge. And the reality is the network edge is the compute layer, not the top of rack switch layer. And so that provides this phenomenal enforcement point for security and policy. And I think outside of today's solutions around virtual firewalls, the other option is centralized appliances. And even if you can get one that can scale large enough, the question is, can you afford it? And so what we end up doing is we kind of hope that NVIDIA's good enough or we hope that the VXLAN tunnel's good enough. And we can't actually apply more advanced techniques there because we can't financially afford that appliance to see all of the traffic. And now that we have a distributed model with this accelerator, we could do it. >> So what's in it for the customer real quick and I think this is an interesting point you mentioned policy. Everyone in networking knows policy is just a great thing. And as you hear it being talked about up the stack as well when you start getting to orchestrating microservices and whatnot all that good stuff going on there, containers and whatnot and modern applications. What's the benefit to the customers with this approach because what I heard was more scale, more edge, deployment flexibility relative to security policies and application enablement? What's the customer get out of this architecture? What's the enablement? >> It comes down to taking again the capabilities that we're in that top of rack switch and distributing them down. So that makes simplicity smaller, blast radius' for failures smaller failure domains, maintenance on the networks and the systems become easier. Your ability to integrate across workloads becomes infinitely easier. And again, we always want to kind of separate each one of those layers so just as in say a VXLAN network, my leaf in spine don't have to be tightly coupled together. I can now do this at a different layer and so you can run a DPU with any networking in the core there. And so you get this extreme flexibility. You can start small, you can scale large. To me the possibilities are endless. >> It's a great security control plan. Really flexibility is key and also being situationally aware of any kind of threats or new vectors or whatever's happening in the network. Alessandro, this is huge upside, right? You've already identified some successes with some customers on your early field trials. What are they doing and why are they attracted to the solution? >> Yeah, I think the response from customer has been the most encouraging and exciting for us to sort of continue and work and develop this product. And we have actually learned a lot in the process. We talked to tier two, tier three cloud providers. We talked to SP, Soft Telco type of networks as well as inter large enterprise customers. In one particular case one, let me call out a couple of examples here just to give you a flavor. There is a cloud provider in Asia who is actually managing a cloud where they're offering services based on multiple hypervisors. They are native services based on Zen, but they also on ramp into the cloud workloads based on ESXi and KVM depending on what the customer picks from the menu. And they have the problem of now orchestrating through their orchestrate or integrating with Zen center, with vSphere, with OpenStack to coordinate this multiple environments. And in the process to provide security, they actually deploy virtual appliances everywhere which has a lot of cost complication and eats up into the server CPU. The promise that they saw in this technology, they call it actually game changing is actually to remove all this complexity, having a single network and distribute the micro segmentation service directly into the fabric. And overall they're hoping to get out it tremendous OPEX benefit and overall operational simplification for the cloud infrastructure. That's one important use case. Another global enterprise customer is running both ESXi and Hyper-V environment and they don't have a solution to do micro segmentation consistently across hypervisors. So again, micro segmentation is a huge driver security. Looks like it's a recurring theme talking to most of these customers. And in the Telco space, we're working with few Telco customers on the CFT program where the main goal is actually to harmonize network cooperation. They typically handle all the VNFs with their own homegrown DPDK stack. This is overly complex. It is frankly also slow and inefficient. And then they have a physical network to manage. The idea of having again one network to coordinate the provisioning of cloud services between the Telco VNFs and the rest of the infrastructure is extremely powerful on top of the offloading capability opted by the BlueField DPUs. Those are just some examples. >> That was a great use case. A lot more potential I see that with the unified cloud networking, great stuff, Pete, shout out to you 'cause at NVIDIA we've been following your success us for a long time and continuing to innovate as cloud scales and Pluribus with unified networking kind of bring it to the next level. Great stuff, great to have you guys on and again, software keeps driving the innovation and again, networking is just a part of it and it's the key solution. So I got to ask both of you to wrap this up. How can cloud operators who are interested in this new architecture and solution learn more because this is an architectural shift? People are working on this problem, they're try to think about multiple clouds, they're try to think about unification around the network and giving more security, more flexibility to their teams. How can people learn more? >> Yeah, so Alessandro and I have a talk at the upcoming NVIDIA GTC conference. So it's the week of March 21st through 24th. You can go and register for free nvidia.com/gtc. You can also watch recorded sessions if you end up watching this on YouTube a little bit after the fact. And we're going to dive a little bit more into the specifics and the details and what we're providing in the solution. >> Alessandro, how can we people learn more? >> Yeah, absolutely. People can go to the Pluribus website, www.pluribusnetworks.com/eft and they can fill up the form and they will contact Pluribus to either know more or to know more and actually to sign up for the actual early field trial program which starts at the end of April. >> Okay, well, we'll leave it there. Thank you both for joining, appreciate it. Up next you're going to hear an independent analyst perspective and review some of the research from the enterprise strategy group ESG. I'm John Furrier with theCUBE, thanks for watching. (upbeat music)

(fastpaced upbeat music) >> Welcome back to theCubes coverage of the power of N and the collaborations between HPE Aruba and Pensando. Where the two companies are setting out to create a new category in network switching. Joining me now is Simon McCormack, who looks after product management at HPE Aruba. Welcome Simon. Good to see you. >> Good morning. Thanks for having me today. >> You're very welcome. So Simon, we've been talking all day about the Aruba switching fabric that you're bringing to market, embedding the Pensando technology. Can you tell us what's the primary value prop that AFC brings to its customers? >> Sure. Aruba Fabric Composer. This is orchestration and management for the Aruba wide switching platform. Primarily for data centers. It does a lot of things. I'll give you three key ones just to get a feel for it. So in data center networking, there's a lot of complex technologies. I'm afraid to say, lease spines, overlays, underlays, EDP and OSPF BGP. I can throw out loads of acronyms for you. Fabric Composer can really simplify through a bunch of intent based workflows, the deployment and management of these fabrics. We can do it either interactively through a UI or fully API driven, if you want to. So it really takes away a lot of the plexity there makes it dead easy to deploy these and that scale. Number two, in a data center, a lot of compute storage hypervisor technologies that you have to interact with the THEO network products. So in Fabric Composer, we built an integration layer into it that interacts with other orchestrators, vCenter, VMware vcenter is a good example of that. So an operator may make changes to vCenter that affect the network. You don't want to call the network team for it. Fabric Composer can automate that network side configuration on the Aruba switch, making your day to operations, insertion of new services, much more simpler. And then finally, number three, because we've got all these capabilities I've just told you about. We actually have a great typology model that we build from it. And we can use that to visualize this virtual to physical network layer that is really powerful for troubleshooting the environment. >> Great? So three things, actually four right. To simplify or integrate and automate. And it's kind of two and two way, I'm going to to call it. and then the visualization piece for troubleshooting. Awesome. What about security policy? How are you thinking about that in this release? >> Yeah, so that's where in this release, we're extending it with the Pensando PSM technologies embedded into the 10K. Now we can use Aruba Fabric Composer to actually orchestrate the policy in addition to the network. So you think about today, Fabric Composer does network primarily. You bring policy into it. You've got one single pane of glass now that does network and policy. It actually provides a really powerful capabilities for operators of different skill sets to be able to manage and orchestrate this environment. >> What about the sort of operational model as it pertains to the network and security, I'm interested in how flexible that is. For instance, if a customer wants to use their own tooling or operational frameworks. What if they want to leverage multi-vendor fabrics like a third-party spine? How do you deal with all of that? >> Yeah, and I think that's, we built that into essentially the DNA of this technology is that we're, we're expecting to often go into brownfield environments. Where they've already got best practices for security and networking. They've already got networking vendors there. The 10K is a very powerful lease switch on its own. We want those lease switches to go in all of these different environments, not just Greenfield. It's really great for Greenfield. And I'm going to explain this a little bit in a few ways. First of all, the technology we have with Aruba fabric Composer and Pensando PSM, you can do a pure operational split between them SecOps, NetOps. A lot of customers that's how they deal with it. They've got the security operations team, network operations team. If they're split, you can use the two tools and make a fantastic product using that. However, if they're not split, and you've got a single policy for it. You can use Aruba Fabric Composer to do both of them. So you've got the options there and we fully embrace that in the architecture of what we built. This extends to multiple layers for the technology build as well. Again, as I said, the 10K's is a lease switch, it can connect to third-party spines. So you could use Fabric Composer to manage this lease Spitch and the policy you could use Fabric Composer just to manage the least switch and connect and interoperate the lease to the spine, or you can do a full Aruba solution, the full Aruba spine and use that operating model. There's one final thing in this area is fabric Composers are a UI based orchestrator, API driven. Some customers love it. Some customers love their CLIs. We fully embrace the operational model where customers still use their own APIs and their own CLIs. So the customer may be using Ansible to automate through API. They can still use that directly to the switch and they can use it to AFC and mix the two. If you talk directly to a switch and change it, Fabric Composer detects it and basically sinks its configuration together. So we can insert all or any part of this solution into existing or new Netflix. >> Yeah, that's nice. Right? Because I mean, so there's the network hard guys, right they, they want that CLI access. So you you're accommodating that. And then as well, being able to bring those SecOps view and the netOps view together is important because let's say, let's face it. A lot of organizations, especially some of the smaller ones, they don't actually have a full blown SecOps team. That's really the netOps responsibility. And so that's nice flexibility, you can handle both worlds. How about segmentation? What a customer is telling you that they want regarding segmentation and how are you guys approaching that? >> Yeah, I mean, it's, it's actually a key feature of what we're doing in this area. Now the iland segmentation generates it's kind of a wide area with many layers to it and we could talk about it for hours. So let me talk briefly about some of the areas we're going into when it comes to the segmentation. But particularly of a compute and virtual type environment. So when you, when you're typically creating policies in today's world, current policies based on addresses, IP addresses, or Mac addresses. You have lots of rules and big lists of addresses. It's really annoying. Customers generally don't talk in addresses. They talk in machines and names of machines. So if you think about what I've already told you with the Fabric Composer, we've already got these hooks in the compute hypervisor layer. So we didn't know about the virtual machines? So it said obviously, a natural extension now for you to be able to create these policies based on the machines. So there's, there's a scale problem in policy distribution at two levels, at the top and the bottom. The top level is your chronic create the policy. You've got this massive distribution addresses. So Fabric Composer can really help you by allowing you to then create these groups, sensible groups, using the names then you can distribute. The 10K solution with the distributed architecture of the bottom layer, now allows us to distribute these policies and rules across your racks within your data center. So it scales really well, but that's one level I've described. You know, you're creating groups of machines with names, so it's easier to define it, but there's auto and automation angle to this as well. You might not want to even create it interactively. Now a lot of customers with VMware vCenter, For example, are tagging the virtual machines. So the tag tells you a group information. Again, Fabric Composer can already get the tag within its database model. So we can use the tag now either to fully automate or use as a hint to creating these groups. So now I've got a really simple way to basically just categorize my machines into the groups so that now I can push rules down onto them. And there's one, one final thing that I just want to tell you before, before we move on. There's, there's often a zero trust model you want to do in the data center for segmentation. Meaning I've got two virtual machines on the same network on the same host. Normally they can talk to each other, nothing's stopping them, but sometimes you want to isolate even those two. You can do it in products like vCenter with PV land technologies. A bit cumbersome to configure on the vSphere side, you got to match it with what you see on the switch side. It's one of those that's a real headache, unless you've got an orchestrator to do it. So Fabric Composer could basically orchestrate this isolated solution. You're now grouping your machines and you're saying they're isolated. We can do the smarts and both of the vCenter side and the switch side, get them in sync, get it all configured. And now the masses can start to do this kind of segmentation at scale. >> Got it. Thank you Simon. Can the Fabric Composer kind of be used as the primary prism for troubleshooting? How do you handle troubleshooting and this art combined architecture? Who, who do I call when there's a problem? How do you approach that? >> Well, definitely start by calling me or actually call my product first, so fabric Composer. If you're using it, use that as the front tool for what you're going to try and figure out what's going on. There is a global health dashboard. It encompasses networking security policy across the solution, across the fabric. So that's your, tells you what's going on immediately. Down to port stats on what's happening within the physical topology of the network. Down to the end-to-end view, we have in terms of policy connectivity between machines. So Fabric Composer is your first port of call, but we built a solution here that we don't want to hide the pieces underneath it. Any networking guy knows when they're deep troubleshooting networking stuff, they're going to end up with the switch. So you started the orchestrator, but sometimes in the deep troubleshooting, not day-to-day, hopefully. You'll go to the switch and you'll troubleshoot that way. We've got the same technology here with the policy, with the firewall rules, with Pensando PSM. We still fully embrace for deep troubleshooting, go to Pensando PSM. They have really advanced tools in their bag of tricks in the product to give you advanced troubleshooting down to the policy layer. They have a really powerful firewall log capability, where you can search and sort, and see exactly what role is allowing or stopping any traffic going through the environment. And the two orchestrated model, we really like it 'cause it scales really well. It allows Fabric Composer to remain lightweight, PSM focused on the policy orchestration bit. But again, if your that customer that wants to do single pane of glass use Fabric Composer for the standard day-to-day stuff. But you've got the tools there to do the advanced troubleshooting between the different elements that we have within the Pensando and the Aruba tools. >> Yeah, really well thought out. You got the simplification angle nailed, the integration automation we talked about that, the visualization and the topology map, zero trust. And then remediation with deep^ened inspection. Simon, thanks so much for taking us through the announcements. Really appreciate your insights and time today. >> Thank you very much. >> You're welcome. Okay. Keep it right there, this is Dave Vellante for theCube. More content from the HPE Aruba Pensando announcements coming right up. (soothing music)

(intro music playing) >> Hello everyone, and welcome to the power of n where HPE Aruba and Pensando are changing the game, the way customers scale with the cloud, and what's next in the evolution in switching. Hey everyone, I'm John furrier with the cube, and I'm here with Shane Corbin, director of technical product management at Pensando, and William show vice president of product management, Aruba HPE. Gentlemen, thank you for coming on and doing a deep dive and, and going into the, the big news. So the first question I want to ask you guys is um, what do you guys see from a market customer perspective that kicked this project off? um, amazing um, results um, over the past year or so? Where did it all come from? >> No, it's a great question, John. So when we were doing our homework, there were actually three very clear customer challenges. First, security threats were largely spawn with on, within the perimeter. In fact, Forrester highlighted 80% of threats originate within the internal network. Secondly, workloads are largely distributed creating a ton of east-west traffic. And then lastly, network services such as firewalls, load balancers, VPN aggregators are expensive, they're centralized, and they ultimately result in service chaining complexity. >> John: So, so, >> John: Go ahead, Shane. >> Yeah. Additionally, when we spoke to our customers after launching initially the distributed services platform, these compliance challenges clearly became apparent to us and while they saw the architecture value of adopting what the largest public cloud providers have done by putting a smart NIC in each compute node to provide these stateful services. Enterprise customers were still, were struggling with the need to upgrade fleets and brown field servers and the associated per node cost of adding a smart NIC to every compute node. Typically the traffic volumes for on a per node basis within an enterprise data center are significantly lower than cloud. Thus, we saw an opportunity here to, in conjunction with Aruba, develop a new category of switching product um, to share the processing capabilities of our unique intellectual property around our DPU across a rack of servers that net net delivers the same set of services through a new category of platform, enabling a distributed services architecture, and ultimately addressing the compliance and TCO generating huge TCO and ROI for customers. >> You know, one of the things that we've been reporting on with you guys, as well as the cloud scale, this is the volume of data and just the performance and scale. I think the timing of the, of this partnership and the product development is right on point. And you've got the edge right around the corner, more, more distributed nature of cloud operations, huge, huge change in the marketplace. So great timing on the origination story there. Great stuff. Tell me more about the platform itself, the details, what's under the hood, the hardware OS, what are the specs? >> Yeah, so we started with a very familiar premise. Rubik customers are already leveraging CX with an edge to cloud common operating model, in deploying leaf and spine networks. Plus we're excited to introduce the industry's first distributed services switch, where the first configuration has 48-25 gig ports with a hundred gig couplings running Aruba CX cloud native operating system, Pensando Asic's software inside, enabling layer four through six, seven stateful services. Shane, do you want to elaborate on. >> Yeah, let me elaborate on that a little bit further, um, you know, as we spoke existing platforms and how customers were seeking to address these challenges were, are inherently limited by the ASIC dye size, and that does limit their scale and performance and ability in traditional switching platforms to deliver truly stateful functions in, in, in a switching platform, this was, you know, architecturally from the ground up, when we developed our DPU, first and second generation, we delivered it, or we, we built it with stateful services in mind from the get-go, we leveraged the clean state design with our P four program with DPU. We evolved to our seven nanometers based pro DPU right now, which is essentially enabling software and Silicon. And this has generated a new level of performance scale, flexibility and capability in terms of services. This serves as the foundation for our 200 gig card, were we taking the largest cloud providers into production for. And the DPU itself is, is designed inherently to process stage, track stateful connections, and stateful flow is at very, very large scale without impacting performance. And in fact, the two of these DPU components server disk, services foundation of the CX 10 K, and this is how we enable stateful functions in a switching platform functions like stateful network fire-walling, stateful segmentation, enhanced programmable telemetry, which we believe will bring a whole lot of value to our customers. And this is a platform that's inherently programmable from the ground up. We can, we can build and leverage this platform to build new use cases around encryption, enabling stateful load balancing, stateful NAT to name a few, but, but the key message here is, this is, this is a platform with the next generation of architecture's in mind, is programmed, but at all, there's the stack, and that's what makes it fundamentally different than anything else. >> I want to just double click on that if you don't mind, before we get to the competitive question, because I think you brought up the state thing. I think this is worth calling out, if you guys don't mind commenting more on this states issue, because this is big. Cloud native developers right now, want speed, they're shifting left at the CICD pipeline with programmability. So going down and having the programmability, and having state is a really big deal. Can you guys just expand on that a little bit more and why it's important and, and how hard it really is to pull off? >> I, I can start, I guess, um, it's very hard to pull off because of the sheer amount of connections you need to track when you're developing something like a stateful firewall or a stateful load balancer, a key component of that is managing the connections at very, very large scale and understanding what's happening with those connections at scale, without impacting application performance. And this is fundamentally different at traditional switching platform, regardless of how it's deployed today in Asics, don't typically process and manage state like this. Um, memory resources within the chip aren't sufficient, um, the policy scale that you can um, implement on a platform aren't sufficient to address and fundamentally enable deployable firewalling, or load balancing, or other stateful services. >> That's exactly right. And so the other kind of key point here is that, if you think about the sophistication of different security threats, it does really require you to be able to look at the entire packet, and, and more so be able to look at the entire flow and be able to log that history, so that you can get much better heuristics around different anomalies, security threats that are emerging today. >> That's a great, great point. Thanks for, for, um, bringing that extra, extra point out. I would just add to this, we're reporting this all the time on Silicon angle in the cube is that, you know, the, you know, the, the automation wave that's coming with around data, you know, it's a center of data, not data centers we heard earlier on with the, in, in, in the presentation. Data drives automation, having that enabled with the state is a real big deal. So, I think that's really worth calling out. Now, I've got to ask the competition question, how is this different? I mean, this is an evolution. I would say, it's a revolution. You guys are being being humble, um, but how is this different from what customers can deploy today? >> Architecturally, if you take a look at it. We've, we've spoken about the technology and fundamentally in the platform what's unique, in the architecture, but, foundationally when customers deploy stateful services they're typically deployed leveraging traditional big box appliances for east-west our workload based agents, which seek to implement stateful security for each east-west. Architecturally what we're enabling is stateful services like firewalling, segmentation, can scale with the fabric and are delivered at the optimal point for east west which is through leaf for access layer of the network. And we do this for any type of workload. Be it deployed on a virtualized compute node, be a deployed on a containerized worker node, be deployed on bare metal, agnostic up typology, it can be in the access layer of a three tier design and a data center. It can be in the leaf layer of a VX VPN based fabric, but the goal is an all centrally managed to a single point of orchestration and control of which William will talk about shortly. The goal of this is to drive down the TCO of your data center as a whole, by allowing you to retire legacy appliances that are deployed in an east-west roll, and not utilize host based agents, and thus save a whole lot of money and we've modeled on the order of 60 to 70% in terms of savings in terms of the traditional data center pod design of a thousand compute nodes which we'll be publishing. And as, as we go forward additional services, as we mentioned, like encryption, this platform has the capability to terminate up to 800 gigs of our line rates encryption, IP sec, VPN per platform, stateful Nat load balancing, and this is all functionality we'll be adding to this existing platform because it's programmable as we've mentioned from the ground up. >> What are some of the use cases lead? And what's the top use cases, what's the low hanging fruit and where does this go? You've got service providers, enterprises. What are the types of customers you guys see implementing? >> Yeah, that's, what's really exciting about the CX 10,000. We actually see customer interest from all types of different markets, whether it be higher education, service providers to financial services, basically all enterprises verticals with private cloud or edge data centers. For example, it could be a hospital, a big box retailer, or a colon such as Iniquinate So it's really the CX 10,000 that creates a new switching category, enabling stateful services in that leaf node right at the workload, unifying network and security automation policy management. Second, the CX 10,000 greatly improves security posture and eliminates the need for hair-pinning east-west traffic all the way back to the centralized deployments. Lastly, As Shane highlighted, there's a 70% TCO savings by eliminating that appliance sprawl and ultimately collapsing the network security operations. >> I love the category creation um, vibe here. Love it. And also the technical and the cloud alignment's great. But how do the customers manage all this? Okay, I got a new category. I just put the box in, throw away some other ones? I mean, how does this all get done? And how does the customers manage all this? >> Yeah, so we're, we're looking to build on top of the river fabric composer. It's another familiar site for our customers, and what's already provides for compute storage and network automation, with a broad ecosystem integrations, such as VMware vSphere Vcenter as with Nutanix prism and so aligned with the CX 10,000 FGA, now you have a fabric composer, unified security and policy orchestration, and management with the ability to find firewall policies efficiently and provide that telemetry to collect your such a Splunk. >> John: So the customer environments right now involve a lot of multi-vendor and new frameworks, obviously, cloud native. How does this fit into the customer's existing environment with the ecosystem? How do they get, get going here? >> Yeah, great question. Um, Our customers can get going as we, we've built a flexible platform that can be deployed in either Greenfield or brownfield. Obviously it's a best of breed architecture for distributed services we're building in conjunction with Aruba. But if customers want to gradually integrate this into their existing environments and they're using other vendors, spines or cores, this can be inserted seamlessly as, as a lead for an access, access tier switch to deliver the exact same set of services within that architecture. So it plugs seamlessly in because it supports all the standard control plan protocols, a VX 90 VPN, and a traditional attitude, three tier designs easily. Now, for any enterprise solution deployment, it's critical that you build a holistic ecosystem around it. It's clear that, this will get customer deployments and the ecosystem being diverse and rich is very, very important. And as part of our integrations with the controller, we're building a broad suite of integrations across threat detection, application dependency mapping, Siemens sooam, dev ops infrastructure as code tools. (inaudible) And it's clear if you look at these categories of integrations, you know, XDR or threat detection requires full telemetric from within the data center, it's been hard to accomplish to date because you typically need agents on, on your compute nodes to give you the visibility into what's going on or firewalls for east west fuels. Now, our platform can natively provide full visibility into all flows east- west in the data center. And this can become the source of telemetry truth that these MLX CR engines require to work. The other aspects of ecosystem around application dependency mapping, this single core challenge with deploying segmentation east west is understanding the rules to put in & Right, first is how do you insert the service, um, service device in such a way that it won't add more complexity? We don't add any complexity because we're in line natively. How you would understand it, would allow you to build the rules that are necessary to do segmentation. We integrate with tools like Guardi core, we provide our flogs as source of data, and they can provide room recommendations and policy recommendations for customers. Around, we're building integrations around Siemen soam with, with tools like Splunk and elastic, elastic search that will allow NetOps and SecOps teams to visualize trend and manage the services delivered by the CX 10 K. And the other aspect of ecosystem, from a security standpoint is clearly how do I get policy for these traditional appliances and enforce them on this next generation architecture that you've built, that can enable stateful services. So we're building integrations with tools like turf and an algo sec third-party sources of policy that we can ingest and enforce on the infrastructure, allowing you to gradually, um, migrate to this new architecture over time. >> John: It's really a cloud native switch. I mean, you solve people's problems, pin- points, but yet positioned for growth. I mean, it sounds that's my takeaway, but I got to ask you guys both, what's the takeaway for the customers because it's not that simple for them, I mean it's, we a have complicated environment. (all giggling) >> Yeah, I think it's, I think it's really simple, um, you know, every 10 years or so, we see major evolutions in the data center and the switching environment, but we do believe we've created a new category with the distributed services, distributed services switch, delivering cloud scale distributed services, where the local, where the workloads reside greatly, simplifying network, security provisioning, and operations with the urban fabric composer while improving security posture and the TCO. But that's not all the folks, it's a journey, right Shane? >> Yeah, it's absolutely a journey. And this is the first step in a long journey with a great partner like Aruba. There's other platforms, hundred or 400 gig hardware platforms where we're looking at and then this additional services that we can enable over time, allowing customers to drive even more TCO value out of the platform of the architecture services like encryption for securing the cloud on-ramp, services like stateful load balancing to deploy east-west in the data center and, you know, holistically that's, that's the goal, deliver value for customers. And we believe we have an architecture and a platform, and this is a first step in a long journey. >> It's a great way of, I just ask one final, final question for both of you as product leaders, you got to be excited having a category creation product here in this market, this big wave, but what's your thoughts? >> Yeah, exactly right, it doesn't happen that often, and so we're, we're all in it's, it's exciting to be able to work with a great team like Pensando and Shane here. Um, so we're really, really excited about this launch. >> Yeah, it's awesome. The team is great. It's a great partnership between Pensando and Aruba. You know, we, we look forward to delivering value for our joint customers. >> John: Thank you both for sharing under the hood and more details on the product. Thanks for coming on. >> [William And Shane] Thank you. >> Okay. The next evolution in switching, I'm John Furrier here with the power of nHPE Aruba and Pensando changing the game, the way customers scale up in the cloud and networking. Thanks for watching. (music playing)

(upbeat music) >> Welcome back to the cubes coverage of the power of N and the collaborations between HPE Aruba and Pensando. Where the two companies are setting out to create a new category in network switching. Joining me now is Simon McCormack, who looks after product management at HPE Aruba. Welcome Simon. Good to see you. >> Good morning. Thanks for having me today. >> You're very welcome. So Simon, we've been talking all day about the Aruba switching fabric that you're bringing to market embedding the Pensando technology. Can you tell us what's the primary value prop that AFC brings to its customers? >> Sure. Aruba fabric composer. This is orchestration and management for the Aruba wide switching platform, primarily for data centers. It does a lot of things. I'll give you three key ones just to get a feel for it. So in data center, networking, there's a lot of complex technologies. I'm afraid to say, lease spines, overlays, underlays, EDPs, OSPs PGP. I can throw out loads of acronyms for you. Fabric composer can really simplify through a bunch of intent based workflows, the deployment and management of these fabrics. We can do it either interactively through a UI or fully API driven if you want to. So it really takes away a lot of the complexity there makes it dead easy to deploy these and that scale. Number two, in a data center, a lot of compute storage hypervisor technologies that you have to interact with with your network products. So in fabric composer, we built an integration layer into it, that interacts with other orchestrators. V-Center, VMware Vcenter is a good example of that. So an operator may make changes to V-Center that affect the network. You don't want to call the network team for it. Fabric composer can automate that network side configuration on the Aruba switch, making your day to operations, insertion of new services, much more simpler. And then finally, number three, because we've got all these capabilities I've just told you about. We actually have a great typology model that we build from it. And we can use that to visualize this virtual to physical network layer that is really powerful for troubleshooting the environment. >> Great, so three things actually for right simplify, you integrate and automate, and it's kind of two and two way I'm going to call it and then the visualization piece for troubleshooting. Awesome. What about security policy? How are you thinking about that in this release? >> Yeah, so that's where in this release, we're extending it with the Persando PSM technologies embedded into the 10 K. Now we can use Aruba fabric composer to actually orchestrate the policy in addition to the network. So you think about today, fabric poser does network primarily you bring policy into it, you've got one single pane of glass now that doesn't network in policy, it actually provides a really powerful capabilities for operators of different skill sets to be able to manage and orchestrate this environment. >> What about the sort of operational model as it pertains to the network and security, I'm interested in how flexible that is. Like for instance, if a customer wants to use their own tooling or operational frameworks or frameworks so what if they want to leverage multi-vendor fabrics like a third-party spine? How do you deal with all of that? >> Yeah, and I think that's, we built that into essentially the DNA of this technology is that where we're expecting to often go into brownfield environments where they've already got best practices for security and networking. They've already got networking vendors there. The 10 K the very powerful lease switch on its own. We want those lease switches to go in all of these different environments, not just Greenfield. It's really great for Greenfield. And I'm going to explain this a little bit in a few ways. First of all, the technology we have with Aruba fabric composer and Pensando PSM, you can do a pure operational split between them. SecOps, NetOps a lot of customers that's how they deal with it. They've got the security operations team network operations team. If they're split, you can use the two tools and make a fantastic product using that. However, they're not split and you've got a single policy for it. You can use Aruba fabric composer to do both of them. So you've got the options there and we fully embrace that in the architecture of what we built. This extends to multiple layers for the technology build as well. Again, as I said, the 10 K's at Leafs, which it can connect to third-party spines. So you could use fabric composer to manage this lead switch and the policy you could use fabric composer just to manage the lease switch and connect and inter-operate the Leaf's to a spine, or you can do a full Aruba solution, the full Rube Leaf spine and use that operating model. There's one final thing in this area is fabri Composers are a UI based orchestrator, API driven. Some customers love it. Some customers that love their CLIs, we fully embrace the operational model where customers still use their own API APIs and their own CLIs. So the customer may be using Ansible to automate through API. They can still use that directly to the switch and they can use it to AFC and mix the two. If you talk directly to a switch and change it, fabric composer detects it and basically sinks its configuration together. So we can insert all or any part of this solution into existing or new Networks. >> Yeah, that's nice. Right? Because I mean, so there's the network hard guys, they want that CLI access, so you you're accommodating that. And then as well, being able to bring those SecOps view and the NetOps view together is important because let's face it. A lot of organizations, especially some of the smaller ones, they don't actually have a full blown SecOps team, that's really the NetOps responsibility. And so that's nice flexibility. You can handle both worlds. How about segmentation? When a customer is telling you that they want regarding segmentation and how are you guys approaching that? >> Yeah, I mean, it's actually a key feature of what we're doing in this area. Now the land segmentation generates it's kind of a wide area with many layers to it and we could talk about it for hours. So let me talk briefly about some of the areas we're going into when it comes to the segmentation, particularly the compute-virtual type environment. So when you, you're typically creating policies in today's world, current policies based on addresses, IP addresses, or Mac addresses. You have lots of rules and big lists of addresses. It's really annoying. Customers generally don't talk in addresses. They talk in machines and names of machines. So if you think about what I've already told you with a fabric composer. We've already got these hooks in the compute hypervisor layer. So what do we know about the virtual machines? So it's undoubtedly a natural extension now for you to be able to create these policies based on the machines. So there's a scale problem in policy distribution, at two levels, at the top and the bottom. The top level is your chronic create the policy. You've got this massive distribution addresses. So fabric composer can really help you by allowing you to then create these groups, sensible groups, using the names. Then you can distribute the 10 K solution with the distributed architecture of the bottom layer, now allows us to distribute these policies and rules across your racks within your data center. So it scales really well, but that's one level I've described. You know, you're creating groups of machines with names, so it's easier to define it, but there's also an automation angle to this as well. You might not want to even create it interactively. A lot of customers with VMware Vcenter for example, are tagging the virtual machines. So the tag tells you a group information. Again, fabric composer can already get the tag within its database model. So we can use the tag now either to fully automate or use as a hint to creating these groups. So now I've got a really simple way to basically just categorize my machines into the groups so that now I can push rules down onto the, and there's one, final thing that I just want to tell you before we move on, There's often a zero trust model you want to do in the data center for segmentation, meaning I've got two virtual machines on the same network on the same host. Normally they can talk to each other, nothing's stopping them, but sometimes you want to isolate even those two. You can do it in products like V-Center with PV land technologies. A bit cumbersome to configure on the VSphere side, you've got to match it with what you see on the switch side. It's one of those, that's a real headache, unless you've got an orchestrator to do it. So fabric composer could basically orchestrate this isolated solution. You're now grouping the machines and you're saying they're isolated. We can do the smarts and both of the center side and the switch side, get them in sync, get it all configured. And now the masses can start to do this kind of segmentation at scale. >> Got it. Thank you Simon. Can the fabric composer kind of be used as the primary prism for troubleshooting? How do you handle troubleshooting and this art combined architecture? Who, who do I call when there's a problem? How do you approach that? >> Well, definitely start by calling me or actually call my product first, so fabric composer. If you're using it, use that as the front tool for what you're going to try and figure out what's going on. There is a global health dashboard. It encompasses networking security policy across the solution, across the fabric. So that's your tells you what's going on immediately, down to port stats on what's happening within the physical topology of the network down to the end to end view, we have in terms of policy connectivity between machines. So fabric composer is your first port of call, but we built a solution here that we don't want to hide the pieces underneath it. Any networking guy knows when they're deep troubleshooting networking stuff, they're going to end up at the switch. So you started the orchestrator, but sometimes in the deep troubleshooting, not day-to-day hopefully, you'll go to the switch and you'll troubleshoot that way. We've got the same technology here with the policy, with the firewall rules, with Pensando PSM, we still fully embrace. For deep troubleshooting, go to Pensando PSM. They have really advanced tools in their bag of tricks in the product to give you advanced troubleshooting down to the policy layer that they have a really powerful firewall log capability, where you can search and sort and see exactly what role is allowing or stopping any traffic going through the environment. And the two orchestrated model, we really like it because it scales really well. It allows fabric composer to remain lightweight, PSM focused on the policy orchestration bit. But again, if you're the customer that wants to do single pane of glass, use fabric composer for the standard day-to-day stuff. But you've got the tools there to do the advanced troubleshooting between the different elements that we have within the Pensando and the Aruber tools. >> Yeah, really well thought out, you get the simplification angle nailed, the integration automation we talked about that, the visualization and a topology map, zero trust, and then remediation with deepened spend inspection. Simon, thanks so much for taking us through the announcements, really appreciate your insights and time today. >> Thank you very much. >> You're welcome. Okay. Keep it right there. This is Dave Vellante for theCUBE. More content from the HPE Aruba Pensando announcements, coming right up. (soft music)

(bright upbeat music) >> Narrator: From around the globe, it's theCUBE! With digital coverage of AnsibleFest 2020 brought to you by Red Hat. >> Welcome back to the cube virtual coverage of AnsibleFest 2020. Virtual, not face to face this year, obviously because of COVID, and all events are going virtual. This is theCUBE virtual. I'm excited to have on CUBE, alumni Mandy Whaley, who's the Senior Director of DevNet & Cisco Certifications. Mandy, great to see you, >> Thank you. >> virtually. >> Great to see you too. It's exciting to be here with theCUBE again, and especially here at AnsibleFest. >> Last time we saw each other at a physical event was Barcelona in January, as the world was taking a turn. I see a lot of people online, learning has been great. What would DevOpsSec things going on, we'll get to that in a second, but I want to first talk about you and your role in Cisco and Red Hat Ansible. You're a trusted adviser. What are customers experiencing? And what are their expectations around automation? The big theme of this conference? >> Absolutely. So, in terms of the community that I work with at Cisco, it's our DevNet, and our learning community, all of our Cisco certified engineers, as well as our DevNet developer audience. And so, automation is at the core of what they're working on. And we've seen even the move to more work from home, all the virtual things that we're dealing with, that's even more emphasis on companies needing to do automation and needing to have the skills to build that within their teams. So we're really seeing that everyone has expectations around platforms being able to have open API's, integrate with tool sets, having choice in how they integrate things into their different workflows that they may already be using. And then we're seeing a big demand for people wanting to skill up and learn about automation, learn about Ansible, learn about Python. Our new DevNet certifications, they actually cover Cisco platforms as well as industry standard topics like Python and Ansible. And we've seen really great feedback from the community around loving that combination of getting to work really deeply with our Cisco technologies, as well as learning things like Ansible and Python. We had a special special challenge when we launched the DevNet Certifications, for the first 500 people to earn that certification. And we were really excited to see the community achieve that within the first 16 days. So I just think that shows how important automation is to our community right now. >> What do you hear from customers around this certification opportunity around Ansible and Python? Can you give an example? >> So what we're hearing from companies and customers and individual developers is that they're having to deal with more scale, they are seeing more opportunity to handle consistent policy to make sure configurations are consistent. All of these things are really important right now with the scale they're trying to handle. And so, they're looking for ways that they can quickly add these skills to their tool set. And since we are working from home, not traveling as much, everyone's schedule is a little bit different. There is extra opportunity for teams to dig in and do some learning. So, leaders, IT leaders are looking for how do they work with their teams to go after these skills and add them into their way that they approach problems, the way solve problems. And then individuals are looking for how they add them to open up new job roles and new opportunities for themselves. >> Well, I want to give you a shout out and props and kudos for the work you guys have done over at DevNet. We've watched the evolution. Obviously you guys have transformed the learning but also, the API enabled products and economy that Cisco is driving with the SaaS. This is consistent with Ansible's success in the cloud and on premise with private cloud. Again, Cloud, Ops, Sec, everything's kind of happening. Tell us the importance of automation within the Cisco products and how Ansible fits in. >> Absolutely. So, like I said earlier, having this open API's really, across the whole Cisco portfolio, and up and down the stack at the device level, at the controller level. That's part of our strategy. It's important to our customers, it's important to Cisco. We actually have a developer event, DevNet Create, coming up. And, Chuck Robbins, will be talking about some of that importance of developers and automation in the Cisco strategy at DevNet Create. So maybe you can tune in and see some of that as well. We have been working with Ansible since early on in terms of how we bring Cisco technologies together with Ansible. And as Ansible moved to the new collections, we stepped into that very early, we knew it was important to have a seamless transition around that for our community. And that's been a big part of our work this year in terms of how we've been working with Ansible and getting ready for the the new collection structure. >> The people who are watching and know theCUBE know that, or maybe new to theCUBE and our work, know that I've been a cheerleader for Cloud Native, but now it's actually happening, Mandy, we've been cheering it on and saying it's going to happen. Cloud Native and the modern app focus, again, this is some of the narrative on the inside, the industry is now mainstream. This is really a big deal because it's now DevOps and sec, so all that's happening mainstream, the rise of Kubernetes. Everything is on the front burner when it comes to Cloud Native. So I got to ask you, how do the developers here at AnsibleFest get to learn more about Cisco? Because now you're bringing everything together. The automation up and down the stack from modern apps down to the plumbing network's certainly super important from edge, 5G's right around the corner. This is a business enterprise opportunity. How can developers at AnsibleFest learn more about Cisco? >> Fantastic, yes. The one place to learn about all of our Cisco platforms, and like you said, how all these things, Cloud Native, DevOps, DevsSecOps, how all of these things are coming together. You can learn about it at developer.cisco.com. It's where all of our developer resources are, it's where you can find, if you're wanting to get started with Cisco products and Ansible. We have learning labs, engineer to engineer tutorials, videos, sample code, all kinds of the resources to help people get started on that journey. And the other thing we're really seeing is, like you said, this coming together and the real move in enterprises towards DevOps is creating all of these new job roles around DevSecOps, and network automation engineer, and web scale developer. And one of the things we're seeing is people are needing to add skills to their current skill set, mix and match, bringing hardware and software together, cloud and networking skills and development skills to really meet the need for these new job roles, which is being driven by the business demands that we're facing. And that's one of the things that we're working really hard on in the DevNet and Cisco community right now. >> Can't go wrong by continuing your career at Cisco and certainly configuration management software comes together as awesome. So, thanks for sharing that. One of the topics at AnsibleFest 2020 virtual this year is the theme is kind of three things, as we heard on some of the interviews, collections, collections collections. This notion of Ansible (Mandy laughs) automation platform has a numerous Cisco certified collections. Can you share some insight and anecdotes from your community on, from the DevNet users on what they're dealing with day to day around automation and how these collections and the certified collections fits in? >> Yeah, absolutely. So, part of my team has been working with our community, with Ansible, to bring the Cisco Ansible collections together. And it's been a big part of our work throughout the year. And we've seen tremendous use by the community. So we've been following the downloads of people downloading connections and using them is growing rapidly. We are really excited to see the use of the community and then the community interest support. And then we're doing our best to make sure that we have playbooks in our DevNet code exchange, so people can go in and find them. That we're helping people understand collections and how all that fits together in the current Ansible structure. And we've just seen tremendous interesting response from the community on that. >> How does this tie into security automation? Another theme that comes up, you talk about network, you got cloud, you got security, intrusion, detection, prevention, these are all useful things to DevNet users, how does that all fit in? >> Security is one of the areas that I'm consistently hearing about from our community and customers. I think people are really looking for how they can deal with increased scale, how they can increase the scale that they're able to deal with and keep it secure. We're seeing people want to take quick action, when a malicious activity occurs, or even something like ensuring that policy is consistent across a range of security endpoints. And these are all places where automation can really help out, and help teams manage the scale that they're having to deal with. So, one of the things we've been working with is showing some learning labs on DevNet, that combine using Ansible with our security products to help people tackle some of those use cases. We have an area called automation exchange. And it's all about these automation use cases, and giving you the sample code to get started on tackling some of these harder use cases. That's where we have seen a lot of interest around security. >> On a broader scale, could you tell us where you see NetOps going? I mean, it's a big theme, Susie Wee, April, yourself. We've all chatted about this in the past NetOps, or DevOps for networking ops for basically DevOps for networking, basically. >> Yes. >> Where's this... Where's it going in the future? Where are we on the progress? Certainly there's been great evolution. How is DevNet evolving to push this mission forward? >> So, one of the things that we talk with customers a lot about when they are moving down this pathway to bringing DevOps to the way that they run their network is we talk about a walk, run, fly progression. And walk is where there, I use cases where maybe you are only doing read-only type things, and you're gathering insight, you're gathering information to help with troubleshooting, you're gathering information that maybe gets packaged up into a ticket that then an engineer takes action on. And this is a great place where a lot of organizations can start. If they are learning these skills, building these practices, they don't have to worry about it, making changes but they get a lot of the benefit of the automation. So, we're recommending that to at least two companies who are getting started, teams that are getting started, as a place to start their automation journey. And then really moving through that progression of next, taking some automated action, all the way to that full DevOps, lifecycle and workflow. And we're seeing companies move through that progression as their teams also move through that progression. >> Just as a side note, one of the things we've been riffing on lately around the Cloud Native, as you know now, it's mainstream as we just talked about, is that the integrations are a big part of it. So, you could have an environment that has a little bit of that, a little bit of this. A lot of integrations because of API's, and also microservices, you get Kubernetes around to tie it on, glue it all together. You got DevNet Create coming up, and you guys always have a great DevNet Zone at your events. It's a real learning environment. Talk of Ansible developers in the community out there and how you guys work together for these classes, because you guys have a lot of learning, is like a cross section of the community that work together, some don't some do. The Cloud Native really enables the integrations to happen quicker. Can you just share what's going on at DevNet Create, and your world? >> Absolutely. So, and it's great because, John, you were at our first DevNet Create years ago when we started it. So it's really exciting. This is our first virtual DevNet Create, that's October 13th. And we had planned it to be an in person event in March when the pandemic hit the US, and so we had to re-plan, and regroup and bring it to a virtual audience this fall. And it's actually been great with our virtual events, we've been able to see how there's many more people who can participate, who can learn who can be a part of that community, because it's not only limited to the people who can be there in person. So we're actually really excited about that virtual part of it. And DevNet Create is the event where we have speakers from all over our community, from companies, from partners, from community groups, and all kinds of technologies, like you said, it's a great place to look at the integrations. So you'll find talks on Ansible, you'll find talks on Kubernetes, you'll find talks on IoT, you'll find talks on mashing up different API's to go after use cases. And it's really about that strength of the community speakers that brings a lot of excellent content into DevNet Create, and we're so thankful for them, and the way that our community likes to, step up and share and help each other. >> Well, yes, we were there for the first one we will still be there with you. But the question that comes up, and I'd like you to just quickly take a minute to clarify the difference between DevNet and DevNet Create, cause there is a nuance here, it's important. Take a minute to explain DevNet and DevNet Create, and the objective of the two. >> Absolutely. So DevNet are DevNet Zone Event, which happen typically in our Cisco lives, they have more of a focus on our more network engineer community who's spanning into programmability, DevOps, moving that direction because it happens within a Cisco live event, normally, the DevNet Zone. DevNet Create is our conference that started to focus on the application developer, the cloud developer, and how they are starting to tackle some of these hybrid use cases. And so DevNet Create is the place where that really comes together. And when, last year, Susie and I are on stage and we really wanted to know kind of what aspects people were bringing to the conference. And we asked the community, how many people are really focused on application development in their day job? That's their main focus. How many people are more on the Ops side? Infrastructure developer, DevOps engineer? And then how many people are really working to bridge that? And it was one third, one third, one third, in terms of the people at Create that year. And that was just really great to see. And to me, I think really shows the community that's building around around DevNet Create. >> And if you look at the trends too, the discussions are about modern applications, and certainly with COVID, people are looking at this and saying, "Hey, it's an opportunity to use this pandemic "and look at the opportunity to be very agile, "and create these modern apps which require programmability, "which require "some instructions away >> That's right. >> "from the complexity, all the way down to the network." I mean, it really gives great vision. >> All the way to the network. Yeah, and even things like, using things with Meraki cameras with using things like our collaboration products, to build those use cases that are really helping out in a lot of the new challenges that we're facing. So that's all what you can find at DevNet Create. It's one of my favorite events because it does cover such a range of topics. >> I'm in my first interview at one of your first event with Todd Nightingale. He is doing the Meraki thing. Now he's running a lot of the big part of the business there. But it really was a great vision. You guys really nailed it. Hats off to you guys. Kudos props. Congratulations and stay safe. And we'll see you at your event. Thanks for joining me. >> Thank you so much, and thanks to AnsibleFest. >> Okay, that's theCUBE virtual coverage. I'm John Furrier, your host with AnsibleFest 2020. Thanks for watching. (bright upbeat music)

(soft music) >> From around the globe, it's theCUBE. Presenting, Accelerating Automation with DevNet, brought to you by Cisco. >> And welcome back everybody, Jeff Frick here with theCUBE. We have our ongoing coverage of the Cisco DevNet event. It's really Accelerating with Automation and Programmability in the new normal. And we know the new normal is definitely continuing to go. We've been doing this since the middle of March and now we're in October. So, we're excited to have our next guest. He's Thomas Scheibe, he is the vice president of product management for data center for Cisco, Thomas, great to see you. >> Hey, good to see you too. >> Yeah. >> Yeah, and truly run it in normal as everybody can see on our background. >> Exactly, so, I mean, I'm curious, we've talked to a lot of people. We talked to a lot of leaders, you know, especially like back in March and April with this light switch moment, which was, you know, no time to prep, and suddenly everybody has to work from home. Teachers got to teach from home. And so you got the kids home, you got the spouse home, everybody's home trying to get on the network and do their zoom calls and their classes. I'm curious from your perspective, you guys are right there on the network, you're right in the infrastructure. What did you hear and see kind of from your customers when suddenly, you know, March 16th hit and everybody had to go home? >> Well, (laughs) good point, hey, I do think we all appreciate the network much more than we used to do before. And then the only other difference is I'm really more on WebEx calls and zoom calls, but, you know, otherwise yes. What I do see actually is that as I said network becomes much more operas as a critical piece. And so before we really talked a lot about agility and flexibility, these days we talk much more about resiliency quite frankly, and what do I need to have in place with respect to network to get my things from left to right. And you know, north to south and east to west, as we see in the data center. >> Right. >> And touches as for most of my customers, a very, very important topic at this point. >> Right, you know, it's amazing to think, you know, had this happened, you know, five years ago, 10 years ago, you know, the ability for so many people in the information industry to be able to actually make that transition relatively seamlessly is actually pretty amazing. I'm sure there was (chuckles) some excitement and some kudos in terms of, you know, it is all based on the network and it is kind of this quiet thing in the background that nobody pays attention to. It's like a ref in the football game until they make a bad play. So, you know, it is pretty fascinating that you and your colleagues have put this infrastructure and that enabled us to really make that move with really no prep, no planning and actually have a whole lot of services delivered into our homes that we're used to getting at the office or are used to getting at school. >> Yeah, and I mean, to your point, I mean, some of us did some planning. We clearly talking about some of these trends and the way I look at this trend as being distributed data centers and having the ability to move your workloads and access for users to wherever you want to be. And so I think that clearly went on for a while. And so, in a sense we prep was our normal we're prepping for. But as I said, resiliency just became so much more important. And, you know, one of the things I actually do a little preview for a blog I put out end of August around resiliency. If you didn't put this in place, you better put it in place. Because I think as we all know, we saw it in March this is like maybe two or three months, we're now in October. And I think this is the new normal for some time being. >> Yeah, I think so. So, let's stick on that theme in terms of trends, right? The other great trend is public cloud and hybrid cloud and multi cloud. There's all types of variants on that theme, you had in that blog post about resiliency in data center cloud networking, data center cloud. You know, some people think, wait, it's kind of an either or I either got my data center or I've got my stuff in the cloud and I've got public cloud. And then as I said, hybrid cloud, you're talking really specifically about enabling both inner data center resiliency within multi data center resiliency within the same enterprise as well as connecting to the cloud. That's probably counterintuitive for some people to think that that's something that Cisco is excited about and supporting. So, I wonder if you can share, you know, kind of how the market is changing, how you guys are reacting and really putting the things in place to deliver customer choice. >> Yeah, no, it's actually, to me, it's really not counterintuitive because in the end, what I'm focusing on and the company is focusing on is what our customers want to do and need to do. And that's really, you know, most people call hybrid cloud or multicloud. In the end, what it is is really the ability to have the flexibility, to move your workloads where you want them to be. And there are different reasons why you want to place them, right? You might've placed them for security reason. You might played some compliance reasons depending on which customer segment you're after. If you're in the United States or in Europe or in Asia, there are a lot of different reasons where you're going to put your syncs. And so I think in the end what an enterprise looks for is that agility, flexibility, and resiliency. And so really what you want to put in place is what we call like a cloud on ramp, right? You need to have an ability to move syncs as needed. But the logic context section which we see in the last couple of months accelerating is really this whole theme around digital transformation, which goes hand in hand than was the requirement on the IT side really do. And IT operations transformation, right? How IT operates. And I think that's really exciting to see, and this was excellent. Well, a lot of my discussions I was customized. What does it actually mean with respect to the IT organization? And what are the operational changes there's a lot of our customers are going through quite frankly accelerated going through? >> Right, and automation is in the title of the event. So, automation is an increasingly important thing, you know, as we know, and we hear all the time, you know, the flows of data, the complexity of the data. Either on the security or the way the network's moving, or as you said, shifting workloads around, based on the dynamic situations, whether that's business security, et cetera. And a software defined networking has been around for a while. How are you seeing kind of this evolution in adding more automation, you know, to more and more processes to free up those you know, kind of limited resources in terms of really skilled people to focus on the things that they should be focused on and not stuff that hopefully you can, you know, get a machine to run with some level of automation. >> Yeah, that's a good point. And I said, TechLine, I have, you know, sometimes when my mind is really going from CloudReady, which is in most of our infrastructure is today to cloud-native. And so let me a little expand on those, right? It's like the CloudReady is basically what we have put in place over the last five to six years, all the infrastructure that our customers have, network infrastructure or the Nexus 9000, they're all CloudReady, right? And what this really means, you have APIs everywhere, right? Whether this is on the box, whether it's on the controller, whether this is on the operations tools, all of these are API enabled. And that's just the foundation for automation, right? You have to have that. Now, the next step really is what do you do with that capability, right? And this is the integration with a lot of automation tools and that's the whole range, right? This is where the IT operation transformation kicks in different customers at different speed, right? Some just, you know, I use these APIs and use normal tools that they have on a network world just to pull information. Some customers go for further saying, "I want to integrate this with some CMDB tools." Some go even further and saying, "This is like the cloud-native (indistinct), "Oh, I want to use, let's say, Red Hat Ansible, or I want to use (indistinct) Terraform and use those things to actually drive how I managed my infrastructure. And so that's really the combination of the automation capability plus the integration was relevant cloud-native enabling tools that really is happening at this point. We're seeing customers accelerating in that motion. Which really then drives us how they run their IT operations. >> Right. >> And so that's a pretty exciting area to see. given as I said, we have the infrastructure in place. There's no need for customers to actually do change something. Most of them have already the infrastructures that can do this. It's just not doing the operational change the process change is to actually get there. >> Right, and it's funny, we recently covered, you know, PagerDuty and they highlight what you just talked about, the cloud-native, which is, you know, all of these applications now are so interdependent on all these different API, you know, pulling data from all these technical applications. So, hey, when they work great, it's terrific. But if there's a problem, you know, there's a whole lot of potential throats to choke out there and find those issues. And it's all being connected via the network. So, you know, it's even more critically important, not only for the application, but for all these little tiny components within the application to deliver, you know, ultimately a customer experience within very small units of time. So, that you don't lose that customer. You complete that transaction. They check out of their shopping cart. You know, all these things that are now created with cloud-native applications that just couldn't really do before. >> Now, you're absolutely right. And this is like, just as I said, I'm actually very excited because it opens up a lot of abilities for our customers. How they want to actually structure the operation, right? One of the nice things around this whole automation plus cloud network tool integration is you actually opened us up not a sole automation training, not just to the network operations personnel, right? You also open it up and can use those for the SecOps person or for the DevOps person or for the CloudOps engineering team, right? Because the way it's structured, the way we built this, it's literally as an API interface and you can now decide, what is your process? Do you want to have a more traditional process, you have to request, a network operation teams executes the request using these tools and then hands it back over. Or do you say, "Hey, maybe some of these security things, "I can hand over the SecOps team and they can "directly call these APIs, right?" Or even one step further, you can have the opportunity that the DevOps or the application team actually says, "Hey, I going to write a whole infrastructure as code "kind of a script or template, and I just execute, right?" And it's really just using what the infrastructure provides. And so that whole range of different user roles in our customer base, what they can do with the automation capability that's available. It's just very, very exciting way because it literally unleashes a lot of flexibility. How they want to structure and how they want to rebuild the IT operations processes. >> That's interesting, you know, 'cause the, you know, the DevOps culture has taken over a lot, right? Obviously changed software programming for the last 20 years. And I think, you know, there's a lot of just kind of the concept of DevOps versus necessarily, you know, the actual things that you do to execute that technique. And I don't think most people would think of, you know, NetworkOps or, NetOps, whatever the equivalent is in the networking world to have kind of a fast changing dynamic kind of point of view versus a stick it in, spec it, stick it in, lock it down. So, I wonder if you can, you can share how, kind of that DevOps attitude point of view, workflow, whatever the right verb is has impacted things at Cisco in the way you guys think about networking and flexibility within the networking world. >> Yeah, literally, absolutely. And again, it's all customer driven, right? It's none of these is really actually, you know, a little bit of credit, maybe some of us where we have a vision, but a lot of it is just customer driven feedback. And yeah, we do have EU Network Operations Teams come to you saying, "Hey, we use Ansible heavily on the compute, "so, we might use this for Alpha Seven. "We want to use the same for networking." And so we made available all these integrations with sobriety as a state, whether these are the switches, whether these are ACI and dc network controller or our multi site orchestration capabilities, all of these has Ansible integration the way to the right. The other one as I mentioned that how she formed Tarco Terraform, we have integrations available and they see the requests for these tools to use that. And so that is the motion we're in for over a year now. And another blog actually is out there we just posted saying, Yeah, all set what you can do. And then a parallel to this, right? Just making the integration available. We also have a very, very heavy focus on definite and enablement and training. And, you know, a little plucking I know probably part of the segment, the whole definite community that Cisco has is very, very vibrant. And the beauty of this is right. If you look at us, whether you're a NetOps person or a DevOps person or a SecOps person, it doesn't really matter. There's a lot of like capability available to just help you get going or go from one level to the next level, right? And there's simple things like sandbox environments where you can, you know, without stress try things out, snippets of code are there, you can do all of these things. And so we do see it's a kind of a push and pull a tremendous amount of interest and a tremendous time people spend to learn. Quite frankly then, that's another side product of the suggestion when people say, "Oh man, and say, okay, online learning is the thing." So, these tools are used very heavily. >> Right. That's awesome 'cause you know, we've had Susie Leon a number of times and I know he and Mandy and the team, right? Really built this DevNet thing. And it really follows along this other theme that we see consistently across other pieces of tech, which is democratization, right? Democratization is the access tool, taking it out of just a mahogany row with, again, a really limited number of people that know how to make it work. And it can make the changes in an opening up to a software defined world where now it's application centric point of view, where the people that are building the apps to go create competitive advantage now don't have to wait for, you know, the one network person to help them out in and out of these environments really interesting. And I wonder if, you know, when you look at what's happened with public cloud and how they kind of changed the buying parameter, how they kind of changed the degree of difficulty to get project started, you know, how you guys have kind of integrated that type of thought process to make it easier for app developers to get their job done. >> Yeah, I mean, again, I typically look at this more from a customer lens, right? It's the transformation process and it always starts as I want agility, I want flexibility and I want resiliency, right? This is where we talk to a business owner what they're looking for. And then that translates into an IT operations process, right? Your strategy needs to map then how you actually do this. And that just drives then what tools do you want to have available to actually enable this, right? And the enablement again is for different roles, right? You need to give sync services to the app developer and the platform team and the security team, right? To your point so the network can act at the same speed. But you also give tools to the network operations teams because they need to adjust then, they have the ability to react to some of these requirements, right? And it's not just automation, I said we focused on that, but there's also to your point, the need, how do I extend between data centers? You know, just for backup and recovery, and how do I extend into public clouds, right? And in the end that's a network connectivity problem, and we have solved as, we have meters available, we have integrations into AWS. We have integrations into Ajua to actually make this very easy from a network perspective to extend your private domains, private networks into which have private networks on these public clouds. So, from an app developer perspective, now it looks like it's on the same network. It's a protective enterprise network. Some of it might sit here, some of it might sit here. But it's really looking the same. And that's really in the end I said what a business looks at, right? They don't necessarily want to say, I need you to have something separate for this deployment or separate for that deployment. What they want is I need you to deploy something. I need to do this resilience. And the resilient way and an agile way gives me the tools. And so that's really where we focused and what we're driving, right? It's that combination of automation consistently, and then definite tools available that we support, but they're all open. They're all standard tools as the ones I mentioned, right? That everybody's using. So, you're not getting into this, "Oh, this is specific to Cisco, right? It's really democratization, I actually liked your term. >> Yeah, it's a great term and it's really interesting, especially with the APIs and the way everything is so tied together. That everyone kind of has to enable this because that's what the customer is demanding. And it is all about the applications and the workloads and where those things are moving, but they don't really want to manage that. They just want to, you know, deliver business benefit to their customers in respond to, you know, competitive threats in the marketplace, et cetera. So, it's really an interesting time for the infrastructure to really support kind of this app first point of view, versus the other way around is kind of what it used to be. And enable this hyper fast development, hyper fast change in the competitive landscape or else you will be left behind. So, super important stuff. >> Yeah, no, I totally agree. And as I said, I mean, it's kind of interesting because we started on the Cisco data center. It's where we started this probably six or seven years ago. When we named the application-centric, clearly a lot of these concepts evolved. But in a sense it is that reversal of the role from the network provides something and you use to, this is what I want to do. And I need a service thinking on the networking side to expose services that can be consumed. And so that clearly is playing out. And as I said, automation is a key foundation that we put in place. And our customers most of our customers at this point are on these products. They have all the capabilities there are. They can literally take advantage. There's really nothing that stops them at this point. >> Well, it's good times for you because I'm sure you've seen all the memes in social media, right? What's driving your digital transformation is the CEO, the CMO or COVID. And we all know the answer to the question. So, I don't think the pace of change is going to slow down anytime soon. So, (indistinct) keeping the network up and enabling us all to get done what we have to get done and all the little magic that happens behind the scenes. >> Yeah, I know, thanks for having me and again, yeah, if you're listening and you're wondering, how do I get started? Cisco definitely is the place to go. It's, you know, fantastic, fantastic environment. And I highly recommend everybody, roll up the sleeves and you know, the best reasons you can have. >> Yeah, and we know once the physical events come back, we've been to DevNet Create a bunch of times, and it's a super vibrant, super excited, really engaged community, sharing lots of information. It's still kind of that early vibe, you know, where everyone is still really enthusiastic and really about learning and sharing information. So, like Susie and the team have really built a great thing and we're happy to continue to cover it and eventually we'll be back face to face. >> Okay, (chuckles) look forward to that as well. >> All right, thanks. He's Thomas and I'm Jeff you're watching continuing coverage of CiscoDevNet Accelerating With Automation and Programmability. Thanks for watching, we'll see you next time. (upbeat music)

(electronic music) >> From Santa Clara, California in the heart of Silicon Valley, its theCUBE. Covering Altitude 2020, brought to you by Aviatrix. (electronic music) >> Female pilot: Good morning, ladies and gentlemen, this is your captain speaking, we will soon be taking off on our way to altitude. (upbeat music) Please keep your seat belts fastened and remain in your seat. We will be experiencing turbulence, until we are above the clouds. (thunder blasting) (electronic music) (seatbelt alert sounds) Ladies and gentlemen, we are now cruising at altitude. Sit back and enjoy the ride. (electronic music) >> Female pilot: Altitude is a community of thought leaders and pioneers, cloud architects and enlightened network engineers, who have individually and are now collectively, leading their own IT teams and the industry. On a path to lift cloud networking above the clouds. Empowering enterprise IT to architect, design and control their own cloud network, regardless of the turbulent clouds beneath them. It's time to gain altitude. Ladies and gentlemen, Steve Mullaney, president and CEO of Aviatrix. The leader of multi-cloud networking. (electronic music) (audience clapping) >> Steve: All right. (audience clapping) Good morning everybody, here in Santa Clara as well as to the millions of people watching the livestream worldwide. Welcome to Altitude 2020, all right. So, we've got a fantastic event, today, I'm really excited about the speakers that we have today and the experts that we have and really excited to get started. So, one of the things I wanted to share was this is not a one-time event. This is not a one-time thing that we're going to do. Sorry for the Aviation analogy, but, you know, Sherry Wei, aviatrix means female pilot so everything we do has an aviation theme. This is a take-off, for a movement. This isn't an event, this is a take-off of a movement. A multi-cloud networking movement and community that we're inviting all of you to become part of. And why we're doing that, is we want to enable enterprises to rise above the clouds, so to speak and build their network architecture, regardless of which public cloud they're using. Whether it's one or more of these public clouds. So the good news, for today, there's lots of good news but this is one good news, is we don't have any PowerPoint presentations, no marketing speak. We know that marketing people have their own language. We're not using any of that, and no sales pitches, right? So instead, what are we doing? We're going to have expert panels, we've got Simon Richard, of Gartner here. We've got ten different network architects, cloud architects, real practitioners that are going to share their best practices and their real world experiences on their journey to the multi-cloud. So, before we start, everybody know what today is? In the U.S., it's Super Tuesday. I'm not going to get political, but Super Tuesday there was a bigger, Super Tuesday that happened 18 months ago. And Aviatrix employees know what I'm talking about. Eighteen months ago, on a Tuesday, every enterprise said, "I'm going to go to the cloud". And so what that was, was the Cambrian explosion, for cloud, for the enterprise. So, Frank Cabri, you know what a Cambrian explosion is. He had to look it up on Google. 500 million years ago, what happened, there was an explosion of life where it went from very simple single-cell organisms to very complex, multi-cell organisms. Guess what happened 18 months ago, on a Tuesday, I don't really know why, but every enterprise, like I said, all woke up that day and said, "Now I'm really going to go to cloud" and that Cambrian explosion of cloud meant that I'm moving from a very simple, single cloud, single-use case, simple environment, to a very complex, multi-cloud, complex use case environment. And what we're here today, is we're going to go undress that and how do you handle those, those complexities? And, when you look at what's happening, with customers right now, this is a business transformation, right? People like to talk about transitions, this is a transformation and it's actually not just a technology transformation, it's a business transformation. It started from the CEO and the Boards of enterprise customers where they said, "I have an existential threat to the survival of my company." If you look at every industry, who they're worried about is not the other 30-year-old enterprise. What they're worried about is the three year old enterprise that's leveraging cloud, that's leveraging AI, and that's where they fear that they're going to actually wiped out, right? And so, because of this existential threat, this is CEO led, this is Board led, this is not technology led, it is mandated in the organizations. We are going to digitally transform our enterprise, because of this existential threat and the movement to cloud is going to enable us to go do that. And so, IT is now put back in charge. If you think back just a few years ago, in cloud, it was led by DevOps, it was led by the applications and it was, like I said, before the Cambrian explosion, it was very simple. Now, with this Cambrian explosion, an enterprise is getting very serious and mission critical. They care about visibility, they care about control, they care about compliance, conformance, everything, governance. IT is in charge and that's why we're here today to discuss that. So, what we're going to do today, is much of things but we're going to validate this journey with customers. >> Steve: Did they see the same thing? We're going to validate the requirements for multi-cloud because, honestly, I've never met an enterprise that is not going to be multicloud. Many are one cloud today but they all say, " I need to architect my network for multiple clouds", because that's just what, the network is there to support the applications and the applications will run in whatever cloud it runs best in and you have to be prepared for that. The second thing is, is architecture. Again, with IT in charge, you, architecture matters. Whether its your career, whether its how you build your house, it doesn't matter. Horrible architecture, your life is horrible forever. Good architecture, your life is pretty good. So, we're going to talk about architecture and how the most fundamental and critical part of that architecture and that basic infrastructure is the network. If you don't get that right, nothing works, right? Way more important than compute. Way more important than storage. Network is the foundational element of your infrastructure. Then we're going to talk about day two operations. What does that mean? Well day one is one day of your life, where you wire things up they do and beyond. I tell everyone in networking and IT -- it's every day of your life. And if you don't get that right, your life is bad forever. And so things like operations, visibility, security, things like that, how do I get my operations team to be able to handle this in an automated way because it's not just about configuring it in the cloud, it's actually about how do I operationalize it? And that's a huge benefit that we bring as Aviatrix. And then the last thing we're going to talk and it's the last panel we have, I always sayyou can't forget about the humans, right? So all this technology, all these things that we're doing, it's always enabled by the humans. At the end of the day, if the humans fight it, it won't get deployed. And we have a massive skills gap, in cloud and we also have a massive skills shortage. You have everyone in the world trying to hire cloud network architects, right? There's just not enough of them going around. So, at Aviatrix, we said as leaders do, "We're going to help address that issue and try to create more people." We created a program, what we call the ACE Program, again, aviation theme, it stands for Aviatrix Certified Engineer. Very similar to what Cisco did with CCIEs where Cisco taught you about IP networking, a little bit of Cisco, we're doing the same thing, we're going to teach network architects about multicloud networking and architecture and yeah, you'll get a little bit of Aviatrix training in there, but this is the missing element for people's careers and also within their organizations. So we're going to go talk about that. So, great, great event, great show. We're going to try to keep it moving. I next want to introduce, my host, he is the best in the business, you guys have probably seen him multiple, many times, he is the co-CEO and co founder of theCUBE, John Furrier. (audience clapping) (electronic music) >> John: Okay, awesome, great speech there, awesome. >> Yeah. >> I totally agree with everything you said about the explosion happening and I'm excited, here at the heart of silicon valley to have this event. It's a special digital event with theCUBE and Aviatrix, where we're live-streaming to, millions of people, as you said, maybe not a million. >> Maybe not a million. (laughs) Really to take this program to the world and this is really special for me, because multi-cloud is the hottest wave in cloud. And cloud-native networking is fast becoming the key engine, of the innovations, so we got an hour and a half of action-packed programming. We have a customer panel. Two customer panels. Before that Gartner's going to come out, talk about the industry. We have global system integrators, that will talk about, how their advising and building these networks and cloud native networking. And then finally the ACE's, the Aviatrix Certified Engineers, are going to talk more about their certifications and the expertise needed. So, let's jump right in, let's ask, Simon Richard to come on stage, from Gartner. We'll kick it all off. (electronic music) (clapping) >> John: Hi, can I help you. Okay, so kicking things off, getting started. Gartner, the industry experts on cloud. Really kind of more, cue your background. Talk about your background before you got to Gartner? >> Simon: Before being at Gartner, I was a chief network architect, of a Fortune 500 company, that with thousands of sites over the world and I've been doing everything in IT from a C programmer, in the 90, to a security architect, to a network engineer, to finally becoming a network analyst. >> So you rode the wave. Now you're covering the marketplace with hybrid cloud and now moving quickly to multi-cloud, is really what everyone is talking about. >> Yes. >> Cloud-native's been discussed, but the networking piece is super important. How do you see that evolving? >> Well, the way we see Enterprise adapting, cloud. The first thing you do about networking, the initial phases they either go in a very ad hoc way. Is usually led by none IT, like a shadow IT, or application people, sometime a DevOps team and it just goes as, it's completely unplanned. They create VPC's left and right with different account and they create mesh to manage them and they have Direct Connect or Express Route to any of them. So that's the first approach and on the other side. again within our first approach you see what I call, the lift and shift. Where we see like enterprise IT trying to, basically replicate what they have in a data center, in the Cloud. So they spend a lot of time planning, doing Direct Connect, putting Cisco routers and F5 and Citrix and any checkpoint, Palo Alto device, that in a sense are removing that to the cloud. >> I got to ask you, the aha moment is going to come up a lot, in one our panels, is where people realize, that it's a multi-cloud world. I mean, they either inherit clouds, certainly they're using public cloud and on-premises is now more relevant than ever. When's that aha moment? That you're seeing, where people go, "Well I got to get my act together and get on this cloud." >> Well the first, right, even before multi-cloud. So there is two approach's. The first one, like the adult way doesn't scare. At some point IT has to save them, 'cause they don't think about the tools, they don't think about operation, they have a bunch of VPC and multiple cloud. The other way, if you do the lift and shift way, they cannot take any advantages of the cloud. They lose elasticity, auto-scaling, pay by the drink. All these agility features. So they both realize, okay, neither of these ways are good, so I have to optimize that. So I have to have a mix of what I call, the cloud native services, within each cloud. So they start adapting, like all the AWS Construct, Azure Construct or Google Construct and that's what I call the optimal phase. But even that they realize, after that, they are all very different, all these approaches different, the cloud are different. Identities is constantly, difficult to manage across clouds. I mean, for example, anybody who access' accounts, there's subscription, in Azure and GCP, their projects. It's a real mess, so they realized, well I don't really like constantly use the cloud product and every cloud, that doesn't work. So I have, I'm going multi-cloud, I like to abstract all of that. I still want to manage the cloud from an EPI point of view, I don't necessarily want to bring my incumbent data center products, but I have to do that and in a more EPI driven cloud environment. >> So, the not scaling piece that you where mentioning, that's because there's too many different clouds? >> Yes. >> That's the least they are, so what are they doing? What are they, building different development teams? Is it software? What's the solution? >> Well, the solution is to start architecting the cloud. That's the third phase. I called that the multi-cloud architect phase, where they have to think about abstraction that works across cloud. Fact, even across one cloud it might not scale as well, If you start having like ten thousand security agreement, anybody who has that doesn't scale. You have to manage that. If you have multiple VPC, it doesn't scale. You need a third-party, identity provider. In variously scales within one cloud, if you go multiple cloud, it gets worse and worse. >> Steve, weigh in here. What's your thoughts? >> I thought we said this wasn't going to be a sales pitch for Aviatrix. (laughter) You just said exactly what we do, so anyway, that's a joke. What do you see in terms of where people are, in that multi-cloud? So, like lot of people, you know, everyone I talk to, started at one cloud, right, but then they look and then say okay but I'm now going to move to Azure and I'm going to move to... (trails off) Do you see a similar thing? >> Well, yes. They are moving but there's not a lot of application, that uses three cloud at once, they move one app in Azure, one app in AWS and one app in Google. That's what we see so far. >> Okay, yeah, one of the mistakes that people think, is they think multi-cloud. No one is ever going to go multi-cloud, for arbitrage. They're not going to go and say, well, today I might go into Azure, 'cause I get a better rate on my instance. Do you agree? That's never going to happen. What I've seen with enterprise, is I'm going to put the workload in the app, the app decides where it runs best. That may be Azure, maybe Google and for different reasons and they're going to stick there and they're not going to move. >> Let me ask you guys-- >> But the infrastructure, has to be able to support, from a networking team. >> Yes. >> Be able to do that. Do you agree with that? >> Yes, I agree. And one thing is also very important, is connecting to the cloud, is kind of the easiest thing. So, the wide area network part of the cloud, connectivity to the cloud is kind of simple. >> Steve: I agree. >> IP's like VPN, Direct Connect, Express Route. That's the simple part, what's difficult and even the provisioning part is easy. You can use Terraform and create VPC's and Vnet's across your three cloud provider. >> Steve: Right. >> What's difficult is that they choose the operation. So we'll define day two operation. What does that actually mean? >> Its just the day to day operations, after you know, the natural, lets add an app, lets add a server, lets troubleshoot a problem. >> Something changes, now what do you do? >> So what's the big concerns? I want to just get back to the cloud native networking, because everyone kind of knows what cloud native apps are. That's been the hot trend. What is cloud native networking? How do you guys, define that? Because that seems to be the hardest part of the multi-cloud wave that's coming, is cloud native networking. >> Well there's no, you know, official Gartner definition but I can create one on the spot. >> John: Do it. (laughter) >> I just want to leverage the Cloud Construct and the cloud EPI. I don't want to have to install, like a... (trails off) For example, the first version was, let's put a virtual router that doesn't even understand the cloud environment. >> Right. If I have if I have to install a virtual machine, it has to be cloud aware. It has to understand the security group, if it's a router. It has to be programmable, to the cloud API. And understand the cloud environment. >> And one thing I hear a lot from either CSO's, CIO's or CXO's in general, is this idea of, I'm definitely not going API. So, its been an API economy. So API is key on that point, but then they say. Okay, I need to essentially have the right relationship with my suppliers, aka you called it above the clouds. So the question is... What do I do from an architectural standpoint? Do I just hire more developers and have different teams, because you mentioned that's a scale point. How do you solve this problem of, okay, I got AWS, I got GCP, or Azure, or whatever. Do I just have different teams or do I just expose EPI's? Where is that optimization? Where's the focus? >> Well, I think what you need, from a network point of view is a way, a control plane across the three clouds. And be able to use the API's of the cloud, to build networks but also to troubleshoot them and do day to day operation. So you need a view across the three clouds, that takes care of routing, connectivity. >> Steve: Performance. >> John: That's the Aviatrix plugin, right there. >> Steve: Yeah. So, how do you see, so again, your Gartner, you see the industry. You've been a network architect. How do you see this this playing out? What are the legacy incumbent client server, On Prem networking people, going to do? >> Well they need to.. >> Versus people like a Aviatrix? How do you see that playing out? >> Well obviously, all the incumbents, like Arista, Cisco, Juniper, NSX. >> Steve: Right. >> They want to basically do the lift and shift part, they want to bring, and you know, VMware want to bring in NSX on the cloud, they call that "NSX everywhere" and Cisco want to bring in ACI to the cloud, they call that "ACI Anywhere". So, everyone's.. (trails off) And then there's CloudVision from Arista, and Contrail is in the cloud. So, they just want to bring the management plane, in the cloud, but it's still based, most of them, is still based on putting a VM in them and controlling them. You extend your management console to the cloud, that's not truly cloud native. >> Right. >> Cloud native you almost have to build it from scratch. >> We like to call that cloud naive. >> Cloud naive, yeah. >> So close, one letter, right? >> Yes. >> That was a big.. (slurs) Reinvent, take the T out of Cloud Native. It's Cloud Naive. (laughter) >> That went super viral, you guys got T-shirts now. I know you're loving that. >> Steve: Yeah. >> But that really, ultimately, is kind of a double-edged sword. You can be naive on the architecture side and ruleing that. And also suppliers or can be naive. So how would you define who's naive and who's not? >> Well, in fact, their evolving as well, so for example, in Cisco, it's a little bit more native than other ones, because there really is, "ACI in the cloud", you can't really figure API's out of the cloud. NSX is going that way and so is Arista, but they're incumbent, they have their own tools, its difficult for them. They're moving slowly, so it's much easier to start from scratch. Even you, like, you know, a network company that started a few years ago. There's only really two, Aviatrix was the first one, they've been there for at least three or four years. >> Steve: Yeah. >> And there's other one's, like Akira, for example that just started. Now they're doing more connectivity, but they want to create an overlay network, across the cloud and start doing policies and things. Abstracting all the clouds within one platform. >> So, I got to ask you. I interviewed an executive at VMware, Sanjay Poonen, he said to me at RSA last week. Oh, there'll only be two networking vendors left, Cisco and VMware. (laughter) >> What's you're response to that? Obviously when you have these waves, these new brands that emerge, like Aviatrix and others. I think there'll be a lot of startups coming out of the woodwork. How do you respond to that comment? >> Well there's still a data center, there's still, like a lot, of action on campus and there's the wan. But from the cloud provisioning and cloud networking in general, I mean, they're behind I think. You know, you don't even need them to start with, you can, if you're small enough, you can just keep.. If you have AWS, you can use the AWS construct, they have to insert themselves, I mean, they're running behind. From my point of view. >> They are, certainly incumbents. I love the term Andy Jess uses at Amazon web services. He uses "Old guard, new guard", to talk about the industry. What does the new guard have to do? The new brands that are emerging. Is it be more DevOp's oriented? Is it NetSec ops? Is it NetOps? Is it programmability? These are some of the key discussions we've been having. What's your view, on how you see this programmability? >> The most important part is, they have to make the network simple for the Dev teams. You cannot make a phone call and get a Vline in two weeks anymore. So if you move to the cloud, you have to make that cloud construct as simple enough, so that for example, a Dev team could say, "Okay, I'm going to create this VPC, but this VPC automatically associates your account, you cannot go out on the internet. You have to go to the transit VPC, so there's lot of action in terms of, the IAM part and you have to put the control around them to. So to make it as simple as possible. >> You guys, both. You're the CEO of Aviatrix, but also you've got a lot of experience, going back to networking, going back to the, I call it the OSI days. For us old folks know what that means, but, you guys know what this means. I want to ask you the question. As you look at the future of networking, you hear a couple objections. "Oh, the cloud guys, they got networking, we're all set with them. How do you respond to the fact that networking's changing and the cloud guys have their own networking. What's some of the paying points that's going on premises of these enterprises? So are they good with the clouds? What needs... What are the key things that's going on in networking, that makes it more than just the cloud networking? What's your take on it? >> Well as I said earlier. Once you could easily provision in the cloud, you can easily connect to the cloud, its when you start troubleshooting applications in the cloud and try to scale. So that's where the problem occurred. >> Okay, what's your take on it. >> And you'll hear from the customers, that we have on stage and I think what happens is all the clouds by definition, designed to the 80-20 rule which means they'll design 80% of the basic functionality. And then lead to 20% extra functionality, that of course every Enterprise needs, to leave that to ISV's, like Aviatrix. Because why? Because they have to make money, they have a service and they can't have huge instances, for functionality that not everybody needs. So they have to design to the common and that, they all do it, right? They have to and then the extra, the problem is, that Cambrian explosion, that I talked about with enterprises. That's what they need. They're the ones who need that extra 20%. So that's what I see, there's always going to be that extra functionality. In an automated and simple way, that you talked about, but yet powerful. With the up with the visibility and control, that they expect of On Prem. That kind of combination, that Yin and the Yang, that people like us are providing. >> Simon I want to ask you? We're going to ask some of the cloud architect, customer panels, that same question. There's pioneer's doing some work here and there's also the laggards who come in behind their early adopters. What's going to be the tipping point? What are some of these conversations, that the cloud architects are having out there? Or what's the signs, that they need to be on this, multi-cloud or cloud native networking trend? What are some of the signal's that are going on in the environment? What are some of the thresholds? Are things that are going on, that they can pay attention to? >> Well, once they have the application on multiple cloud and they have to get wake up at two in the morning, to troubleshoot them. They'll know it's important. (laughter) So, I think that's when the rubber will hit the road. But, as I said, it's easier to prove, at any case. Okay, it's AWS, it's easy, user transit gateway, put a few VPC's and you're done. And you create some presents like Equinox and do a Direct Connect and Express Route with Azure. That looks simple, its the operations, that's when they'll realize. Okay, now I need to understand! How cloud networking works? I also need a tool, that gives me visibility and control. But not only that, I need to understand the basic underneath it as well. >> What are some of the day in the life scenarios. you envision happening with multi-cloud, because you think about what's happening. It kind of has that same vibe of interoperability, choice, multi-vendor, 'cause they're multi-cloud. Essentially multi-vendor. These are kind of old paradigms, that we've lived through with client server and internet working. What are some of the scenarios of success, that might be possible? Will be possible, with multi-cloud and cloud native networking. >> Well, I think, once you have good enough visibility, to satisfy your customers, not only, like to, keep the service running and application running. But to be able to provision fast enough, I think that's what you want to achieve. >> Simon, final question. Advice for folks watching on the Livestream, if they're sitting there as a cloud architect or CXO. What's your advice to them right now, in this market, 'cause obviously, public cloud check, hybrid cloud, they're working on that. That gets on premises done, now multi-cloud's right behind it. What's your advice? >> The first thing they should do, is really try to understand cloud networking. For each of their cloud providers and then understand the limitations. And, is what the cloud service provider offers enough? Or you need to look to a third party, but you don't look at a third party to start with. Especially an incumbent one, so it's tempting to say "I have a bunch of F5 experts", nothing against F5. I'm going to bring my F5 in the Cloud, when you can use an ELB, that automatically understand eases and auto scaling and so on. And you understand that's much simpler, but sometimes you need your F5, because you have requirements. You have like iRules and that kind of stuff, that you've used for years. 'cause you cannot do it. Okay, I have requirement and that's not met, I'm going to use Legacy Star and then you have to start thinking, okay, what about visibility control, above the true cloud. But before you do that you have to understand the limitations of the existing cloud providers. First, try to be as native as possible, until things don't work, after that you can start thinking of the cloud. >> Great insight, Simon. Thank you. >> That's great. >> With Gartner, thank you for sharing. (electronic music)

(electronic music) >> From Santa Clara, California in the heart of Silicon Valley, its theCUBE. Covering Altitude 2020, brought to you by Aviatrix. (electronic music) >> Female pilot: Good morning, ladies and gentlemen, this is your captain speaking, we will soon be taking off on our way to altitude. (upbeat music) Please keep your seat belts fastened and remain in your seat. We will be experiencing turbulence, until we are above the clouds. (thunder blasting) (electronic music) (seatbelt alert sounds) Ladies and gentlemen, we are now cruising at altitude. Sit back and enjoy the ride. (electronic music) >> Female pilot: Altitude is a community of thought leaders and pioneers, cloud architects and enlightened network engineers, who have individually and are now collectively, leading their own IT teams and the industry. On a path to lift cloud networking above the clouds. Empowering enterprise IT to architect, design and control their own cloud network, regardless of the turbulent clouds beneath them. It's time to gain altitude. Ladies and gentlemen, Steve Mullaney, president and CEO of Aviatrix. The leader of multi-cloud networking. (electronic music) (audience clapping) >> Steve: All right. (audience clapping) Good morning everybody, here in Santa Clara as well as to the millions of people watching the livestream worldwide. Welcome to Altitude 2020, all right. So, we've got a fantastic event, today, I'm really excited about the speakers that we have today and the experts that we have and really excited to get started. So, one of the things I wanted to share was this is not a one-time event. This is not a one-time thing that we're going to do. Sorry for the Aviation analogy, but, you know, Sherry Wei, aviatrix means female pilot so everything we do has an aviation theme. This is a take-off, for a movement. This isn't an event, this is a take-off of a movement. A multi-cloud networking movement and community that we're inviting all of you to become part of. And why we're doing that, is we want to enable enterprises to rise above the clouds, so to speak and build their network architecture, regardless of which public cloud they're using. Whether it's one or more of these public clouds. So the good news, for today, there's lots of good news but this is one good news, is we don't have any PowerPoint presentations, no marketing speak. We know that marketing people have their own language. We're not using any of that, and no sales pitches, right? So instead, what are we doing? We're going to have expert panels, we've got Simon Richard, of Gartner here. We've got ten different network architects, cloud architects, real practitioners that are going to share their best practices and their real world experiences on their journey to the multi-cloud. So, before we start, everybody know what today is? In the U.S., it's Super Tuesday. I'm not going to get political, but Super Tuesday there was a bigger, Super Tuesday that happened 18 months ago. And Aviatrix employees know what I'm talking about. Eighteen months ago, on a Tuesday, every enterprise said, "I'm going to go to the cloud". And so what that was, was the Cambrian explosion, for cloud, for the enterprise. So, Frank Cabri, you know what a Cambrian explosion is. He had to look it up on Google. 500 million years ago, what happened, there was an explosion of life where it went from very simple single-cell organisms to very complex, multi-cell organisms. Guess what happened 18 months ago, on a Tuesday, I don't really know why, but every enterprise, like I said, all woke up that day and said, "Now I'm really going to go to cloud" and that Cambrian explosion of cloud meant that I'm moving from a very simple, single cloud, single-use case, simple environment, to a very complex, multi-cloud, complex use case environment. And what we're here today, is we're going to go undress that and how do you handle those, those complexities? And, when you look at what's happening, with customers right now, this is a business transformation, right? People like to talk about transitions, this is a transformation and it's actually not just a technology transformation, it's a business transformation. It started from the CEO and the Boards of enterprise customers where they said, "I have an existential threat to the survival of my company." If you look at every industry, who they're worried about is not the other 30-year-old enterprise. What they're worried about is the three year old enterprise that's leveraging cloud, that's leveraging AI, and that's where they fear that they're going to actually wiped out, right? And so, because of this existential threat, this is CEO led, this is Board led, this is not technology led, it is mandated in the organizations. We are going to digitally transform our enterprise, because of this existential threat and the movement to cloud is going to enable us to go do that. And so, IT is now put back in charge. If you think back just a few years ago, in cloud, it was led by DevOps, it was led by the applications and it was, like I said, before the Cambrian explosion, it was very simple. Now, with this Cambrian explosion, an enterprise is getting very serious and mission critical. They care about visibility, they care about control, they care about compliance, conformance, everything, governance. IT is in charge and that's why we're here today to discuss that. So, what we're going to do today, is much of things but we're going to validate this journey with customers. >> Steve: Did they see the same thing? We're going to validate the requirements for multi-cloud because, honestly, I've never met an enterprise that is not going to be multicloud. Many are one cloud today but they all say, " I need to architect my network for multiple clouds", because that's just what, the network is there to support the applications and the applications will run in whatever cloud it runs best in and you have to be prepared for that. The second thing is, is architecture. Again, with IT in charge, you, architecture matters. Whether its your career, whether its how you build your house, it doesn't matter. Horrible architecture, your life is horrible forever. Good architecture, your life is pretty good. So, we're going to talk about architecture and how the most fundamental and critical part of that architecture and that basic infrastructure is the network. If you don't get that right, nothing works, right? Way more important than compute. Way more important than storage. Network is the foundational element of your infrastructure. Then we're going to talk about day two operations. What does that mean? Well day one is one day of your life, where you wire things up they do and beyond. I tell everyone in networking and IT -- it's every day of your life. And if you don't get that right, your life is bad forever. And so things like operations, visibility, security, things like that, how do I get my operations team to be able to handle this in an automated way because it's not just about configuring it in the cloud, it's actually about how do I operationalize it? And that's a huge benefit that we bring as Aviatrix. And then the last thing we're going to talk and it's the last panel we have, I always sayyou can't forget about the humans, right? So all this technology, all these things that we're doing, it's always enabled by the humans. At the end of the day, if the humans fight it, it won't get deployed. And we have a massive skills gap, in cloud and we also have a massive skills shortage. You have everyone in the world trying to hire cloud network architects, right? There's just not enough of them going around. So, at Aviatrix, we said as leaders do, "We're going to help address that issue and try to create more people." We created a program, what we call the ACE Program, again, aviation theme, it stands for Aviatrix Certified Engineer. Very similar to what Cisco did with CCIEs where Cisco taught you about IP networking, a little bit of Cisco, we're doing the same thing, we're going to teach network architects about multicloud networking and architecture and yeah, you'll get a little bit of Aviatrix training in there, but this is the missing element for people's careers and also within their organizations. So we're going to go talk about that. So, great, great event, great show. We're going to try to keep it moving. I next want to introduce, my host, he is the best in the business, you guys have probably seen him multiple, many times, he is the co-CEO and co founder of theCUBE, John Furrier. (audience clapping) (electronic music) >> John: Okay, awesome, great speech there, awesome. >> Yeah. >> I totally agree with everything you said about the explosion happening and I'm excited, here at the heart of silicon valley to have this event. It's a special digital event with theCUBE and Aviatrix, where we're live-streaming to, millions of people, as you said, maybe not a million. >> Maybe not a million. (laughs) Really to take this program to the world and this is really special for me, because multi-cloud is the hottest wave in cloud. And cloud-native networking is fast becoming the key engine, of the innovations, so we got an hour and a half of action-packed programming. We have a customer panel. Two customer panels. Before that Gartner's going to come out, talk about the industry. We have global system integrators, that will talk about, how their advising and building these networks and cloud native networking. And then finally the ACE's, the Aviatrix Certified Engineers, are going to talk more about their certifications and the expertise needed. So, let's jump right in, let's ask, Simon Richard to come on stage, from Gartner. We'll kick it all off. (electronic music) (clapping) >> John: Hi, can I help you. Okay, so kicking things off, getting started. Gartner, the industry experts on cloud. Really kind of more, cue your background. Talk about your background before you got to Gartner? >> Simon: Before being at Gartner, I was a chief network architect, of a Fortune 500 company, that with thousands of sites over the world and I've been doing everything in IT from a C programmer, in the 90, to a security architect, to a network engineer, to finally becoming a network analyst. >> So you rode the wave. Now you're covering the marketplace with hybrid cloud and now moving quickly to multi-cloud, is really what everyone is talking about. >> Yes. >> Cloud-native's been discussed, but the networking piece is super important. How do you see that evolving? >> Well, the way we see Enterprise adapting, cloud. The first thing you do about networking, the initial phases they either go in a very ad hoc way. Is usually led by none IT, like a shadow IT, or application people, sometime a DevOps team and it just goes as, it's completely unplanned. They create VPC's left and right with different account and they create mesh to manage them and they have Direct Connect or Express Route to any of them. So that's the first approach and on the other side. again within our first approach you see what I call, the lift and shift. Where we see like enterprise IT trying to, basically replicate what they have in a data center, in the Cloud. So they spend a lot of time planning, doing Direct Connect, putting Cisco routers and F5 and Citrix and any checkpoint, Palo Alto device, that in a sense are removing that to the cloud. >> I got to ask you, the aha moment is going to come up a lot, in one our panels, is where people realize, that it's a multi-cloud world. I mean, they either inherit clouds, certainly they're using public cloud and on-premises is now more relevant than ever. When's that aha moment? That you're seeing, where people go, "Well I got to get my act together and get on this cloud." >> Well the first, right, even before multi-cloud. So there is two approach's. The first one, like the adult way doesn't scare. At some point IT has to save them, 'cause they don't think about the tools, they don't think about operation, they have a bunch of VPC and multiple cloud. The other way, if you do the lift and shift way, they cannot take any advantages of the cloud. They lose elasticity, auto-scaling, pay by the drink. All these agility features. So they both realize, okay, neither of these ways are good, so I have to optimize that. So I have to have a mix of what I call, the cloud native services, within each cloud. So they start adapting, like all the AWS Construct, Azure Construct or Google Construct and that's what I call the optimal phase. But even that they realize, after that, they are all very different, all these approaches different, the cloud are different. Identities is constantly, difficult to manage across clouds. I mean, for example, anybody who access' accounts, there's subscription, in Azure and GCP, their projects. It's a real mess, so they realized, well I don't really like constantly use the cloud product and every cloud, that doesn't work. So I have, I'm going multi-cloud, I like to abstract all of that. I still want to manage the cloud from an EPI point of view, I don't necessarily want to bring my incumbent data center products, but I have to do that and in a more EPI driven cloud environment. >> So, the not scaling piece that you where mentioning, that's because there's too many different clouds? >> Yes. >> That's the least they are, so what are they doing? What are they, building different development teams? Is it software? What's the solution? >> Well, the solution is to start architecting the cloud. That's the third phase. I called that the multi-cloud architect phase, where they have to think about abstraction that works across cloud. Fact, even across one cloud it might not scale as well, If you start having like ten thousand security agreement, anybody who has that doesn't scale. You have to manage that. If you have multiple VPC, it doesn't scale. You need a third-party, identity provider. In variously scales within one cloud, if you go multiple cloud, it gets worse and worse. >> Steve, weigh in here. What's your thoughts? >> I thought we said this wasn't going to be a sales pitch for Aviatrix. (laughter) You just said exactly what we do, so anyway, that's a joke. What do you see in terms of where people are, in that multi-cloud? So, like lot of people, you know, everyone I talk to, started at one cloud, right, but then they look and then say okay but I'm now going to move to Azure and I'm going to move to... (trails off) Do you see a similar thing? >> Well, yes. They are moving but there's not a lot of application, that uses three cloud at once, they move one app in Azure, one app in AWS and one app in Google. That's what we see so far. >> Okay, yeah, one of the mistakes that people think, is they think multi-cloud. No one is ever going to go multi-cloud, for arbitrage. They're not going to go and say, well, today I might go into Azure, 'cause I get a better rate on my instance. Do you agree? That's never going to happen. What I've seen with enterprise, is I'm going to put the workload in the app, the app decides where it runs best. That may be Azure, maybe Google and for different reasons and they're going to stick there and they're not going to move. >> Let me ask you guys-- >> But the infrastructure, has to be able to support, from a networking team. >> Yes. >> Be able to do that. Do you agree with that? >> Yes, I agree. And one thing is also very important, is connecting to the cloud, is kind of the easiest thing. So, the wide area network part of the cloud, connectivity to the cloud is kind of simple. >> Steve: I agree. >> IP's like VPN, Direct Connect, Express Route. That's the simple part, what's difficult and even the provisioning part is easy. You can use Terraform and create VPC's and Vnet's across your three cloud provider. >> Steve: Right. >> What's difficult is that they choose the operation. So we'll define day two operation. What does that actually mean? >> Its just the day to day operations, after you know, the natural, lets add an app, lets add a server, lets troubleshoot a problem. >> Something changes, now what do you do? >> So what's the big concerns? I want to just get back to the cloud native networking, because everyone kind of knows what cloud native apps are. That's been the hot trend. What is cloud native networking? How do you guys, define that? Because that seems to be the hardest part of the multi-cloud wave that's coming, is cloud native networking. >> Well there's no, you know, official Gartner definition but I can create one on the spot. >> John: Do it. (laughter) >> I just want to leverage the Cloud Construct and the cloud EPI. I don't want to have to install, like a... (trails off) For example, the first version was, let's put a virtual router that doesn't even understand the cloud environment. >> Right. If I have if I have to install a virtual machine, it has to be cloud aware. It has to understand the security group, if it's a router. It has to be programmable, to the cloud API. And understand the cloud environment. >> And one thing I hear a lot from either CSO's, CIO's or CXO's in general, is this idea of, I'm definitely not going API. So, its been an API economy. So API is key on that point, but then they say. Okay, I need to essentially have the right relationship with my suppliers, aka you called it above the clouds. So the question is... What do I do from an architectural standpoint? Do I just hire more developers and have different teams, because you mentioned that's a scale point. How do you solve this problem of, okay, I got AWS, I got GCP, or Azure, or whatever. Do I just have different teams or do I just expose EPI's? Where is that optimization? Where's the focus? >> Well, I think what you need, from a network point of view is a way, a control plane across the three clouds. And be able to use the API's of the cloud, to build networks but also to troubleshoot them and do day to day operation. So you need a view across the three clouds, that takes care of routing, connectivity. >> Steve: Performance. >> John: That's the Aviatrix plugin, right there. >> Steve: Yeah. So, how do you see, so again, your Gartner, you see the industry. You've been a network architect. How do you see this this playing out? What are the legacy incumbent client server, On Prem networking people, going to do? >> Well they need to.. >> Versus people like a Aviatrix? How do you see that playing out? >> Well obviously, all the incumbents, like Arista, Cisco, Juniper, NSX. >> Steve: Right. >> They want to basically do the lift and shift part, they want to bring, and you know, VMware want to bring in NSX on the cloud, they call that "NSX everywhere" and Cisco want to bring in ACI to the cloud, they call that "ACI Anywhere". So, everyone's.. (trails off) And then there's CloudVision from Arista, and Contrail is in the cloud. So, they just want to bring the management plane, in the cloud, but it's still based, most of them, is still based on putting a VM in them and controlling them. You extend your management console to the cloud, that's not truly cloud native. >> Right. >> Cloud native you almost have to build it from scratch. >> We like to call that cloud naive. >> Cloud naive, yeah. >> So close, one letter, right? >> Yes. >> That was a big.. (slurs) Reinvent, take the T out of Cloud Native. It's Cloud Naive. (laughter) >> That went super viral, you guys got T-shirts now. I know you're loving that. >> Steve: Yeah. >> But that really, ultimately, is kind of a double-edged sword. You can be naive on the architecture side and ruleing that. And also suppliers or can be naive. So how would you define who's naive and who's not? >> Well, in fact, their evolving as well, so for example, in Cisco, it's a little bit more native than other ones, because there really is, "ACI in the cloud", you can't really figure API's out of the cloud. NSX is going that way and so is Arista, but they're incumbent, they have their own tools, its difficult for them. They're moving slowly, so it's much easier to start from scratch. Even you, like, you know, a network company that started a few years ago. There's only really two, Aviatrix was the first one, they've been there for at least three or four years. >> Steve: Yeah. >> And there's other one's, like Akira, for example that just started. Now they're doing more connectivity, but they want to create an overlay network, across the cloud and start doing policies and things. Abstracting all the clouds within one platform. >> So, I got to ask you. I interviewed an executive at VMware, Sanjay Poonen, he said to me at RSA last week. Oh, there'll only be two networking vendors left, Cisco and VMware. (laughter) >> What's you're response to that? Obviously when you have these waves, these new brands that emerge, like Aviatrix and others. I think there'll be a lot of startups coming out of the woodwork. How do you respond to that comment? >> Well there's still a data center, there's still, like a lot, of action on campus and there's the wan. But from the cloud provisioning and cloud networking in general, I mean, they're behind I think. You know, you don't even need them to start with, you can, if you're small enough, you can just keep.. If you have AWS, you can use the AWS construct, they have to insert themselves, I mean, they're running behind. From my point of view. >> They are, certainly incumbents. I love the term Andy Jess uses at Amazon web services. He uses "Old guard, new guard", to talk about the industry. What does the new guard have to do? The new brands that are emerging. Is it be more DevOp's oriented? Is it NetSec ops? Is it NetOps? Is it programmability? These are some of the key discussions we've been having. What's your view, on how you see this programmability? >> The most important part is, they have to make the network simple for the Dev teams. You cannot make a phone call and get a Vline in two weeks anymore. So if you move to the cloud, you have to make that cloud construct as simple enough, so that for example, a Dev team could say, "Okay, I'm going to create this VPC, but this VPC automatically associates your account, you cannot go out on the internet. You have to go to the transit VPC, so there's lot of action in terms of, the IAM part and you have to put the control around them to. So to make it as simple as possible. >> You guys, both. You're the CEO of Aviatrix, but also you've got a lot of experience, going back to networking, going back to the, I call it the OSI days. For us old folks know what that means, but, you guys know what this means. I want to ask you the question. As you look at the future of networking, you hear a couple objections. "Oh, the cloud guys, they got networking, we're all set with them. How do you respond to the fact that networking's changing and the cloud guys have their own networking. What's some of the paying points that's going on premises of these enterprises? So are they good with the clouds? What needs... What are the key things that's going on in networking, that makes it more than just the cloud networking? What's your take on it? >> Well as I said earlier. Once you could easily provision in the cloud, you can easily connect to the cloud, its when you start troubleshooting applications in the cloud and try to scale. So that's where the problem occurred. >> Okay, what's your take on it. >> And you'll hear from the customers, that we have on stage and I think what happens is all the clouds by definition, designed to the 80-20 rule which means they'll design 80% of the basic functionality. And then lead to 20% extra functionality, that of course every Enterprise needs, to leave that to ISV's, like Aviatrix. Because why? Because they have to make money, they have a service and they can't have huge instances, for functionality that not everybody needs. So they have to design to the common and that, they all do it, right? They have to and then the extra, the problem is, that Cambrian explosion, that I talked about with enterprises. That's what they need. They're the ones who need that extra 20%. So that's what I see, there's always going to be that extra functionality. In an automated and simple way, that you talked about, but yet powerful. With the up with the visibility and control, that they expect of On Prem. That kind of combination, that Yin and the Yang, that people like us are providing. >> Simon I want to ask you? We're going to ask some of the cloud architect, customer panels, that same question. There's pioneer's doing some work here and there's also the laggards who come in behind their early adopters. What's going to be the tipping point? What are some of these conversations, that the cloud architects are having out there? Or what's the signs, that they need to be on this, multi-cloud or cloud native networking trend? What are some of the signal's that are going on in the environment? What are some of the thresholds? Are things that are going on, that they can pay attention to? >> Well, once they have the application on multiple cloud and they have to get wake up at two in the morning, to troubleshoot them. They'll know it's important. (laughter) So, I think that's when the rubber will hit the road. But, as I said, it's easier to prove, at any case. Okay, it's AWS, it's easy, user transit gateway, put a few VPC's and you're done. And you create some presents like Equinox and do a Direct Connect and Express Route with Azure. That looks simple, its the operations, that's when they'll realize. Okay, now I need to understand! How cloud networking works? I also need a tool, that gives me visibility and control. But not only that, I need to understand the basic underneath it as well. >> What are some of the day in the life scenarios. you envision happening with multi-cloud, because you think about what's happening. It kind of has that same vibe of interoperability, choice, multi-vendor, 'cause they're multi-cloud. Essentially multi-vendor. These are kind of old paradigms, that we've lived through with client server and internet working. What are some of the scenarios of success, that might be possible? Will be possible, with multi-cloud and cloud native networking. >> Well, I think, once you have good enough visibility, to satisfy your customers, not only, like to, keep the service running and application running. But to be able to provision fast enough, I think that's what you want to achieve. >> Simon, final question. Advice for folks watching on the Livestream, if they're sitting there as a cloud architect or CXO. What's your advice to them right now, in this market, 'cause obviously, public cloud check, hybrid cloud, they're working on that. That gets on premises done, now multi-cloud's right behind it. What's your advice? >> The first thing they should do, is really try to understand cloud networking. For each of their cloud providers and then understand the limitations. And, is what the cloud service provider offers enough? Or you need to look to a third party, but you don't look at a third party to start with. Especially an incumbent one, so it's tempting to say "I have a bunch of F5 experts", nothing against F5. I'm going to bring my F5 in the Cloud, when you can use an ELB, that automatically understand eases and auto scaling and so on. And you understand that's much simpler, but sometimes you need your F5, because you have requirements. You have like iRules and that kind of stuff, that you've used for years. 'cause you cannot do it. Okay, I have requirement and that's not met, I'm going to use Legacy Star and then you have to start thinking, okay, what about visibility control, above the true cloud. But before you do that you have to understand the limitations of the existing cloud providers. First, try to be as native as possible, until things don't work, after that you can start thinking of the cloud. >> Great insight, Simon. Thank you. >> That's great. >> With Gartner, thank you for sharing. (electronic music) >> Welcome back to ALTITUDE 2020. For the folks in the live stream, I'm John Furrier, Steve Mullaney, CEO of Aviatrix. For our first of two customer panels with cloud network architects, we've got Bobby Willoughby, AEGON Luis Castillo from National Instruments and David Shinnick with FactSet. Guys, welcome to the stage for this digital event. Come on up. (audience clapping) (upbeat music) Hey good to see you, thank you. Customer panel, this is my favorite part. We get to hear the real scoop, we get the Gardener giving us the industry overview. Certainly, multi-cloud is very relevant, and cloud-native networking is a hot trend with the live stream out there in the digital events. So guys, let's get into it. The journey is, you guys are pioneering this journey of multi-cloud and cloud-native networking and are soon going to be a lot more coming. So I want to get into the journey. What's it been like? Is it real? You've got a lot of scar tissue? What are some of the learnings? >> Absolutely. Multi-cloud is whether or not we accept it, as network engineers is a reality. Like Steve said, about two years ago, companies really decided to just bite the bullet and move there. Whether or not we accept that fact, we need to not create a consistent architecture across multiple clouds. And that is challenging without orchestration layers as you start managing different tool sets and different languages across different clouds. So it's really important to start thinking about that. >> Guys on the other panelists here, there's different phases of this journey. Some come at it from a networking perspective, some come in from a problem troubleshooting, what's your experiences? >> From a networking perspective, it's been incredibly exciting, it's kind of once in a generational opportunity to look at how you're building out your network. You can start to embrace things like infrastructure as code that maybe your peers on the systems teams have been doing for years, but it just never really worked on-prem. So it's really exciting to look at all the opportunities that we have and all of the interesting challenges that come up that you get to tackle. >> And effects that you guys are mostly AWS, right? >> Yeah. Right now though, we are looking at multiple clouds. We have production workloads running in multiple clouds today but a lot of the initial work has been with Amazon. >> And you've seen it from a networking perspective, that's where you guys are coming at it from? >> Yup. >> Awesome. How about you? >> We evolve more from a customer requirement perspective. Started out primarily as AWS, but as the customer needed more resources from Azure like HPC, Azure AD, things like that, even recently, Google analytics, our journey has evolved into more of a multi-cloud environment. >> Steve, weigh in on the architecture because this is going to be a big conversation, and I wanted you to lead this section. >> I think you guys agree the journey, it seems like the journey started a couple of years ago. Got real serious, the need for multi-cloud, whether you're there today. Of course, it's going to be there in the future. So that's really important. I think the next thing is just architecture. I'd love to hear what you, had some comments about architecture matters, it all starts, every enterprise I talked to. Maybe talk about architecture and the importance of architects, maybe Bobby. >> From architecture perspective, we started our journey five years ago. >> Wow, okay. >> And we're just now starting our fourth evolution over network architect. And we call it networking security net sec, versus just as network. And that fourth-generation architecture should be based primarily upon the Palo Alto Networks and Aviatrix. Aviatrix to new orchestration piece of it. But that journey came because of the need for simplicity, the need for a multi-cloud orchestration without us having to go and do reprogramming efforts across every cloud as it comes along. >> I guess the other question I also had around architecture is also... Luis maybe just talk about it. I know we've talked a little bit about scripting, and some of your thoughts on that. >> Absolutely. So for us, we started creating the network constructs with cloud formation, and we've stuck with that for the most part. What's interesting about that is today, on-premise, we have a lot of automation around how we provision networks, but cloud formation has become a little bit like the new manual for us. We're now having issues with having to automate that component and making it consistent with our on-premise architecture and making it consistent with Azure architecture and Google cloud. So, it's really interesting to see companies now bring that layer of abstraction that SD-WAN brought to the wound side, now it's going up into the cloud networking architecture. >> Great. So on the fourth generation, you mentioned you're on the fourth-gen architecture. What have you learned? Is there any lessons, scratch issue, what to avoid, what worked? What was the path that you touched? >> It's probably the biggest lesson there is that when you think you finally figured it out, you haven't. Amazon will change something, Azure change something. Transit Gateway is a game-changer. And listening to the business requirements is probably the biggest thing we need to do upfront. But I think from a simplicity perspective, like I said, we don't want to do things four times. We want to do things one time, we want be able to write to an API which Aviatrix has and have them do the orchestration for us. So that we don't have to do it four times. >> How important is architecture in the progression? Is it do you guys get thrown in the deep end, to solve these problems, are you guys zooming out and looking at it? How are you guys looking at the architecture? >> You can't get off the ground if you don't have the network there. So all of those, we've gone through similar evolutions, we're on our fourth or fifth evolution. I think about what we started off with Amazon without Direct Connect Gateway, without Transit Gateway, without a lot of the things that are available today, kind of the 80, 20 that Steve was talking about. Just because it wasn't there doesn't mean we didn't need it. So we needed to figure out a way to do it, we couldn't say, "Oh, you need to come back to the network team in a year, and maybe Amazon will have a solution for it." We need to do it now and evolve later and maybe optimize or change the way you're doing things in the future. But don't sit around and wait, you can't. >> I'd love to have you guys each individually answer this question for the live streams that comes up a lot. A lot of cloud architects out in the community, what should they be thinking about the folks that are coming into this proactively and, or realizing the business benefits are there? What advice would you guys give them on architecture? What should be they'd be thinking about, and what are some guiding principles you could share? >> So I would start with looking at an architecture model that can spread and give consistency to the different cloud vendors that you will absolutely have to support. Cloud vendors tend to want to pull you into using their native tool set, and that's good if only it was realistic to talk about only one cloud. But because it doesn't, it's super important to talk about, and have a conversation with the business and with your technology teams about a consistent model. >> And how do I do my day one work so that I'm not spending 80% of my time troubleshooting or managing my network? Because if I'm doing that, then I'm missing out on ways that I can make improvements or embrace new technologies. So it's really important early on to figure out, how do I make this as low maintenance as possible so that I can focus on the things that the team really should be focusing on? >> Bobby, your advice there, architecture. >> I don't know what else I can add to that. Simplicity of operations is key. >> So the holistic view of day two operations you mentioned, let's can jump in day one as you're getting stuff set up, day two is your life after. This is kind of of what you're getting at, David. So what does that look like? What are you envisioning as you look at that 20-mile stair, out post multi-cloud world? What are some of the things that you want in the day two operations? >> Infrastructure as code is really important to us. So how do we design it so that we can start fit start making network changes and fitting them into a release pipeline and start looking at it like that, rather than somebody logging into a router CLI and troubleshooting things in an ad hoc nature? So, moving more towards a dev-ops model. >> You guys, anything to add on that day two? >> Yeah, I would love to add something. In terms of day two operations you can either sort of ignore the day two operations for a little while, where you get your feet wet, or you can start approaching it from the beginning. The fact is that the cloud-native tools don't have a lot of maturity in that space and when you run into an issue, you're going to end up having a bad day, going through millions and millions of logs just to try to understand what's going on. That's something that the industry just now is beginning to realize it's such a big gap. >> I think that's key because for us, we're moving to more of an event-driven or operations. In the past, monitoring got the job done. It's impossible to monitor something that is not there when the event happens. So the event-driven application and then detection is important. >> Gardner is all about the cloud-native wave coming into networking. That's going to be a serious thing. I want to get your guys' perspective, I know you have each different views of how you come into the journey and how you're executing. And I always say the beauty's in the eye of the beholder and that applies to how the network's laid out. So, Bobby, you guys do a lot of high-performance encryption, both on AWS and Azure. That's a unique thing for you. How are you seeing that impact with multi-cloud? >> That's a new requirement for us too, where we have an increment to encrypt. And then if you ever get the question, should I encrypt, should I not encrypt? The answer is always yes. You should encrypt when you can encrypt. For our perspective, we need to migrate a bunch of data from our data centers. We have some huge data centers, and getting that data to the cloud is a timely expense in some cases. So we have been mandated, we have to encrypt everything, leave in the data center. So we're looking at using the Aviatrix insane mode appliances to be able to encrypt 10, 20 gigabits of data as it moves to the cloud itself. >> David, you're using Terraform, you've got FireNet, you've got a lot of complexity in your network. What do you guys look at the future for your environment? >> So many exciting that we're working on now as FireNet. So for our security team that obviously have a lot of knowledge base around Palo Alto, and with our commitments to our clients, it's not very easy to shift your security model to a specific cloud vendor. So there's a lot of SOC 2 compliance and things like that were being able to take some of what you've worked on for years on-prem and put it in the cloud and have the same type of assurance that things are going to work and be secure in the same way that they are on-prem, helps make that journey into the cloud a lot easier. >> And Louis, you guys got scripting, you got a lot of things going on. What's your unique angle on this? >> Absolutely. So for disclosure, I'm not an Aviatrix customer yet. (laughs) >> It's okay, we want to hear the truth, so that's good. Tell us, what are you thinking about? What's on your mind? >> When you talk about implementing a tool like this, it's really just really important to talk about automation focus on value. When you talk about things like encryption and things like so you're encrypting tunnels and encrypting the path, and those things should be second nature really. When you look at building those back-ends and managing them with your team, it becomes really painful. So tools like Aviatrix that add a lot automation it's out of sight, out of mind. You can focus on the value, and you don't have to focus on this. >> So I got to ask you guys. I see Aviatrix was here, they're supplier to this sector, but you guys are customers. Everyone's pitching your stuff, people knock on you, "Buy my stuff." How do you guys have that conversation with the suppliers, like the cloud vendors and other folks? What's it like? We're API all the way? You've got to support this? What are some of your requirements? How do you talk to and evaluate people that walk in and want to knock on your door and pitch you something? What's the conversation like? >> It's definitely API driven. We definitely look at the API structure that the vendors provide before we select anything. That is always first of mine and also, what problem are we really trying to solve? Usually, people try to sell or try to give us something that isn't really valuable, like implementing a Cisco solution on the cloud doesn't really add a lot of value, that's where we go. >> David, what's your conversation like with suppliers? Do you have a certain new way to do things? As it becomes more agile, essentially networking, and getting more dynamic, what are some of the conversations with either in commits or new vendors that you're having? What do you require? >> Ease of use is definitely high up there. We've had some vendors come in and say, "Hey, when you go to set this up, "we're going to want to send somebody on-site." And they're going to sit with you for a day to configure it. And that's a red flag. Well, wait a minute, do we really, if one of my really talented engineers can't figure it out on his own, what's going on there and why is that? Having some ease of use and the team being comfortable with it and understanding it is really important. >> Bobby, how about you? Old days was, do a bake-off and the winner takes all. Is it like that anymore? What's evolving? Bake-off last year for but still win. But that's different now because now when you get the product, you can install the product in AWS and Azure, have it up running in a matter of minutes. So the key is that can you be operational within hours or days instead of weeks? But do we also have the flexibility to customize it, to meet your needs? Because you don't want to be put into a box with the other customers when you have needs that are past their needs. >> I can almost see the challenge that you guys are living, where you've got the cloud immediate value, depending how you can roll up any solutions, but then you might have other needs. So you've got to be careful not to buy into stuff that's not shipping. So you're trying to be proactive and at the same time, deal with what you got. How do you guys see that evolving? Because multi-cloud to me is definitely relevant, but it's not yet clear how to implement across. How do you guys look at this baked versus future solutions coming? How do you balance that? >> Again, so right now, we're taking the ad hoc approach and experimenting what the different concepts of cloud are and really leveraging the native constructs of each cloud. But there's a breaking point for sure. You don't get to scale this like someone said, and you have to focus on being able to deliver, developers their sandbox or their play area for the things that they're trying to build quickly. And the only way to do that is with some consistent orchestration layer that allows you to-- >> So you expect a lot more stuff to becoming pretty quickly in that area. >> I do expect things to start maturing quite quickly this year. >> And you guys see similar trend, new stuff coming fast? >> Yeah. Probably the biggest challenge we've got now is being able to segment within the network, being able to provide segmentation between production, non-production workloads, even businesses, because we support many businesses worldwide and isolation between those is a key criteria there. So the ability to identify and quickly isolate those workloads is key. So the CIOs that are watching are saying, "Hey, take that hill, do multi-cloud." And then you have the bottoms up organization, "Pause, you're like off a little bit, it's not how it works." What is the reality in terms of implementing as fast as possible? Because the business benefits are clear, but it's not always clear on the technology how to move that fast. What are some of the barriers, what are the blockers, what are the enablers? >> I think the reality is that you may not think you're multi-cloud, but your business is. So I think the biggest barrier there is understanding what the requirements are and how best to meet those requirements in a secure manner. Because you need to make sure that things are working from a latency perspective that things work the way they did and get out of the mind shift that it was a tier-three application and the data center, it doesn't have to be a tier-three application in the cloud. So, lift and shift is not the way to go. >> Scale is a big part of what I see is the competitive advantage by these clouds and used to be proprietary network stacks in the old days, and then open systems came, that was a good thing. But as cloud has become bigger, there's an inherent lock-in there with the scale. How do you guys keep the choice open? How are you guys thinking about interoperability? What are some of the conversations that you guys are having around those key concepts? >> When we look at from a networking perspective, it's really key for you to just enable all the class to be able to communicate between them. Developers will find a way to use the cloud that best suits their business needs. And like you said, it's whether you're in denial or not, of the multi-cloud fact that your company is in already that's it becomes really important for you to move quickly. >> Yeah. And a lot of it also hinges on how well is the provider embracing what that specific cloud is doing? So, are they swimming with Amazon or Azure and just helping facilitate things, and they're doing the heavy lifting API work for you? Or are they swimming upstream and they're trying to hack it all together in messy way? And so that helps you stay out of the lock-in because there, if they're using Amazon native tools to help you get where you need to be, it's not like Amazon is going to release something in the future that completely makes you have designed yourself into a corner. So the closer, more than cloud-native they are, the more, the easier it is to deploy. >> Which also need to be aligned in such a way that you can take advantage of those cloud-native technologies. Will it make sense? TGW is a gamechanger in terms of cost and performance. So to completely ignore that, would be wrong. But if you needed to have encryption, TGW is not encrypted, so you need to have some type of Gateway to do the VPN encryption. So, the Aviatrix tool will give you the beauty of both worlds. You can use TGW or the Gateway. Real quick on the last minute we have, I want to just get a quick feedback from you guys. I hear a lot of people say to me, "Hey, pick the best cloud for the workload you got, then figure out multicloud behind the scenes." Do you guys agree with that? Do I go more to one cloud across the whole company or this workload works great on AWS, that workload works great on this. From a cloud standpoint, do you agree with that premise, and then when is multi-cloud stitching altogether? >> From an application perspective, it can be per workload, but it can also be an economical decision, certain enterprise contracts will pull you in one direction to add value, but the network problem is still the same. >> It doesn't go away. >> You don't want to be trying to fit a square into a round hall. If it works better on that cloud provider, then it's our job to make sure that service is there and people can use it. >> I agree, you just need to stay ahead of the game, make sure that the network infrastructure is there, security is available and is multi-cloud capable. >> At the end of the day, you guys are just validating that it's the networking game now. Cloud storage, compute check, networking is where the action is. Awesome. Thanks for your insights guys, appreciate you coming on the panel. Appreciate it, thanks. (upbeat music) >> John: Our next customer panel, got great another set of cloud network architects, Justin Smith with Zuora, Justin Brodley with EllieMae and Amit Utreja with Coupa. Welcome to stage. (audience applauds) (upbeat music) >> All right, thank you. >> How are ya? >> Thank you. Thank You. >> Hey Amit. How are ya? >> Did he say it right? >> Yeah. >> Okay he's got all the cliff notes from the last session, welcome back. Rinse and repeat. We're going to go into the hood a little bit. And I think they nailed what we've been reporting, we've been having this conversation around, networking is where the action is because that's at the end of the day you got to move packet from A to B and you got workloads exchanging data. So it's really killer. So let's get started. Amit, what are you seeing as the journey of multicloud as you go under the hood and say, "Okay, I got to implement this. "I have to engineer the network, "make it enabling, make it programmable, "make it interoperable across clouds." That almost sounds impossible to me. What's your take? >> Yeah, it seems impossible but if you are running an organization which is running infrastructure as a code it is easily doable. Like you can use tools out there that's available today, you can use third party products that can do a better job. But put your architecture first, don't wait. Architecture may not be perfect, put the best architecture that's available today and be agile, to iterate and make improvements over the time. >> We get to Justin's over here, so I have to be careful when I point a question to Justin, they both have the answer. Okay, journeys, what's the journey been like? Is there phases, We heard that from Gardner, people come into multicloud and cloud native networking from different perspectives? What's your take on the journey, Justin? >> Yeah, from our perspective, we started out very much focused on one cloud and as we've started doing acquisitions, we started doing new products to the market, the need for multicloud becomes very apparent, very quickly for us. And so having an architecture that we can plug and play into and be able to add and change things as it changes is super important for what we're doing in the space. >> Justin, your journey. >> Yes. For us, we were very ad hoc oriented and the idea is that we were reinventing all the time, trying to move into these new things and coming up with great new ideas. And so rather than it being some iterative approach with our deployments that became a number of different deployments. And so we shifted that toward and the network has been a real enabler of this. There's one network and it touches whatever cloud we want it to touch, and it touches the data centers that we need it to touch, and it touches the customers that we needed to touch. Our job is to make sure that the services that are available in one of those locations are available in all of the locations. So the idea is not that we need to come up with this new solution every time, it's that we're just iterating on what we've already decided to do. >> Before we get the architecture section, I want to ask you guys a question? I'm a big fan of let the app developers have infrastructure as code, so check. But having the right cloud run that workload, I'm a big fan of that, if it works great. But we just heard from the other panel, you can't change the network. So I want to get your thoughts, what is cloud native networking? And is that the engine really, that's the enabler for this multicloud trend? What's you guys take? We'll start with Amit, what do you think about that? >> Yeah, so you're going to have workloads running in different clouds and the workloads would have affinity to one cloud or other. But how you expose that it's a matter of how you are going to build your networks. How you're going to run security. How you're going to do egress, ingress out of it so -- >> You said networking is the big problem to solve. >> Yes. >> What's the solution? What's the key pain points and problem statement? >> The key pain point for most companies is how do you take your traditionally on premise network and then blow it out to the cloud in a way that makes sense. You have IP conflicts, you have IP space, you have public IPs on premise as well as in the cloud. And how do you kind of make sense of all of that? And I think that's where tools like Aviatrix make a lot of sense in that space. >> From our side, it's really simple. It's a latency, it's bandwidth and availability. These don't change whether we're talking about cloud or data center, or even corporate IT networking. So our job when these all of these things are simplified into like, S3, for instance and our developers want to use those. We have to be able to deliver that and for a particular group or another group that wants to use just just GCP resources. We have to support these requirements and these wants, as opposed to saying, "Hey, that's not a good idea." No, our job is to enable them not to disable them. >> Do you guys think infrastructure is code? Which I love that, I think that's the future in this. We even saw that with DevOps. But as you start getting the networking, is it getting down to the network portion where its network as code? Because storage and compute working really well, we're seeing all Kubernetes on service mesh trend. Network has code, reality is it there? Is it still got work to do? >> It's absolutely there, you mentioned net DevOps and it's very real. In Coupa we build our networks through terraform and not only just terraform, build an API so that we can consistently build VNets and VPC all across in the same way. >> So you guys are doing it? >> Yup. And even security groups. And then on top and Aviatrix comes in, we can peer the networks bridge all the different regions through code. >> Same with you guys. >> Yeah. >> What do you think about this? >> Everything we deploy is done with automation and then we also run things like Lambda on top to make changes in real time, we don't make manual changes on our network. In the data center, funny enough, it's still manual but the cloud has enabled us to move into this automation mindset. And all my guys, that's what they focus on is bringing, now what they're doing in the cloud into the data center, which is kind of opposite of what it should be or what it used to be. >> It's full DevOps then? >> Yes. >> For us, it was similar on-prem is still somewhat very manual, although we're moving more and more to ninja and terraform type concepts. But everything in the production environment is code, confirmation terraform code and now coming into the data center same (mumbles). >> So I just wanted to jump in Justin Smith, one of the comment that you made, because it's something that we always talk about a lot is that the center of gravity of architecture used to be an on-prem and now it's shifted in the cloud. And once you have your strategic architecture, what do you do? You push that everywhere. So what you used to see at the beginning of cloud was pushing the architecture on-prem into cloud. Now, I want to pick up on what you said, do you others agree that the center of gravity is here, I'm now pushing what I do in the cloud back into on-prem? And then so first that and then also in the journey, where are you at from zero to 100 of actually in the journey to cloud? Are you 50% there, are you 10%? Are you evacuating data centers next year? Where are you guys at? >> Yeah, so there's there's two types of gravity that you typically are dealing with, with the migration. First is data, gravity and your data set, and where that data lives. And then the second is the network platform that wraps all that together. In our case, the data gravity solely mostly on-prem but our network is now extending out to the app tier, it's going to be in cloud. Eventually, that data, gravity will also move to cloud as we start getting more sophisticated but in our journey, we're about halfway there. About halfway through the process, we're taking a handle of lift and shift and -- >> Steve: And when did that start? >> We started about three years ago. >> Okay, okay. >> Well for Coupa it's a very different story. It started from a garage and 100% on the cloud. So it's a business plan management platform, software as a service run 100% on the cloud. >> That was was like 10 years ago, right? >> Yes. >> Yeah. >> You guys are riding the wave of the architecture. Justin I want to ask you, Zuora, you guys mentioned DevOps. Obviously, we saw the huge observability wave, which essentially network management for the cloud, in my opinion. It's more dynamic, but this is about visibility. We heard from the last panel you don't know what's being turned on or turned off from a services standpoint, at any given time. How is all this playing out when you start getting into the DevOps down (mumbles)? >> This is the big challenge for all of us is visibility. When you talk transport within a cloud, very interestingly we we have moved from having a backbone that we bought, that we own, that would be data center connectivity. Zuora's a subscription billing company, so we want to support the subscription mindset. So rather than going and buying circuits and having to wait three months to install and then coming up with some way to get things connected and resiliency and redundancy. My backbone is in the cloud. I use the cloud providers interconnections between regions to transport data across and so if you do that with their native solutions, you do lose visibility. There are areas in that that you don't get, which is why controllers and having some type of management plane is a requirement for us to do what we're supposed to do and provide consistency while doing it. >> Great conversation. I loved what you said earlier latency, bandwidth, I think availability were your top three things. Guys SLA, just do ping times between clouds it's like, you don't know what you're getting for round trip time. This becomes a huge kind of risk management, black hole, whatever you want to call it, blind spot. How are you guys looking at the interconnect between clouds? Because I can see that working from ground to cloud on per cloud but when you start dealing with multiclouds workloads, SLAs will be all over the map, won't they just inherently. How do you guys view that? >> Yeah, I think we talked about workload and we know that the workloads are going to be different in different clouds, but they're going to be calling each other. So it's very important to have that visibility, that you can see how data is flowing at what latency and what availability is there and our authority needs to operate on that. >> So use the software dashboard, look at the times and look at the latency -- >> In the old days, Strongswan Openswan you try to figure it out, in the new days you have to figure out. >> Justin, what's your answer to that because you're in the middle of it? >> Yeah, I think the key thing there is that we have to plan for that failure, we have to plan for that latency in our applications. If certain things are tracking in your SLI, certain things are planning for and you loosely coupled these services in a much more microservices approach. So you actually can handle that kind of failure or that type of unknown latency and unfortunately, the cloud has made us much better at handling exceptions in a much better way. >> You guys are all great examples of cloud native from day one. When did you have the tipping point moment or the epiphany of saying a multiclouds real, I can't ignore it, I got to factor that into all my design principles and everything you're doing? Was there a moment or was it from day one? >> There are two reasons, one was the business. So in business, there were some affinity to not be in one cloud or to be in one cloud and that drove from the business side. So as a cloud architect our responsibility was to support that business. Another is the technology, some things are really running better in, like if you're running Dotnet workload or your going to run machine learning or AI so that you would have that preference of one cloud over other. >> Guys, any thoughts on that? >> That was the bill that we got from AWS. That's what drives a lot of these conversations is the financial viability of what you're building on top of. This failure domain idea which is fairly interesting. How do I solve our guarantee against a failure domain? You have methodologies with back end direct connects or interconnect with GCP. All of these ideas are something that you have to take into account but that transport layer should not matter to whoever we're building this for. Our job is to deliver the frames and the packets, what that flows across, how you get there? We want to make that seamless. And so whether it's a public internet API call or it's a back end connectivity through direct connect, it doesn't matter. It just has to meet a contract that you've signed with your application, folks. >> Yeah, that's the availability piece. >> Justin, your thoughts on that, any comment on that? >> So actually multiclouds become something much more recent in the last six to eight months, I'd say. We always kind of had a very much an attitude of like moving to Amazon from our private cloud is hard enough, why complicate it further? But the realities of the business and as we start seeing, improvements in Google and Azure and different technology spaces, the need for multicloud becomes much more important. As well as our acquisition strategies are matured, we're seeing that companies that used to be on premise that we typically acquire are now very much already on a cloud. And if they're on a cloud, I need to plug them into our ecosystem. And so that's really changed our multicloud story in a big way. >> I'd love to get your thoughts on the clouds versus the clouds, because you compare them Amazon's got more features, they're rich with features. Obviously, the bills are high to people using them. But Google's got a great network, Google's networks pretty damn good And then you got Azure. What's the difference between the clouds? Where do they fall? Where do they peak in certain areas better than others? What are the characteristics, which makes one cloud better? Do they have a unique feature that makes Azure better than Google and vice versa? What do you guys think about the different clouds? >> Yeah, to my experience, I think the approach is different in many places. Google has a different approach very DevOps friendly and you can run your workloads with your network can span regions. But our application ready to accept that. Amazon is evolving. I remember 10 years back Amazon's network was a flat network, we would be launching servers in 10.0.0/8, right. And then the VPCs came out. >> We'll have to translate that to English for the live feed. Not good. So the VPCs concept came out, multi account came out, so they are evolving. Azure had a late start but because they have a late start, they saw the pattern and they have some mature setup on the network. >> They've got around the same price too. >> I think they're all trying to say they're equal in their own ways. I think they all have very specific design philosophies that allow them to be successful in different ways and you have to kind of keep that in mind as you architect your own solution. For example, Amazon has a very regional affinity, they don't like to go cross region in their architecture. Whereas Google is very much it's a global network, we're going to think about as a global solution. I think Google also has advantage that it's third to market and so has seen what Azure did wrong, it seeing what AWS did wrong and it's made those improvements and I think that's one of their big advantage. >> They got great scale too. Justin thoughts on the cloud. >> So yeah, Amazon built from the system up and Google built from the network down. So their ideas and approaches are from a global versus original, I agree with you completely that is the big number one thing. But the if you look at it from the outset, interestingly, the inability or the ability for Amazon to limit layer to broadcasting and what that really means from a VPC perspective, changed all the routing protocols you can use. All the things that we had built inside of a data center to provide resiliency and make things seamless to users, all of that disappeared. And so because we had to accept that at the VPC level, now we have to accept that at the WAN level. Google's done a better job of being able to overcome those things and provide those traditional network facilities to us. >> Just a great panel, we could go all day here, it's awesome. So I heard, we will get to the cloud native naive questions. So kind of think about what's naive and what's cloud, I'll ask that next but I got to ask you I had a conversation with a friend he's like, "WAN is the new LAN?" So if you think about what the LAN was at a data center, WAN is the new LAN, cause you keep talking about the cloud impact? So that means ST-WAN, the old ST-WAN kind of changing. There's a new LAN. How do you guys look at that? Because if you think about it, what LANs were for inside a premises was all about networking, high speed. But now when you take the WAN and make it, essentially a LAN, do you agree with that? And how do you view this trend? Is it good or bad or is it ugly? What you guys take on this? >> Yeah, I think it's a thing that you have to work with your application architects. So if you are managing networks and if you're a server engineer, you need to work with them to expose the unreliability that it would bring in. So the application has to handle a lot of the difference in the latencies and the reliability has to be worked through the application there. >> LAN, WAN, same concept is that BS? Can you give some insight? >> I think we've been talking about for a long time the erosion of the edge. And so is this just a continuation of that journey we've been on for last several years. As we get more and more cloud native and we talked about API's, the ability to lock my data in place and not be able to access it really goes away. And so I think this is just continuation. I think it has challenges. We start talking about WAN scale versus LAN scale, the tooling doesn't work the same, the scale of that tooling is much larger. and the need to automation is much, much higher in a WAN than it wasn't a LAN. That's why you're seeing so much infrastructure as code. >> Yeah. So for me, I'll go back again to this, it's bandwidth and its latency that define those two LAN versus WAN. But the other thing that's comes up more and more with cloud deployments is whereas our security boundary and where can I extend this secure aware appliance or set of rules to protect what's inside of it. So for us, we're able to deliver VRFs or route forwarding tables for different segments wherever we're at in the world. And so they're trusted to talk to each other but if they're going to go to someplace that's outside of their network, then they have to cross the security boundary, where we enforce policy very heavily. So for me, there's it's not just LAN, WAN it's how does environment get to environment more importantly. >> That's a great point in security, we haven't talked it yet but that's got to be baked in from the beginning, this architecture. Thoughts on security, how you guys are dealing with it? >> Yeah, start from the base, have app to app security built in. Have TLS, have encryption on the data at transit, data at rest. But as you bring the application to the cloud and they're going to go multicloud, talking to over the internet, in some places, well have app to app security. >> Our principles day, security is day zero every day. And so we always build it into our design, build into our architecture, into our applications. It's encrypt everything, it's TLS everywhere. It's make sure that that data is secure at all times. >> Yeah, one of the cool trends at RSA, just as a side note was the data in use encryption piece, which is homomorphic stuff was interesting. Alright guys, final question. We heard on the earlier panel was also trending at re:Invent, we think the T out of cloud native, it spells cloud naive. They have shirts now, Aviatrix kind of got this trend going. What does that mean to be naive? To your peers out there watching the live stream and also the suppliers that are trying to supply you guys with technology and services, what's naive look like and what's native look like? When is someone naive about implementing all this stuff? >> So for me, because we are in 100% cloud, for us its main thing is ready for the change. And you will find new building blocks coming in and the network design will evolve and change. So don't be naive and think that it's static, evolve with the change. >> I think the biggest naivety that people have is that well, I've been doing it this way for 20 years, I've been successful, it's going to be successful in cloud. The reality is that's not the case. You got to think some of the stuff a little bit differently and you need to think about it early enough, so that you can become cloud native and really enable your business on cloud. >> Yeah for me it's being open minded. Our industry, the network industry as a whole, has been very much I'm smarter than everybody else and we're going to tell everybody how it's going to be done. And we fell into a lull when it came to producing infrastructure and so embracing this idea that we can deploy a new solution or a new environment in minutes as opposed to hours, or weeks or months in some cases, is really important in and so >> - >> It's naive being closed minded, native being open minded. >> Exactly. For me that was a transformative kind of where I was looking to solve problems in a cloud way as opposed to looking to solve problems in this traditional old school way. >> All right, I know we're at a time but I got to asked one more question, so you guys so good. Give me a quick answer. What's the BS language when you, the BS meter goes off when people talk to you about solutions? What's the kind of jargon that you hear, that's the BS meter going off? What are people talking about that in your opinion you here you go, "That's total BS?" What triggers you? >> So that I have two lines out of movies if I say them without actually thinking them. It's like 1.21 gigawatts are you out of your mind from Back to the Future right? Somebody's giving you all these wiz bang things. And then Martin Maul and Michael Keaton in Mr Mom when he goes to 220, 221, whatever it takes. >> Yeah. >> Those two right there, if those go off in my mind where somebody's talking to me, I know they're full of baloney. >> So a lot of speeds and feeds, a lot of speeds and feeds a lot of -- >> Just data. Instead of talking about what you're actually doing and solutioning for. You're talking about, "Well, it does this this this." Okay to 220, 221. (laughter) >> Justin, what's your take? >> Anytime I start seeing the cloud vendors start benchmarking against each other. Your workload is your workload, you need to benchmark yourself. Don't listen to the marketing on that, that's just awful. >> Amit, what triggers you in the BS meter? >> I think if somebody explains to you are not simple, they cannot explain you in simplicity, then it's all bull shit. >> (laughs) That's a good one. Alright guys, thanks for the great insight, great panel. How about a round of applause to practitioners. (audience applauds) (upbeat music) >> John: Okay, welcome back to Altitude 2020 for the digital event for the live feed. Welcome back, I'm John Furrier with theCUBE with Steve Mullaney, CEO Aviatrix. For the next panel from Global System Integrated, the folks who are building and working with folks on their journey to multicloud and cloud-native networking. We've got a great panel, George Buckman with DXC and Derrick Monahan with WWT, welcome to the stage. (Audience applauds) >> Hey >> Thank you >> Groovy spot >> All right (upbeat music) >> Okay, you guys are the ones out there advising, building, and getting down and dirty with multicloud and cloud-native networking, we just heard from the customer panel. You can see the diversity of where people come in to the journey of cloud, it kind of depends upon where you are, but the trends are all clear, cloud-native networking, DevOps, up and down the stack, this has been the main engine. What's your guys' take of this journey to multicloud? What do you guys think? >> Yeah, it's critical, I mean we're seeing all of our enterprise customers enter into this, they've been through the migrations of the easy stuff, ya know? Now they're trying to optimize and get more improvements, so now the tough stuff's coming on, right? They need their data processing near where their data is. So that's driving them to a multicloud environment. >> Yeah, we've heard some of the Edge stuff, I mean, you guys are-- >> Exactly. >> You've seen this movie before, but now it's a whole new ballgame, what's your take? Yeah, so, I'll give you a hint, our practice is not called the cloud practice, it's the multicloud practice, and so if that gives you a hint of how we approach things. It's very consultative. And so when we look at what the trends are, like a year ago. About a year ago we were having conversations with customers, "Let's build a data center in the cloud. Let's put some VPCs, let's throw some firewalls, let's put some DNS and other infrastructure out there and let's hope it works." This isn't a science project. What we're starting to see is customers are starting to have more of a vision, we're helping with that consultative nature, but it's totally based on the business. And you've got to start understanding how lines of business are using the apps and then we evolve into the next journey which is a foundational approach to-- >> What are some of the problems some of your customers are solving when they come to you? What are the top things that are on their mind, obviously the ease of use, agility, all that stuff, what specifically are they digging into? >> Yeah, so complexity, I think when you look at a multicloud approach, in my view is, network requirements are complex. You know, I think they are, but I think the approach can be, "Let's simplify that." So one thing that we try to do, and this is how we talk to customers is, just like you simplify in Aviatrix, simplifies the automation orchestration of cloud networking, we're trying to simplify the design, the plan, and implementation of the infrastructure across multiple workloads, across multiple platforms. And so the way we do it, is we sit down, we look at not just use cases, not just the questions we commonly anticipate, we actually build out, based on the business and function requirements, we build out a strategy and then create a set of documents, and guess what? We actually build it in a lab, and that lab that we platform rebuilt, proves out this reference architectural actually works. >> Absolutely, we implement similar concepts. I mean, they're proven practices, they work, right? >> But George, you mentioned that the hard part's now upon us, are you referring to networking, what specifically were you getting at there when you said, "The easy part's done, now the hard part?" >> So for the enterprises themselves, migrating their more critical apps or more difficult apps into the environments, ya know, we've just scratched the surface, I believe, on what enterprises are doing to move into the cloud, to optimize their environments, to take advantage of the scale and speed to deployment and to be able to better enable their businesses. So they're just now really starting to-- >> So do you guys see what I talked about? I mean, in terms of that Cambrian explosion, I mean, you're both monster system integrators with top fortune enterprise customers, you know, really rely on you for guidance and consulting and so forth, and deploy their networks. Is that something that you've seen? I mean, does that resonate? Did you notice a year and a half ago all of a sudden the importance of cloud for enterprise shoot up? >> Yeah, I mean, we're seeing it now. >> Okay. >> In our internal environment as well, ya know, we're a huge company ourselves, customer zero, our internal IT, so, we're experiencing that internally and every one of our other customers as well. >> So I have another question and I don't know the answer to this, and a lawyer never asks a question that you don't know the answer to, but I'm going to ask it anyway. DXC and WWT, massive system integrators, why Aviatrix? >> Great question, Steve, so I think the way we approach things, I think we have a similar vision, a similar strategy, how you approach things, how we approach things, at World Wide Technology. Number one, we want a simplify the complexity. And so that's your number one priority. Let's take the networking, let's simplify it, and I think part of the other point I'm making is we see this automation piece as not just an after thought anymore. If you look at what customers care about, visibility and automation is probably at the top three, maybe the third on the list, and I think that's where we see the value. I think the partnership that we're building and what I get excited about is not just putting yours and our lab and showing customers how it works, it's co-developing a solution with you. Figuring out, "Hey, how can we make this better?" >> Right >> Visibility is a huge thing, just in security alone, network everything's around visibility. What automation do you see happening, in terms of progression, order of operations, if you will? What's the low hanging fruit? What are people working on now? What are some of the aspirational goals around when you start thinking about multicloud and automation? >> So I wanted to get back to his question. >> Answer that question. >> I wanted to answer your question, you know, what led us there and why Aviatrix. You know, in working some large internal IT projects, and looking at how we were going to integrate those solutions, you know, we like to build everything with recipes. Network is probably playing catch-up in the DevOps world but with a DevOps mindset, looking to speed to deploy, support, all those things, so when you start building your recipe, you take a little of this, a little of that, and you mix it all together, well, when you look around, you say, "Wow, look, there's this big bag of Aviatrix. "Let me plop that in. That solves a big part "of my problems that I had, the speed to integrate, "the speed to deploy, and the operational views "that I need to run this." So that was what led me to-- >> John: So how about reference architectures? >> Yeah, absolutely, so, you know, they came with a full slate of reference architectures already out there and ready to go that fit our needs, so it was very easy for us to integrate those into our recipes. >> What do you guys think about all the multi-vendor inter-operability conversations that have been going on? Choice has been a big part of multicloud in terms of, you know, customers want choice, they'll put a workload in the cloud if it works, but this notion of choice and interoperability has become a big conversation. >> It is, and I think that our approach, and that's the way we talk to customers is, "Let's speed and de-risk that decision making process, "and how do we do that?" Because interoperability is key. You're not just putting, it's not just a single vendor, we're talking, you know, many many vendors, I mean think about the average number of cloud applications a customer uses, a business, an enterprise business today, you know, it's above 30, it's skyrocketing and so what we do, and we look at it from an interoperability approach is, "How do things inter-operate?" We test it out, we validate it, we build a reference architecture that says, "These are the critical design elements, "now let's build one with Aviatrix "and show how this works with Aviatrix." And I think the important part there, though, is the automation piece that we add to it and visibility. So I think the visibility is what I see lacking across industry today. >> In cloud-native that's been a big topic. >> Yep >> Okay, in terms of Aviatrix, as you guys see them coming in, they're one of the ones that are emerging and the new brands emerging with multicloud, you've still got the old guard encumbered with huge footprints. How are customers dealing with that kind of component in dealing with both of them? >> Yeah, I mean, we have customers that are ingrained with a particular vendor and you know, we have partnerships with many vendors. So our objective is to provide the solution that meets that client. >> John: And they all want multi-vendor, they all want interoperability. >> Correct. >> All right, so I got to ask you guys a question while we were defining Day-2 operations. What does that mean? You guys are looking at the big business and technical components of architecture, what does Day-2 operations mean, what's the definition of that? >> Yeah, so I think from our perspective, with my experience, we, you know, Day-2 operations, whether it's not just the orchestration piece in setting up and let it automate and have some, you know, change control, you're looking at this from a Day-2 perspective, "How do I support this ongoing "and make it easy to make changes as we evolve?" The cloud is very dynamic. The nature of how fast it's expanding, the number features is astonishing. Trying to keep up to date with the number of just networking capabilities and services that are added. So I think Day-2 operations starts with a fundamental understanding of building out supporting a customer's environments, and making the automation piece easy from a distance, I think. >> Yeah and, you know, taking that to the next level of being able to enable customers to have catalog items that they can pick and choose, "Hey I need this network connectivity "from this cloud location back to this on-prem." And being able to have that automated and provisioned just simply by ordering it. >> For the folks watching out there, guys, take a minute to explain as you guys are in the trenches doing a lot of good work. What are some of the engagements that you guys get into? How does that progress? What happens there, they call you up and say, "Hey I need some multicloud," or you're already in there? I mean, take us through how someone can engage to use a global SI, they come in and make this thing happen, what's the typical engagement look like? >> Derrick: Yeah, so from our perspective, we typically have a series of workshops in the methodology that we kind of go along the journey. Number one, we have a foundational approach. And I don't mean foundation meaning the network foundation, that's a very critical element, we got to factor in security and we got to factor in automation. So when you think about foundation, we do a workshop that starts with education. A lot of times we'll go in and we'll just educate the customer, what is VPC sharing? You know, what is a private link in Azure? How does that impact your business? We have customers that want to share services out in an ecosystem with other customers and partners. Well there's many ways to accomplish that. Our goal is to understand those requirements and then build that strategy with them. >> Thoughts George, on-- >> Yeah, I mean, I'm one of the guys that's down in the weeds making things happen, so I'm not the guy on the front line interfacing with the customers every day. But we have a similar approach. We have a consulting practice that will go out and apply their practices to see what those-- >> And when do you parachute in? >> Yeah, when I parachute in is, I'm on the back end working with our offering development leads for networking, so we understand and are seeing what customers are asking for and we're on the back end developing the solutions that integrate with our own offerings as well as enable other customers to just deploy quickly to meet their connectivity needs. So the patterns are similar. >> Right, final question for you guys, I want to ask you to paint a picture of what success looks like. You don't have to name customers, you don't have to get in and reveal who they are, but what does success look like in multicloud as you paint a picture for the folks here and watching on the live stream, if someone says, "Hey I want to be multicloud, I got to to have my operations Agile, I want full DevOps, I want programmability and security built in from Day-zero." What does success look like? >> Yeah, I think success looks like this, so when you're building out a network, the network is a harder thing to change than some other aspects of cloud. So what we think is, even if you're thinking about that second cloud, which we have most of our customers are on two public clouds today, they might be dabbling in it. As you build that network foundation, that architecture, that takes in to consideration where you're going, and so once we start building that reference architecture out that shows, this is how to approach it from a multicloud perspective, not a single cloud, and let's not forget our branches, let's not forget our data centers, let's not forget how all this connects together because that's how we define multicloud, it's not just in the cloud, it's on-prem and it's off-prem. And so collectively, I think the key is also is that we provide them an HLD. You got to start with a high level design that can be tweaked as you go through the journey but you got to give it a solid structural foundation, and that networking which we think, most customers think as not the network engineers, but as an after thought. We want to make that the most critical element before you start the journey. >> George, from your seat, how does success look for you? >> So, you know it starts out on these journeys, often start out people not even thinking about what is going to happen, what their network needs are when they start their migration journey to the cloud. So I want, success to me looks like them being able to end up not worrying about what's happening in the network when they move to the cloud. >> Steve: Good point. >> Guys, great insight, thanks for coming on and sharing. How about a round of applause for the global system integrators? (Audience applauds) (Upbeat music) >> The next panel is the AVH certified engineers, also known as ACEs. This is the folks that are certified, they're engineering, they're building these new solutions. Please welcome Toby Foss from Informatica, Stacey Lanier from Teradata, and Jennifer Reed with Viqtor Davis to the stage. (upbeat music) (audience cheering) (panelists exchanging pleasantries) >> You got to show up. Where's your jacket Toby? (laughing) You get it done. I was just going to rib you guys and say, where's your jackets, and Jen's got the jacket on. Okay, good. >> Love the Aviatrix, ACEs Pilot gear there above the Clouds. Going to new heights. >> That's right. >> So guys Aviatrix aces, I love the name, think it's great, certified. This is all about getting things engineered. So there's a level of certification, I want to get into that. But first take us through the day in the life of an ACE, and just to point out, Stacy is a squad leader. So he's, he's like a-- >> Squadron Leader. >> Squadron Leader. >> Yeah. >> Squadron Leader, so he's got a bunch of ACEs underneath him, but share your perspective a day in the Life. Jennifer, we'll start with you. >> Sure, so I have actually a whole team that works for me both in the North America, both in the US and in Mexico. So I'm eagerly working to get them certified as well, so I can become a squad leader myself. But it's important because one of the critical gaps that we've found is people having the networking background because you graduate from college, and you have a lot of computer science background, you can program you've got Python, but networking in packets they just don't get. So, just taking them through all the processes that it's really necessary to understand when you're troubleshooting is really critical. Because you're going to get an issue where you need to figure out where exactly is that happening on the network, Is my issue just in the VPCs? Is it on the instance side is a security group, or is it going on prem? This is something actually embedded within Amazon itself? I mean, I troubleshot an issue for about six months going back and forth with Amazon, and it was the VGW VPN. Because they were auto scaling on two sides, and we ended up having to pull out the Cisco's, and put in Aviatrix so I could just say, " okay, it's fixed," and actually helped the application teams get to that and get it solved. But I'm taking a lot of junior people and getting them through that certification process, so they can understand and see the network, the way I see the network. I mean, look, I've been doing this for 25 years when I got out. When I went in the Marine Corps, that's what I did, and coming out, the network is still the network. But people don't get the same training they got in the 90s. >> Was just so easy, just write some software, and they were, takes care of itself. I know, it's pixie dust.  >> I'll come back to that, I want to come back to that, the problem solved with Amazon, but Toby. >> I think the only thing I have to add to that is that it's always the network's fault. As long as I've been in networking, it's always been the network's fault. I'm even to this day, it's still the network's fault, and part of being a network guy is that you need to prove when it is and when it's not your fault. That means you need to know a little bit about 100 different things, to make that work. >> Now you got a full stack DevOps, you got to know a lot more times another hundred. >> Toby: And the times are changing, yeah. >> This year the Squadron Leader and get that right. What is the Squadron Leader firstly? Describe what it is. >> I think is probably just leading on the network components of it. But I think, from my perspective, when to think about what you asked them was, it's about no issues and no escalations. So of my day is like that, I'm happy to be a squadron leader. >> That is a good outcome, that's a good day. >> Yeah, sure, it is. >> Is there good days? You said you had a good day with Amazon? Jennifer, you mentioned the Amazon, and this brings up a good point, when you have these new waves come in, you have a lot of new things, new use cases. A lot of the finger pointing it's that guy's problem , that girl's problems, so how do you solve that, and how do you get the Young Guns up to speed? Is there training, is it this where the certification comes in? >> This is where the certifications really going to come in. I know when we got together at Reinvent, one of the questions that we had with Steve and the team was, what should our certification look like? Should we just be teaching about what AVH troubleshooting brings to bear, but what should that be like? I think Toby and I were like, No, no, no, no. That's going a little too high, we need to get really low because the better someone can get at actually understanding what's actually happening in the network, and where to actually troubleshoot the problem, how to step back each of those processes. Because without that, it's just a big black box, and they don't know. Because everything is abstracted, in Amazon and in Azure and in Google, is abstracted, and they have these virtual gateways, they have VPNs, that you just don't have the logs on, is you just don't know. So then what tools can you put in front of them of where they can look? Because there are full logs. Well, as long as they turned on the flow logs when they built it, and there's like, each one of those little things that well, if they'd had decided to do that, when they built it, it's there. But if you can come in later to really supplement that with training to actual troubleshoot, and do a packet capture here, as it's going through, then teaching them how to read that even. >> Yeah, Toby, we were talking before we came on up on stage about your career, you've been networking all your time, and then, you're now mentoring a lot of younger people. How is that going? Because the people who come in fresh they don't have all the old war stories, like they don't talk about it, There's never for, I walk in bare feet in the snow when I was your age, I mean, it's so easy now, right, they say. What's your take on how you train the young People. >> So I've noticed two things. One is that they are up to speed a lot faster in generalities of networking. They can tell you what a network is in high school level now, where I didn't learn that til midway through my career, and they're learning it faster, but they don't necessarily understand why it's that way here. Everybody thinks that it's always slash 24 for a subnet, and they don't understand why you can break it down smaller, why it's really necessary. So the ramp up speed is much faster for these guys that are coming in. But they don't understand why and they need some of that background knowledge to see where it's coming from, and why is it important, and that's old guys, that's where we thrive. >> Jennifer, you mentioned you got in from the Marines, it helps, but when you got into networking, what was it like then and compare it now? Because most like we heard earlier static versus dynamic Don't be static is like that. You just set the network, you got a perimeter. >> Yeah, no, there was no such thing. So back in the day, I mean, we had Banyan vines for email, and we had token ring, and I had to set up token ring networks and figure out why that didn't work. Because how many of things were actually sharing it. But then actually just cutting fiber and running fiber cables and dropping them over shelters to plug them in and all crap, they swung it too hard and shattered it and now I got to figure eight Polish this thing and actually should like to see if it works. I mean, that was the network , current cat five cables to run an Ethernet, and then from that I just said, network switches, dumb switches, like those were the most common ones you had. Then actually configuring routers and logging into a Cisco router and actually knowing how to configure that. It was funny because I had gone all the way up, I was the software product manager for a while. So I've gone all the way up the stack, and then two and a half, three years ago, I came across to work with Entity group that became Viqtor Davis. But we went to help one of our customers Avis, and it was like, okay, so we need to fix the network. Okay, I haven't done this in 20 years, but all right, let's get to it. Because it really fundamentally does not change. It's still the network. I mean, I've had people tell me, Well, when we go to containers, we will not have to worry about the network. And I'm like, yeah, you don't I do. >> And that's within programmability is a really interesting, so I think this brings up the certification. What are some of the new things that people should be aware of that come in with the Aviatrix A certification? What are some of the highlights? Can you guys share some of the highlights around the certifications? >> I think some of the importance is that it doesn't need to be vendor specific for network generality or basic networking knowledge, and instead of learning how Cisco does something, or how Palo Alto does something, We need to understand how and why it works as a basic model, and then understand how each vendor has gone about that problem and solved it in a general. That's true in multicloud as well. You can't learn how Cloud networking works without understanding how AWS and Azure and GCP are all slightly the same but slightly different, and some things work and some things don't. I think that's probably the number one take. >> I think having a certification across Clouds is really valuable because we heard the global s eyes as you have a business issues. What does it mean to do that? Is it code, is it networking? Is it configurations of the Aviatrix? what is, he says,the certification but, what is it about the multiCloud that makes it multi networking and multi vendor? >> The easy answer is yes, >> Yes is all of us. >> All of us. So you got to be in general what's good your hands and all You have to be. Right, it takes experience. Because every Cloud vendor has their own certification. Whether that's SOPs and advanced networking and event security, or whatever it might be, yeah, they can take the test, but they have no idea how to figure out what's wrong with that system. The same thing with any certification, but it's really getting your hands in there, and actually having to troubleshoot the problems, actually work the problem, and calm down. It's going to be okay. I mean, because I don't know how many calls I've been on or even had aviators join me on. It's like, okay, so everyone calm down, let's figure out what's happening. It's like, we've looked at that screen three times, looking at it again is not going to solve that problem, right. But at the same time, remaining calm but knowing that it really is, I'm getting a packet from here to go over here, it's not working, so what could be the problem? Actually stepping them through those scenarios, but that's like, you only get that by having to do it, and seeing it, and going through it, and then you get it. >> I have a question, so, I just see it. We started this program maybe six months ago, we're seeing a huge amount of interest. I mean, we're oversubscribed on all the training sessions. We've got people flying from around the country, even with Coronavirus, flying to go to Seattle to go to these events where we're subscribed, is that-- >> A good emerging leader would put there. >> Yeah. So, is that something that you see in your organizations? Are you recommending that to people? Do you see, I mean, I'm just, I guess I'm surprised or not surprised. But I'm really surprised by the demand if you would, of this MultiCloud network certification because there really isn't anything like that. Is that something you guys can comment on? Or do you see the same things in your organization? >> I see from my side, because we operate in a multiCloud environments that really helps and some beneficial for us. >> Yeah, true. I think I would add that networking guys have always needed to use certifications to prove that they know what they know. >> Right. >> It's not good enough to say, Yeah, I know IP addresses or I know how a network works. A couple little check marks or a little letters body writing helps give you validity. So even in our team, we can say, Hey, we're using these certifications to know that you know enough of the basics and enough of the understandings, that you have the tools necessary, right. >> I guess my final question for you guys is, why an ACE certification is relevant, and then second part is share with the live stream folks who aren't yet ACE certified or might want to jump in to be aviatrix certified engineers. Why is it important, so why is it relevant and why should someone want to be a certified aviatrix certified engineer? >> I think my views a little different. I think certification comes from proving that you have the knowledge, not proving that you get a certification to get an army there backwards. So when you've got the training and the understanding and you use that to prove and you can, like, grow your certification list with it, versus studying for a test to get a certification and have no understanding of it. >> Okay, so that who is the right person that look at this and say, I'm qualified, is it a network engineer, is it a DevOps person? What's your view, a little certain. >> I think Cloud is really the answer. It's the, as we talked like the edges getting eroded, so is the network definition getting eroded? We're getting more and more of some network, some DevOps, some security, lots and lots of security, because network is so involved in so many of them. That's just the next progression. >> Do you want to add something there? >> I would say expand that to more automation engineers, because we have those now, so I probably extend it beyond this one. >> Jennifer you want to? >> Well, I think the training classes themselves are helpful, especially the entry level ones for people who may be "Cloud architects" but have never done anything in networking for them to understand why we need those things to really work, whether or not they go through to eventually get a certification is something different. But I really think fundamentally understanding how these things work, it makes them a better architect, makes them better application developer. But even more so as you deploy more of your applications into the Cloud, really getting an understanding, even from people who have traditionally done Onprem networking, they can understand how that's going to work in Cloud. >> Well, I know we've got just under 30 seconds left. I want to get one more question then just one more, for the folks watching that are maybe younger than, that don't have that networking training. From your experiences each of you can answer why should they know about networking, what's the benefit? What's in it for them? Motivate them, share some insights of why they should go a little bit deeper in networking. Stacy, we'll start with you, we'll go then. >> I'll say it's probably fundamental, right? If you want to deliver solutions, networking is the very top. >> I would say if you, fundamental of an operating system running on a machine, how those machines start together is a fundamental changes, something that start from the base and work your way up. >> Jennifer? >> Right, well, I think it's a challenge. Because you've come from top down, now you're going to start looking from bottom up, and you want those different systems to cross-communicate, and say you've built something, and you're overlapping IP space, note that that doesn't happen. But how can I actually make that still operate without having to re IP re platform. Just like those challenges, like those younger developers or assistant engineers can really start to get their hands around and understand those complexities and bring that forward in their career. >> They get to know then how the pipes are working, and they're got to know it--it's the plumbing. >> That's right, >> They got to know how it works, and how to code it. >> That's right. >> Awesome, thank you guys for great insights, ACE Certified Engineers, also known as ACEs, give them a round of applause. (audience clapping) (upbeat music) >> Thank you, okay. All right, that concludes my portion. Thank you, Steve Thanks for having me. >> John, thank you very much, that was fantastic. Everybody round of applause for John Furrier. (audience applauding) Yeah, so great event, great event. I'm not going to take long, we got lunch outside for the people here, just a couple of things. Just to call the action, right? So we saw the ACEs, for those of you out of the stream here, become a certified, right, it's great for your career, it's great for not knowledge, is fantastic. It's not just an aviator's thing, it's going to teach you about Cloud networking, MultiCloud networking, with a little bit of aviatrix, exactly like the Cisco CCIE program was for IP network, that type of the thing, that's number one. Second thing is learning, right? So there's a link up there to join the community. Again like I started this, this is a community, this is the kickoff to this community, and it's a movement. So go to community.avh.com, starting a community of multiCloud. So get get trained, learn. I'd say the next thing is we're doing over 100 seminars across the United States and also starting into Europe soon, we will come out and we'll actually spend a couple hours and talk about architecture, and talk about those beginning things. For those of you on the livestream in here as well, we're coming to a city near you, go to one of those events, it's a great way to network with other people that are in the industry, as well as to start alone and get on that MultiCloud journey. Then I'd say the last thing is, we haven't talked a lot about what Aviatrix does here, and that's intentional. We want you leaving with wanting to know more, and schedule, get with us and schedule a multi hour architecture workshop session. So we sit down with customers, and we talk about where they're at in that journey, and more importantly, where they're going, and define that end state architecture from networking, computer, storage, everything. Everything you've heard today, everybody panel kept talking about architecture, talking about operations. Those are the types of things that we solve, we help you define that canonical architecture, that system architecture, that's yours. So many of our customers, they have three by five, plotted lucid charts, architecture drawings, and it's the customer name slash Aviatrix, network architecture, and they put it on their whiteboard. That's the most valuable thing they get from us. So this becomes their 20 year network architecture drawing that they don't do anything without talking to us and look at that architecture. That's what we do in these multi hour workshop sessions with customers, and that's super, super powerful. So if you're interested, definitely call us, and let's schedule that with our team. So anyway, I just want to thank everybody on the livestream. Thank everybody here. Hopefully it was it was very useful. I think it was, and Join the movement, and for those of you here, join us for lunch, and thank you very much. (audience applauding) (upbeat music)

(upbeat music) >> From our studios in the heart of Silicon Valley, Palo Alto, California this is a CUBE Conversation. >> Hi I'm Peter Burris and welcome to another CUBE Conversation. from our Palo Alto studios. Now as we do with all CUBE Conversations, we want to have a great conversation about an interesting topic with a thought leader in the industry and that's exactly what we're doing today. The topic we're going to breach is why is it that networking remains so expensive. If we go back over the past 20 years of computing, we've seen dramatic price performance improvements in virtually every single sector of infrastructure, but networking persists as a relatively expensive technology arena despite the fact that we're moving into an era that is going to become increasingly depending upon networks and to better understand both what the nature of the problem is and how we're going to move forward with a solution, we've got Dominic Wilde with us today. Dominic is a CEO of SnapRoute. Dominic, welcome back to theCUBE. >> Thank you. Great to be here. >> So tell us, let's start. Tell us a little bit about SnapRoute. Tell us about yourself and SnapRoute and then we'll get into it. >> Sure, sure. So SnapRoute is delivering basically a new paradigm in network operating systems. We're delivering a cloud native network operating system that's designed from the ground up to integrate in this, into this new world of cloud architecturally. It's a fully containerized microservices architecture from the ground up. And what that does is it enables an operator to deliver fast time-to-service for applications, to always be secure and up-to-date with security compliance and also to drive significant operational efficiencies as well. So we believe that we have a really strong value proposition for the industry here, particularly in the age of cloud. But we're also marrying to that architectural innovation some economic innovation as well. An economic disruption and we believe that the time is really right here for networking to step up its game effective. >> Oh let's talk a bit about that 'cause if I'm a CIO, >> Yeah. >> every year for a variety of reasons, every other business comes to me and says, okay, you got to give me back 10%. We want you to do more. And more is law and other physical features of how computing work has been very kind to me. >> Right. >> I've been able to provide some of that back because I was able to get cheaper servers and then open source allowed me to get cheaper operating systems and even applications got cheaper and then SAS comes along and the cloud comes along. Networking is a hold out. Why has networking been the hold out? >> Yeah, well simply stated, I think it's because networking has not embraced or driven software economics, whereas compute has in many different aspects, if you look at the sort of timeline of what's happened in recent history in compute and so to parallel that with networking, compute got Linux. And that gave an architectural innovation, it gave greater control and the opportunity for operators to innovate on their own. But it also drove this big economic disruption. The prices really came down. Then came virtualization, of course there was the opportunity there to drive down that the prices again because I don't need five servers I only need one. And another great innovation in terms of operator control. And here we are now in the age of containers and cloud native and get much greater, sort of performance benefits of going containers on bare metal and so all of these things have happened where you have an architectural innovation married together with an economic innovation >> at the software level >> At the software level. And this has not happened in networking because in networking we've continued to really treat the network as an appliance. Its proprietary integrated packaged switches, routers, et cetera. And quite frankly, we got Linux. We got Linux in networking but the price has gone up because there was, APIs are introduced and programmability, and there's much greater value there so therefore were charged more. And then virtualization came along, and SDN, the SDN movement. And there was great hope, I think, in the industry that this would drive a real sort of economic revolution in networking. But what happened was that, rather than really addressing the actual network itself and the software issues with the network itself that make it brittle and very difficult to manage, we got overlays and we added overlays over the top and abstracted the underlying network and added more layers of complexity and expense. And then here we are in the container age and one of the things that we've done here at SnapRoute is we've said, look, you know, let's embrace containers fundamentally and let's build an operating system using that technology with DevOps principles to deliver an architecture that lends itself to the task at hand, which is the move to cloud and how can we enable organizations to move quickly to cloud. And let's face it. Cloud is a distributed architecture and so >> Very much so. >> by building a network operating system with an architecture that is essentially a distributed architecture, it gives us some advantages. But let's marry together that, let's put the economic, software economics in there as well. And quite frankly we tried this around about the time of virtualization, the sort of white box networking movement happened and again there was great hope that, hey this means I can get cheaper networking. >> But we'll explain that. White box, you mean, is that effectively you're able to get commodity hardware >> Yeah. >> and hopefully you could just drop your network operating system software on top of it and replace these full stack switches and these full stack riders that were supporting 50, 60% margins. >> That's right, exactly right. And I can go direct to an ODM. I can buy the hardware at the same, if I buy the volumes at the same cost that an OEM would buy them at, go find myself some software or software operating system and put it on top, up I go, it should be cheaper. The reality was that what happened in the industry is that the software that you could buy, the disaggregated software operating systems absorbed the savings that you got from a lower-cost hardware and so everything evened out and actually, quite frankly the white box has not delivered on its promise. It has for the hyperscale vendors who are buying a massive, massive volume and are building their own operating systems, built for purpose, but in the broader industry we haven't seen those advantages. And so what we did at SnapRoute is we took a big step back and we said, look, if you really need software economics here then as a software company we need to step up. We need to be >> You're a software company and not a networking company. >> We're a software company, I mean, at the end of the day, we're delivering a network operating system >> Got it. >> but we view it as it's an application >> Sure. >> And the architecture we've built is not a traditional monolithic Linux sort of blob as it were. We've really embraced the DevOps culture, the DevOps paradigms. We've been embraced all this sort of, the application and software developer paradigms of how you build a state-of-the-art cloud class application today. And that's what we've done with the network operating system. We've taken that approach to deliver what is effectively a distributed application. >> So let's build on that a little bit because the, as you said, the white box approach doesn't work that well in the networking world largely because some of these network operating systems companies were delivering these very large monolithic pieces of software >> Right. >> that really were just layers on top of the network that often people didn't need and generated a significant amount of lock-in so that was always questionable to begin with. The approach that you're taking, using containers, modern software techniques, cloud native approaches, allows, it seems to be two benefits, let me see if I got this right. >> Yeah, sure. >> Benefit number one is it looks like a set of programmable services to the DevOps world, which is good. >> Yeah. >> And number two because it doesn't have this monolithic footprint you can appropriately skinny it up so that it now does make sense >> Right. >> to think in terms of a new economic model. >> Yeah. >> because you can get access to the services you want, you don't have the security, you don't have the footprint associated with... >> Yeah. >> Talk about that. >> Yeah it's, I mean, it's if you look at it architecturally and you're spot on it but if you look at it architecturally and let's for a moment empathize with the net ops teams because their job has been to take something, take a network using tools and products that the industry have given them and try to live in a very dynamic world, the cloud world, the new class of enterprise. But what they've been given is a set of tools and a set of products that only enable them to build a very static and very brittle, distributed sort of, system, distributed network. And these are, they just haven't had the tools to work with. >> They're largely separate from the services that were running on the network. >> Very much so. The net ops has been siloed, the network is more siloed. Our founders came from Apple, where they ran Apple's biggest data centers and one of things they tell me is that the sort of peer pressure and stuff was that if there was a security vulnerability that had to be patched or something that the DevOps team would come in, the compute team would sort of say, okay, we can patch that in couple of hours, a couple of days at worst. And there's the networking team, they would sit there and in the corner of the room, very shy, sort of saying, well it will take us several weeks to get back to you with a plan for a plan and then we've got to wait for an outage window and we've got a, and it could take months. And so net ops has had this really, really difficult task of living in this dynamic world with everybody else. But the issue here is that if you can deliver the tools, the set of tools and that means an operating system that is designed to be dynamic in the first place, then you should also not only be able to reduce the operational costs overall because now you enable NetOps teams to move faster and stuff. But you have to be able to deliver an economic value in terms of Opex because otherwise there's no reason for anybody to move. It's probably safer to stay where you are. It's probably, Change, it always comes with some kind of cost and some kind of risk. And by the very nature NetOps teams have become risk-averse because any time they changed anything the network could break so they have had to start live in a world of no. Every time somebody comes to them and says, hey I have an application, I need you to do this, that and the other, the answer is no, because I don't want to change anything. I'm measured on uptime. That is the standard measure that networking teams are measured by. And if I'm measured by uptime then I don't want to change anything. >> Well, the server world we used to talk about how the cost of the change was underwritten by the improvements in price performance and in many respects what you're saying is by taking a new approach you are paying for the cost and risk of the change because you're jumping to a new economic model >> Right. >> that could fundamentally put you on a different vector not only for new economics but also creates new classes of options in the network that's much more cloud-like. >> Yes, exactly. I mean it's, And this is I believe a fundamental of the sort of cloud thinking, cloud mentality and the reason that we're all trying to get to cloud is exactly because it gives you, it gives you more flexibility at a lower cost. I mean, everybody's embracing the public cloud. Now what we've seen is some recent numbers that are coming out of Lyft that they've had to commit 300 million dollars through 2021 to the public cloud provider and those numbers are scary and terrifying for a lot of companies. So going all-in on the public cloud maybe is not the right way to go. But living in a hybrid world where you have some on-prem, you have some public cloud and working out which model is best for your company is the right way to go. And the network has been an inhibitor to that because if you have to have a different on-prem network model than is being used in the cloud and the public cloud or use the virtual services there well now you're adding a bunch of cost operationally 'cause you have to do two different things. You have to figure all this out >> And very importantly you're losing a lot of the options that the cloud provides you and the whole point is to get a better, get a better cost profile to be able to use new techniques and approaches >> Right. >> to building applications but also to be on a vector that provides new types of options in the future so that you don't have to worry about this network having these limits and that network having a different set of limits. And so >> Right. >> it brings a more unified approach to say, this is a common resource to the business that is these profiles, this physical characteristic, these software characteristics, and these economic characteristics. >> Exactly. >> Yeah, it's a service book mentality. It's like, hey I want to have us a set, a list of services that I subscribe to and I just pick and choose. Or innovate new ones and that's been very difficult in the legacy networking world. So yeah, we're, the approach is to come in with this, this architectural change that it enables the innovation, it enables that service mentality. It enables, it frees up the business to be more dynamic, to be more responsive and agile. But give the economic driver. Do it in software economics, allows you to kick-start that, allows you to gain the momentum within your organization to say hey we should try something new because there is enough savings here and there are significant savings here. So to give you an idea. What we deliver at the system level so if you take a white box, an ODM box and you take our software and put the two together. Install one on the other at the system level. We're about 50% the price of any of the legacy, incumbent vendors, so it's half the price now. Previously in white box what people have found is actually when they were trying to do stuff themselves the price is pretty much the same if not a little bit more expensive once you add in the operational costs. So we're really actually giving the opportunity to make white box successful. We're giving the opportunity to deliver control and the opportunity to innovate to operators, but most significantly when you're going to talk to your CFO or your CIO or anybody else we're driving the price down so significantly that >> Well I was doing quick calculation on my head, 50% savings on network and a sizable enterprise translates into about two-tenths of a margin point for the business. >> Yeah. >> Not bad. Dominic Wilde, CEO of SnapRoute. Thanks very much for talking to us on theCUBE today. >> Thanks, mate, thanks. >> And once again I'm Peter Burris and this has been another CUBE Conversation. Until next time. (dramatic music)

>> Live from Seattle, Washington, it's theCUBE, covering KubeCon and Cloud Native Con North America 2018. Brought to you by RedHat, the Cloud Native Computing Foundation and its ecosystem partners. >> Okay welcome back everyone we're here live in Seattle for KubeCon and Cloud Native Con. I'm John Furrier your host, Stu Miniman from Wikibon here. Next guests Anthony Lye, whose the senior vice president general manager of Cloud Data Services at NetApp, and Jonsi Stergesson, CTO and VP of Cloud Services. Great to have you guys on, great to see you again Anthony. >> As always thank you. >> So first I want to get out there we talked lots in the Kube lounge just to reset. The value parsons of NetApp have significantly been enhanced with the cloud. What is that value proposition? What have you guys seen the explosive headroom for value creation that you guys are enabling with NetApp and the cloud? >> You know what I think NetApp has done over now, probably five years, is really pushed itself to embrace the cloud. To recognize that the cloud is a very important part of everybody's IT infrastructure whether it's an extension of the existing IT infrastructure for things like DR or backup or whether it's the primary platform for legacy workloads or, as we're all here to do, to discuss the refactoring and rebuilding of applications around microservices. I think NetApp chose, unlike all of the traditional storage vendors, to see the cloud as an opportunity and I think it's helped the company and it's helped our customers to operate in what is, I think, is by default now, the end state for many companies is hybrid cloud. >> You guys also made some good moves early on with the cloud. We've documented certainly on SiliconANGLE and theCUBE early on. And then as flash comes in for performance, now you've got compute, storage and networking all being optimized in the cloud, creates app developers an environment where it's programmable infrastructure finally. I mean dev ops is happening, this is where services and notion of compute has gone from standing something up in seconds on the cloud to with functions milliseconds. This is changing the dynamic of applications but you've still got to store the data. Talk about, Jonsi, the impact of the services in piece to the developer, storage, services, provisioning, all that and it covers. >> We are taking, I mean all of our services that are running in all the hyperskills in Google and Azure and AWS and more and even on premise. Our view is our role is always to find the best home for any workload at any given time. Even though it's in public cloud or on premise. However storage has always been sort of left aside, it's always been living in this propietary chunk that is hard to move and the weight of the data is actually quite heavy. So we actually want to use Kubernetes and microservices and resistant volume claims by taking that data and making that very easily migratable replicated between locations, between hyperscalers and sort of adopt a true multi cloud strategy. With data with it not only moving those workloads or applications but the data is key, data is key. >> Sometimes, you know, you want to move the data to a compute and sometimes you want to move compute to the data. >> And that's been validated by Amazon's RDS announcement on VMware, Amazon announced outposting on premises, and the number one thing was latency, work was not yet moving. This is exactly to what you guys have been doing and implementing, today, this is like real product. >> I think the reality of the world is, you know, while there is a ton of innovation that exists in public cloud there are well documented use cases that struggle with a cloud only environment. I think NetApp has chosen to make each one of those three potential persistent stores equal to one another. So whether that's in a traditional on premise and upgrading on premise environments to get better price performance characteristics, embracing the public cloud or combining public and private cloud. >> While it's not trivial NetApp, at it's core, always was software so moving it from a hardware appliance, I mean, back in the day Network Appliance was the original name of the company to a software defined solution to being multi-cloud, you can kind of see that genesis where it can go. A lot of times the tougher part is from the customer standpoint. You know, the traditional person that bought and managed this was a storage administrator and getting them to understand cloud native applications and dev ops and all those things, those are pretty challenging moves so how much of it is education? How much of it is new buying centers inside the company or new clients, help us walk through that. >> Yeah I would make two points in maybe answering to you. So I think NetApp's history, actually 25 years ago, NetApp started off as selling into the developers who were running SUN workstations, who wanted shared everything and NetApp actually you know went around IT and put those appliances into the developers. We built a SaaN business, a very successful SaaN business, with the IT people. Now you're absolutely right, the people around here fall into the, sort of, the modern day dev ops characters. What Google calls the SREs the Site Reliability Engineers. And they're a new breed, they're young, they're doing more and more CICD. Storage is an integral part of what they do but maybe not a primary part. They expect storage to work. We are really lucky you know, a little company called Microsoft and another little company called Google sell our stuff so we get introduced into all of those cloud first, cloud only sort of use cases. Not just of refactoring of primary but building. So we're actually, in many cases now, very relevant to those people but we've been fortunate enough to leverage the big public clouds together. >> So you have a relationship with AWS, Google and Microsoft, Microsoft and Google, which you've just mentioned. You mentioned SRE, Site Reliability Engineer, this is a new persona that's clearly emerging and it has a focus around operations, now IT operations has been around for a long time, dev is changing too but this is, if they sell your stuff, their customers need to operate at scale. This is a big point, can you elaborate on the importance of this and what you guys are doing specifically to help that. >> So the Site Reliability Engineer, he is not doing operations. He is actually in charge of running the workload or the development or the application or the product that comes from development. They have to abide by specific rules that are actually set by the SRE. And to your point, because you were talking about different selling motions and not selling into the storage admin or not selling to traditional IT. This is actually what has actually been really surprising and showcases the power of Kubernetes and how widely adopted it has been, both on premise and in the public cloud because customers are actually coming to us and saying, "Hey we had no idea NetApp was actually "doing all of this in the public cloud. "We had no idea that you had your own Kubernetes services "that actually help solve one of the biggest problems "which is persistent volume claims and application of data." So it's actually coming, and you sort of see how important CNCF is, because they're actually educating the market and educating the enterprise space just as well as the new up and coming development team like I've traditionally come from. So I'm actually seeing that it's easier than I would have sort of thought in the beginning. So they're actually becoming more educated about microservices, more educated about how to run their, actually everybody almost in any company that I go into now, they have the SRE playbook somewhere in their meeting room somewhere and everybody sort of getting educated on how they need to, sort of, elevate themselves from being traditional system administrators into that SRE or dev op role. >> And it's also a cultural thing too, they have to develop, not just the playbook, but have some experience in economies of scale, managing it, and certainly it's a tail wind for you guys, storage because, again, it's also a lot of coating involved they need a pool of resources, storage being one of them. But the other thing that's interesting, those are single clouds, Amazon, Google, multi cloud is really where the action is, right? So multi cloud to me is just, to me, a modern version of multi vendor, which basically is about choice. Choice is critical, but having choice around the app, it becomes the value creator. So if you guys can scale with the app development environments that seems to be a sweet spot. How are you guys talking about that particular point because this becomes an under the covers, a new kind of operations, a new kind of scale, pushing code, not just you know stacking interacting boxes but, like, really making things, patching security things or could have been head of security things so doing things in a really really automated way. >> Yeah, I mean, I think the one thing I'm most proud of at my time at NetApp and what the team does and what the team continues to do is we took a very, very, I think, deliberate perspective that we would deliver storage, but we would do it in a very unique way. That my background was from Saas, I spent my entire career building applications, and when you build an application, you run the application, there is nothing you give the customer and say, "Here, administer it." When you look at a lot of the infrastructure services, they make the customer do a lot of work. So what we did at NetApp was we decided that we ourselves would almost create like an always available protocol that people could just ask for it and it would be there. There was no concept of setting it up or patching it or upgrading it. And that's really I think we have set a bar now on the public clouds that, I think, even the public clouds themselves have not done, and giving those developers that I asked for a storage through an API and all I need to do is ask for capacity and throughput. Nothing else, that's something to a developer they're like, "So now I don't even have to ask "anybody with storage skills. "I can tell my application to ask for it's own storage." >> It's interesting you're living in a new world where you need the scale of a system but the functionality of like an app server. I feel like we're living in that app server days where that middle ground and app development was the key focus, you've got to have both now. You need scalable systems but really application performance. >> And then you add an additional layer because now everybody wants to be able to use the same deployment script, the same configuration management system, Terraform, whatever they're actually using to deploy it on premise or in a public cloud but it needs to be done in a unified manner. This is why it's so important to be upstream compatible and there's a lot of companies out there that are actually destroying that model and not following the true cloud concept. >> Yes give them a slap on the wrist, get in line, fix it! >> If you are going to play in this space with the CNCF and with Kubenetes, you better play by the rules and do the open standards. And so you're actually compatible no matter where your workload resides. >> We've been monitoring how storage is maturing in this whole cloud native Kubenetes ecosystem here. A year ago there were a lot of backroom arguments over what were the right architectures, a few sub projects working through here, it actually blew me away in the keynote this morning to hear that 40% of all applications that are deployed in Kubernetes are stateful. So where are we? What's working? What's good for customers? And what do we still need to work on to kind of solidify the storage data piece of this? >> I think it's interesting, 'cause I think we, sort of, ourselves now consider NetApp to be a data company. Storage is an enabler but what's interesting, everyone talks about their Saas strategy, their PaaS strategy their IaaS strategies. I always ask people, "What's your data strategy?" and that's something I think the CNCF Kubernetes, themselves, recognize that they've done a lot of really great things for compute around the microservices themselves but the storage piece has always been something of a challenge. And we said, about solving that problem, we have an open source project called Trident, that essentially enables people to make persistent volume claims and if the container dies, they can essentially start a new container and pick up the storage exactly where they left off. So we really believe that stateful is an ever increasing percentage of the overall application model. Databases are important things, people need them. >> I would agree with that and that's developing too, it's early on. All right so I want to ask you guys a question, kind of outside the box. Multi cloud certainly is part of a hybrid, what they call a hybrid today, it's really a choice, multi cloud will be a future reality, no matter what anyone says, I believe that. How is multi cloud changing IT investments? Business investments, technical investments or both, what's your guys thoughts on how multi cloud is driving and changing IT investments? >> Well I actually think it offers you the opportunity to have like placement policy algorithms that fit your workload at any given time. For example, if this particular application is latency sensitive, and I created an application that all of a sudden became really popular in Mexico, then I should be able to see which one of the hyperscalers actually has a presence in Mexico City, deploy it there. If I'm under utilizing my private cloud and I have a lot of space on it and there is no specific requirements, it gives you that flexibility to, like I said, always find the best home for your workload at any given time. >> Dynamic policy based stuff? >> Yeah, precisely. And it allows you also, I mean, you can choose to do it whether its based on workload requirements or you can start doing it in a least cost effective route, I mean least cost routing. So it actually impacts both from a technical and a business sense in my opinion. >> I think you know you cannot help but get excited every day with what one cloud delivers over another cloud, and we're seeing something not unlike the arms race, you know, Google does this, then Amazon does this, then Microsoft does this. As developers we're very keen to take advantage of all these capabilities and we want to, in many cases, let the application itself make the decision. >> So yeah Amazons got there, everyone's catching up. Competitions good. All right, final question. Predictions for multi cloud in 2019. What's going to happen? Is there going to be a loud bang? Is there going to be a crash? Is it going to be fruit on the trees? What's the state of the multi cloud predictions for 2019? >> Well I actually believe it's going to become a standard. Nobody should be locked into any region or any one provider, I don't even care if it's on premise or NetOps specific, you should be able to... I mean, I think it's just going to become standard. Everybody has to have a multi cloud strategy and you can see that, like the IDC report that 86% of Fortune 500 companies are adopting multi cloud. And I think I'm actually quite fed up of this hyper cloud stuff because, in my opinion, on premise is just the fourth or the fifth hyperscaler and should be treated as such. So if you actually have that true cloud concept, you should be able to deploy that using the same script, the same APIs to deploy it everywhere. >> As I said in theCube the data center and non print, they're just an edge, a big edge. If it's an operating mall? >> My prediction? Your prediction. >> 2019 is the year of Istio. I think we've become enamored with Kubernetes, I think what Istio brings significantly advances Kubernetes, and we barely scratched the surface, I think, with the service mesh and all of the enhancements and all the contributions that will go into that. I think, you know, that 2019 will probably see as many vendors here next year with Istio credentials and STO capabilities as we see today with Kubernetes. >> Anthony, Jonsi, thanks for coming on, great insights, smart commentary, appreciate it. We should get in the studio and dig into this a little bit deeper. Really a great example of an incumbent, large company, NetApp, really getting a tailwind from the cloud, good smart bets you guys made, programmable infrastructure, dynamic policy routing, all kinds of under the covers goodness from smart cloud deployments. This is where software drives the data. >> Yep data is the new oil, that's what they say right? If you don't have a data set you're not very competitive. >> Thanks for coming on I appreciate it. More Kube coverage here, getting all the breakdown here, the impact of cloud computing at scale, the role of data software, all happening here at the CNCF. This is the KubeCon, I'm John Furrier and Stu Miniman, thanks for watching. More live coverage after this short break.

(upbeat music) >> Narrator: From Barcelona, Spain. It´s theCUBE. Covering Cisco Live 2018. Brought to you by Cisco Veeam and theCUBE´s ecosystem partners. >> Everyone, welcome back to theCUBE´s exclusive live coverage here in Barcelona, Spain with Cisco´s Live 2018 Europe. I was going to say DevNet, but we´re on the DevNet zone. I´m John Furrier, your host, with Stu Miniman, analyst at Wikibon.com . Our next guest is Susie Wee, who´s Vice-President, CTO of DevNet. Susie, CUBE alumni, welcome back to theCUBE, great to see you. >> Great to see you, welcome to Barcelona. >> John: Thank you for having us, we´re in the hot section of the Devnet Zone, the signs, cause it´s a big part of the hallway here. And it´s really where the action is. >> Susie: It is. >> You guys have continued to do a great job and we´re psyched to be on the ground where the action is. Thanks for inviting us. >> Great, I´m glad that you´re here. There´s so much going on. >> Okay, so Devnet is this renaissance going on at Cisco. But it´s also not just a Cisco phenomenon, the world of software development is seeing an explosion. I mean, from the edge of the network, and crazy fringe of cryptocurrency, blockchain, all the way into app development and then under the hood DevOps. Some really great things are happening, you have it featured here, DevOps, at Devnet. What´s going on at the DevNet zone? >> Yeah, it´s really interesting because what happens is here at Cisco live and here in the DevNet zone, we have basically people who deployed network and Compute Infrastructures, around Europe. And so, it´s pretty amazing that we have the people who are like feet on the street, working in those networks, deploying them, digitizing Smart Cities, putting up new buildings, putting up new infrastructure everywhere. And, what´s really cool is, they´re all interested in learning about APIs and software. And, so, that´s not easy, right? That´s something that´s a big shift in, like, I´m running a network infrastructure, and I´m ready to learn about software and deep-dive into APIs. So, our new products are coming out, which actually have built-in programmability. Like, the network now has APIs, it´s getting built into the network. And whereas you could always like take a Compute Infrastructure and manage it virtually, use, you know, CICD pipelines and everything there with DevOps. But the thing is, now the Network has APIs and you can now kind of flexibly deploy your network in that same way of DevOps but using Net DevOps, and that´s kind of what it´s all about. >> Yeah, Susie, I wonder, there was so much hype for a bunch of years about like, software to find networking. (Susie laughs) But, under the covers, like behind the scenes, you know, it´s the API economy. That´s where the actions happen, it doesn´t seem like it´s gotten quite the attention, you have some interesting things about where Net and Dev go together. What do people miss out there, that, you know, kind of the industry watchers, that, you know, aren´t here, aren´t seeing the people that are, you know, been spending days already doing stuff here. >> Susie: Yeah. >> And obviously you´re really excited. >> Well there was all the kind of excitement and hype, you know, it kind of went through it´s hype curve of what software-defined networking was and would be and could be. But the thing that we have to remember is that there´s like real mission critical networks operating all around the world and people who are out there, who deploy them and run them and manage them. And so, what happens is, you need to do more than just like put out a new protocol or put out a new innovation. You need to kind of bring the community along and kind of still make those revolutions, but, by evolving, right, having the evolutions and the folks who are deploying and making all the right thing happen. So, what happens is, just SDN is now becoming a reality. Because, it took more than just putting a controller on top of an existing network, like, that´s good, that´s an important part of it. But, it´s also just building programmability into the network elements themselves. And then, being able to get that really kind of rapid responses. You´re, you know, deploying new configuration, setting policy, incorporating security, you know. And so, now, just SDN is becoming real and the real world here, all of these folks are picking it all up. >> So I have to ask you, you mentioned Net DevOps, cause, you, we love, we´ve talked about DevOps all day long, Stu and I, with all the shows and, you know, we´re hop the trot for DevOps. But you said Net DevOps. >> Susie: Yeah. >> What is that? (Susie laughs) >> Can you explain? >> Yeah, it´s really awesome, it´s just basically the fact that, you know, with DevOps you´re taking your applications, cloud applications, deploying them fast, right? Rapidly, CICD, using this infrastructure-as-code type of thinking. Well now, it´s not only the Compute but the network plays in that too. So, basically, if you picture underneath that network is a bunch of network devices, a bunch of security, you know, products, all of these things are coming together to really connect everything. And, that´s becoming programmable. And what happens is now with Net DevOps you can create and treat the network as code. So, you want to deploy changes in your network, you´ll do it with a software configuration update. You know, you want to like, add new devices into the network. You want to add new users and set new policies for security, control how apps are done, how cloud, you know, applications are running. You can actually roll that out as software changes. So, what happens is suddently, it´s not only Compute that works in a DevOps pipeline, but the network is also participating in this Net DevOps pipeline. >> You know, I love this new trend, Net DevOps, because it´s kind of like, the old days was you moved up the stack. Now you see the movement down the stack from the applications, to DevOps, now moving lower to NetOps, Net DevOps. >> Susie: Yes. >> But the question is, that makes still no sense, by the way, but I need to ask. Who´s writing that code? The network guys? So, in DevOps, we knew who the DevOps guys were, it was the operators and the developers kind of coming together. >> Susie: Yeah. >> Yeah, pushing code, real agile. Who does that, the same guys doing DevOps? Or is it the network guys, a combination oh both? Would you... >> Oh, my God. >> A lot of people. (says in foreign language) >> Yeah, it´s really exciting the way that it´s evolving. So, what you see is, you know, in Cisco Live, we have a huge kind of community, just people who come to Cisco Live to get trained, to get their certifications on how to deploy the latest networking technologies and operate, manage them. They get certified and their running those networks around the world. They´re now here, picking up the software skills and learning to use these, the new software products, and being able to deploy in Net DevOps. So, they´re all here to learn about how can I put built-in automation. You know, once you have that programmability and automation you can scale and work things out in really big ways. How can I put applications performance monitoring into my network? You know, and make sure that it´s operating properly and we´re getting the right assurance that it´s performing well. So, the network operators, are picking up those skills. But, in addition, there´s actually the app developers, who are coming in and app developers who are writing, for example, management or DevOps or even, you know, Docker, Kubernetes. Folks who are in that, who need the network. And basically now they´re like "the network has APIs, I can actually use that, so that, if I, you know, for Docker and for Kubernetes, you know, we´re working with Google on stuff. Our developers are actually now writing tools to make sure that, as you´re optimizing your microservices, the placement of them, you´re taking the network into account as well. >> So you kind of get both. >> So it´s interesting, and Kubernetes plays an interesting role because you can actually run those functions >> Susie: Yes. >> On Kubernetes, can´t you? >> Susie: Yes. >> So that´s kind of a new trend. >> Susie: Yeah. >> Who´s, I mean, so they´re writing code in here, in DevNet Zone? Or is that, the network operators are coming in banging out code? >> So, network operator are here banging out code. There´s app developers who are coming in and banging out code as well. And this whole thing of like, you know, the infrastructure guys, the app developer guys. And then, the DevOps. There´s this DevOps professional, kind of like the IT folks that are moving on to embrace DevOps and they´re kind of emerging in the middle of here to use all of these tools that are created in open source. >> So you´re appealing to all constituency stakeholders of software. >> We are, we are, yeah. (laughs) >> We are, and actually I that some... >> Is that why DevNet´s so popular? (laughs) >> I think that people have a need, they see a need and (laughs), and basically what I think, like the trend that´s going on that´s kind of making this stuff happen, is that, we know there´s so much exciting, excitement in applications and cloud and all of the developments there, and the internet of things. These applications need the network more than ever before. So, before, they only used the network for connectivity, but now they need the network for security. They need it for scale. They do need more bandwidth, they need good performance. And, so... >> John: And they need to program that too. >> And they need to program it, exactly. And so, that´s what the new network APIs, the fact that you have a programmable network is what´s letting those guys play. And not just say, you know, before it was "here´s your network, like, just do the most you can, given the performance of the network", right? >> So Susie, first of all... >> But now it´s programmable. >> Congratulations on, you know, the DevNet Zone here is awesome. >> Susie: Thank you. >> And, we know it´s challenging to bring developers in and to, you know, pull this community in where, they might not have been before, there´s retraining everything, but, I was wondering if you can give us a little inside into Cisco. So, Cisco, you know, has been around for decades. Networking company. Software has been a piece of it for a long time, I mean, it´s, you know, even when it´s, you know, "hey, we spent a lot of money on building this chip out there", I was who´s what drove that. Software´s a large piece but, the whole developer angle, getting Cisco behind this, give us a little bit of inside as for what kind of transformation, you know, your team has driven inside to get more of Cisco onboard. I mean, you know, people that are used to selling boxes, and things that, you know, the networking industry is about ports and cables and speeds and feeds and, you know, apps are very different. >> It is, it is very different and it´s, um, it was actually really great. So we´ve built DevNet over the last four years. And it was one thing to kind of have a strategy, like, we knew that the products were going to software, that SDN was emerging. And that, the only way it could actually become real is for Cisco to also participate in it, right? Just cause there´s so much network out there that is Cisco. And so, the entire industry has made that become more real. But, you need to build an ecosystem around it, right? The only reason that it´d have software, like, there´s many reasons, but one of the main reasons is actually to make sure that the ecosystem is participating in the innovation. So, yeah, we created DevNet to, not just focus on our internal development but to provide and kind of catalyze the industry to participate and really innovate and build software on top using all the new APIs. So, um, so yeah, it´s been, it´s been amazing to see the growth and what´s interesting is, over the last 4 years, it´s the community. So, from our first DevNet Zone we had a lot of people who are interested. You know, they´re all like, ah! You know, my day job´s been networking. I coded a long time ago, let me get back into it. But now we see that audience, plus much more. Like, if you look at here at how engaged all of these kind of networkers and developers are, is, they´re right in there. They´re just hungry saying, you know, I have applications that I need to deploy. Applications are hitting the infrastructure. My network can make a difference in how well these new applications run. They´re all in. >> Susie, you´ve done this you´ve done this a number of times, now. Do you have like, kind of the hero numbers as to a what percentage of the attendees you know, spend a bunch of time in the DevNet zone, how much code or applications get written? Just, kind of order of magnitude. >> Susie: Oh. >> Kind of the engagement. >> You mean like, kind of like, from before til now? >> Yeah, well, pr just, you know, what expectations... >> Yeah. >> For this show, what you´ve seen at some of the previous events. >> Yeah, well, kind of what´s funny is, what happened is, the DevNet Zone, like having a developer conference within Cisco Live, it kind of grew as like a "What´s going on there?". And people where immediately interested, it was full. But we have just kind of grown and grown it to have learning labs, to have ISV partners in here, to have just kind of, like, you know, resellers. People who are solutions providers, they are kind of all here. This has, actually turned into the busiest area of Cisco Live. >> Yeah, and you´ve got your own events, too. >> Yes, yes, that´s right. And on top of like having the DevNet Zone here, our developer conference within Cisco Live, what other Cisco audience comes in, right? A huge ecosystem. But also have DevNet Create. So, when we´re going out, app developers are also interested in network APIs. So, it´s not just networkers. And, so, we actually have DevNet Create, which is just the dedicated developer conference for IOT, cloud developers, app developers. And they´ve shown big interest in all of this as well. >> And this is a whole new constituency, but it´s kind of the same game, though, right? It´s like, you offering the programmable network to a whole another net new Cisco community? Is that kind of like you guys look at it? >> It is, and, exactly. And like, we´ve gone outside, we´re offering the network. And what we´re doing is, we´re actually, you know, when you´re a real networking geek, like a networking expert. >> John: Like us. >> You can do network talk, right? And you´re talking network, and you´re kind of getting into all of that. And before app developers were like, we don´t care about that, like, just, we need to write our apps. We shouldn´t have to worry about the network. But, now that those APIs are coming too, and again, their apps are dependent on network performance, they´re dependent on security they can get from the network. It turns out that once we express the value proposition to them, like, this is what a network API can do for you. They´re really interested. >> And even though that we´ve observed that there´s a separation between app developers who just want to write apps >> Susie: Yep >> And software engineering, which is under the hood they still need to be involved in the network because of microservices. >> Susie: Yes. >> So now they have the ability to use APIs that they´re comfortable with, they know ABIs. And, make unique changes to the app, based upon unique network characteristics they can tap into. >> Yeah. >> John: This seems to be the glue in the crossover point for you guys. >> It is. >> John: Did I get that right? >> It is, it is. So, what happens is, there will always be a set of app developers, who of course, are not going to use the network. They´re going to write their app, they´re going to want it to deploy everywhere, of course. I mean, that´s what everybody wants. But you´ve already seen it. As someone writes a cloud app, right? They write a cloud service or a cloud app, and it scales, and they´re deploying their app across different clusters and >> They are learning a lot >> John: They´re going to write >> About what´s going on >> John: They´re going to write policy. >> They´re going to write policies >> Yeah >> They have to decide what countries am I going to spin up my servers in, you know. >> Yeah. >> So, actually, they do a lot of that. So, what happens is, this set of kind of cloud developers, and specially as they moved to microservices as you said, their applications are going to a microservices-based architecture. Things can spin up in different places and then it becomes more critical of, you know, how do these different containers talk to each other? What´s the networking policy for what data can go in and out? What´s the security policy? And, you need to build that in. So, the network matters to them. >> Well, a beautiful thing about what you guys are doing is, you´re catering to a whole new generation of developers who are slinging APIs on one end, but also potentially writing Node.js code. And so, the´re very familiar with IO. >> Susie: Exactly, yes. >> So, microservices is like fish to water. And so, you´re just making it easier >> Susie: Yes. >> for them. That´s the, that´s the angle on the app side. >> That´s right, and then we´re just giving them that tool. And they had so much pain with it before because a lot of times people would be like writing their app, right? They´re doing it in their cluster, then they push it to production. Boom, it goes out. And then, it doesn´t work anymore. And a lot of times it´s because the network is not set up properly in their new thing. So they blame the network and the blame... But, once you start to open up the APIs, you can start to move these things and do it, you know... >> Well, Susie, you´ve got a great group. It´s the biggest story here. We believe, we´ve been reporting DevNet Zone. You know, theCUBE, we´re always on the best trends and the best waves, you´re on it. >> By the way, have you seen the security challenge over here? >> The blackhat >> So,the blackhat, white hat security challenge? It´s actually pretty interesting. (John laughs) >> It shows... >> John: Well, we´ll have to go test our chops, too. >> That´s right, that´s right. >> John: Dust off those coding hands. >> That´s right. (laughs) >> We´ll go over there. Well, I love the tagline, all around these classrooms. Learn, code, inspire and connect. >> Yes. >> Great motto, cause you´re building community in one end, and educating on the other spectrum. So, education to community, great spectrum. Congratulations. >> Thank you. >> Susie Wee, Vice-President and CTO of DevNet, here at Cisco, doing a great job. This is where the action is. This is the transformation of Cisco. It´s becoming software and network DevOps. New term, Net DevOps, heard here on theCUBE. I´m John Furrier and Stu Miniman. We´ll be back with more live coverage, in Barcelona, Spain after this short break. (upbeat music)

(cheerful music) >> Announcer: Live from Los Angeles, it's theCUBE! Covering Open Source Summit North America 2017. Brought to you by The Linux Foundation and Red Hat. >> Welcome back, and we're live here in Los Angeles. This is theCUBE's special coverage of Open Source Summit North America. I'm John Furrier with Stu Miniman. Two days of wall-to-wall coverage. Our next guest, Ed Warnicke, who is a distinguished consulting engineer with Cisco. Welcome to theCUBE. >> Glad to be here! >> Thanks for coming on. Love to get into it. We love infrastructure as code. We love the cloud developers. The young generation loves it. Making things easy to use all sounds great, but there's still work to get done. The networking... So what's going on here at the Open Source? So this is the big tent event where there's a lot of cross-pollination around projects. Obviously the networking side, you guys at Cisco are doing your share. Give us the update. Networking is still a lot more work to be done. It's a very strategic part of the equation. Certainly making it easier up above makes it programmable. >> Yeah, you have to make the networking invisible even to the DevOps layer. There are certain things that you need from the network. They need isolation and reachability. They need service discovery and service routing. But they don't want to have to think about it. They don't want to be burdened with understanding the nitty gritty details. They don't want to know what subnet they're on, they don't want to have to worry about ACL's, they don't want to think about all of that. And the truth is, there's a lot of work that goes into making the network invisible and ubiquitous for people. And in particular, one of the challenges that we see arising as the world moves more cloud-native, as the microservices get smaller, as the shift happens toward serverless, as Kubernetes is coming on with containers, is that the network is really becoming the run time. And that run time has the need to scale and perform like it never has before. So the number of microservices you'd like to put on a server keeps going up, and that means you need to be able to actually handle that. The amount of traffic that people want to push through them continues to go up. So your performance has to keep up. And that brings a lot of distinct challenges, particularly when you're trying to achieve those in systems that were designed for a world where you had maybe two NIC's on the box, where you weren't really thinking when the original infrastructure was built about the fact that you were actually going to have to do a hell of a lot of routing inside the server because you now have currently hundreds, but hopefully someday thousands and tens of thousands of microservices running there. >> Ed, you know, I think when we've been talking about the last 15 or 20 years or so, I need to move faster with my deployment. It always seemed that networking was the thing that held everything up. It's like, okay, wait, when I virtualized, everything's great and everything, and I can just spit up a VM and do that. Oh, but I need to wait for the network to be provisioned. What are the things you've been working on, what open source projects? There's a lot of them out there helping us to really help that overall agility of work today. >> Absolutely. So one of the things I'm deeply involved in right now is a project called FD.io, usually pronounced Fido, because it's cute. And it means we can give away puppies at conferences. It's great. What FD.io is doing, is we have this core technology called VPP that gives you incredibly performant, incredibly scalable networking purely in user space. Which means from a developer velocity point of view, we can have new features every three months. From an extensibility point of view, you can bring new network features as separate plugins you drop as .so's into a plugin directory instead of having to wait for the kernel to rev on your server. And the revving process is also substantially less invasive. So if you need to take a microservice network as a user space thing and rev it, it's a restart of a process. You're talking microseconds, not 15-minute reboot cycles. You're talking levels of disruption where you don't lose your TCP state, where you don't lose any of those things. And that's really crucial to having the kind of agility that you want in the network. And when I talk about performance and scalability, I'm not kidding. So one of the things we recently clocked out with VPP was being able to route a terabyte per second of traffic with millions of routes in the forwarding tables on commodity servers with no hardware existence at all. And the workloads are starting to grow in that direction. It's going to take them a while to catch up, but to your point about the network being the long pull, we want to be far ahead of that curve so it's not the long pull anymore. So you can achieve the agility that you need in DevOps and move innovative products forward. >> Ed, one of the things that comes up all the time, I wanted to get your reaction to this because you're an important part of it, is developers say, look, I love DevOps. And even ops guys are saying, we want to promote DevOps, so there's a mind meld there if you will. But then what they don't want is a black box. They want to see debugging, and they want to have ease of manageability. So I don't mind pushing dev, if I'm an ops guy, send the dev down, but they need a path of visibility. They need to have access to debug fast. Get access to some of those things. What do you see as gates if you will, that we got to get through to make that seamless and clean right now? Obviously Kubernetes, lot of stuff going on with orchestration. And containers are providing a path. But still, the complaint and nervousness is okay, you can touch and program the infrastructure, but if something happens, you're going to be reactive. >> Yeah, that gets exactly to the point. Because the more invisible the network is, the more visibility you need when things go wrong. And for general operational use. And one of the cool things that's happening in FD.io around that, is number one, it's industrial scale. So you have all sorts of counters and telemetry information that you need from an historical point of view in networks to be able to figure out what's going on. But beyond that, there's a whole lot of innovation that's been happening in the network space that has yet to trickle down all the way to the server edge. A really classic example on the visibility front has to do with in-band iOAM. So we now have the technology, and this is present today in VPP, to be able to say, hey, I would like an in-band trace on the flow though the network of this flow for this customer who's giving me a complaint, where I can see hop by hop through the network including in the edge where VPP is, what's the latency between hops? What path it actually passed through. And there's even a feature there where you could say, at each hop, please send the packet capture at that hop to a third-party point where I can collect it so I can look at it in something like Wireshark. So you can look in Wireshark and say, okay I see where this went into that node and came out that node this way. Node by node by node. I don't know how much more visibility than that is actually physically possible. And that's one of the kinds of things that the velocity of features that you have in VPP has made very possible. That's the kind of thing that would take a long time to work into the traditional development line for networking. >> What's the Cisco internal vibe right now? Because we covered the DevNet Create event that Susie Wee put on, which was kind of like a cloud-native cool event. Kind of grassroots, kind of guerrilla. I love the mojo there. But then you've got the DevNet community at Cisco, which is a robust killer developer community on the Cisco side. How are those worlds coming together? I can imagine that the appetite for the Cisco DevNet teams, the DevNet developer community, is looking at cloud-native as an opportunity. Can you share some insight into what's the sentiment, what's the community vibe, what's going on? For folks that just got to run the networks, I mean this is serious stuff. In the past, they've been like, cloud-native, when you're ready we'll get there. But now there seems to be an onboarding of cloud-native. Talk about the dynamic. >> There has to be, because cloud-native won't wait. And there's a lot of things that the network can do to help you as the run time. The iOAM example is one, but there are a ton more. Again, cloud-native won't wait. They will find a way, and so you have to be able to bring those features at the pace at which cloud-native proceeds. You can't do it on six-month product cycles. You can't do it on 12-month product cycles. You have to be able to respond point by point as things more forward. A good example of this is a lot of the stuff that's happening with server meshes in Insteon. Which is coming really fast. Not quite here, but coming really fast. And for that, the real question is, what can the network do for DevOps? Because there's a synergistic relationship between DevOps and NetOps. >> So you were saying... Just to try to get at the point. So yes, are you seeing that the DevNet community is saying hey we love this stuff? Because they're smart, they know how to adapt. Moving from networks to DevOps. To me it seems like they're connecting the dots. You share some-- Are they, yes no maybe? >> They're absolutely connecting the dots, but there's a whole pipeline with all of this. And DevNet is at the short pointy end where it touches the DevOps people. But to get there, there's a lot of things that have to do with identifying what are the real needs, getting the code written to actually do it, figuring out the proper innovations, engaging with open source communities like Kubernetes so that they're utilized. And by the time you get to DevNet, now we're at the point where you can explain them to DevOps, where they can use them really cleanly. One of the other things is, you want it to come through transparently. Because people want to be able to pick their Kubernetes Helm charts off the web, take the collection of containers for the parts of their application they don't want to have to think about, at least right now, and have it work. So you have to make sure you're supporting all the stuff that's there, and you have to work to be able to take advantage of those new features in the existing API's. Or better yet, just have the results of those API's get better without having to think about new features. >> So they're in great shape. It's not a collision, it's not friction. >> No, no no. >> It's pretty much synergistic. Network guys get the DevOps equation. >> No, we get the DevOps equation, we get the need. There is a learning process for both sides. We deeply need each other. Applications without networking are completely uninteresting. And this is even more true in microservices where it's becoming the run time for the network. On the same side, networks without applications are completely uninteresting because there's no one to talk. And what's fascinating to me is how many of the same problems get described in different language and so we'll talk past each other. So DevOps people will talk about service discovery and service routing. And what they're really saying is, I want a thing, I don't want to have to think about how to get to it. On the network side, for 15 years now, we've been talking about identifier/locator separation. Basically the having an IP address for the thing you want, and having the ability to transparently map that to the location where that thing is without having to... It's the classic renumber your network problem. They're at a very fundamental level the same problem. But it's a different language. >> The game is still the same. There's some language nuances that I think I see some synergies. I see people getting it. It's like learning two languages. Okay, the worlds come together. It's not a collision. But the interesting thing is networking has always been enabling opportunity. This is a fundamental nuance. If you can get this right, it's invisible, as you said. That's the end game. >> Absolutely. That's really what you're looking for. You want invisibility in the normal mode, and you want total transparency when something has to be debugged. The classic example with networks is, when there's a network problem it's almost never the network. It's almost always some little niggle of configuration that went wrong along the way. And so you need that transparency to be able to figure out okay, what's the point where things broke? Or what's the point where things are running suboptimally? Or am I getting the level of service that I need? Am I getting the latency I need, and so forth. And there's been a tendency in the past to shorthand many of those things with networking concepts that are completely meaningless to the underlying problem. People will look at subnets, and say for the same subnet, we should have low latency. Bullshit. I mean basically, if you're on the same subnet, the guy could be on the other end of the WAN in the modern era with L2 overlays. So if you want latency, you should be able to ask for a particular latency guarantee. >> It felt to me that it took the networking community a while to fix things when it came to virtualization. (Ed laughs) but the punch line is, when it comes to containers, and what's happening at Kubernetes, it feels like the networking community is rallying a lot faster and getting ahead of it. So what's different this time? You've got kind of that historical view on it. Are we doing better as an industry now, and why is it? >> So a couple of things. The Kubernetes guys have done a really nice job of laying out their networking API's. They didn't get bogged down in the internal guts of the network that no DevOps guy ever wants to have to see. They got really to the heart of the matter. So if you look at the guarantees that you have in Kubernetes, what is it? Every pod can talk to every other pod at L3. So L2 isn't even in the picture. Which is beautiful, because in the cloud, you need to worry about subnets like you need a hole in the head. Then if you want isolation, you specify a network policy. And you don't talk about IP addresses when you do that. You talk about selectors on labels for pods, which is a beautiful way to go about it. Because you're talking about things you actually care about. And then with services, you're really talking about how do I discover the service I want so I never have to figure out a pod IP? The system does it for me. And there are gaps in terms of there being things that people are going to be able to need to do that are not completely specified on those API's yet. But the things they've covered have been covered so well, and they're being defended so thoroughly, that it's actually making it easier because we can't come in and introduce concepts that harm DevOps. We're forced to work in a paradigm that serves it. >> Okay, great. So this'll be easy, so we'll be ready to tackle serverless. What's that going to mean for the network? >> Serverless gets to be even more interesting because the level of agility that you want in your network goes up. Because you can imagine something in serverless where you don't even want to start a pod until someone has made a request. So there's an L7 piece that has to be dealt with but then you have to worry about the efficiency of how do you actually move that TCP session to the actual instance that's come up for serverless for that thing, and how do you move it to the next thing? Because you're working at an L7, where from the client's point of view, they think it's all the same server, but it's actually been vulcanized across all these microservices. And so you have to find an efficient way of making that transparent that minimizes the degree to which you have to hairpin through things all over the cluster because that just introduces more latency, less throughput, more load on the cluster. You've got to be able to avoid that. And so, by being able to bring sophisticated features quickly to the data plain with something like FD.io and VPP, you can actually start peeling those problems off progressively as serverless matures. Because the truth of the matter is, no one really knows what those things are going to look like. We all like to believe we do, but you're going to find new problems as you go. It's the unknown unknowns that require the velocity. >> So it sounds like you're excited about serverless, though. >> Ed: Usually, yes, definitely. >> So I love serverless too, and I always talk about it. So what is in your opinion the confusion? There are some people who are like, oh it's bullshit. I don't think it is personally. I think it's nirvana. I think it's what people want, what most developers want. There's a server behind it. It's not serverless per se. It's just from a developer standpoint, you don't have to provision hardware. >> Or containers, or VM's, or any of that. >> I personally think it's a good thing. Is it just a better naming convention? Give the people, what's the nuance? Why are people confused? >> I think it's much more fundamental than just the naming convention. Because historically, if you look at the virtualization of workloads, every movement we've had to date has been about some workload run time technology. VM's were about virtual machines. Containers are about containers to run technology. When you get to microservices and serverless, we've made the leap from talking about the underlying technology that most developers don't care about to talking about the philosophy that they do. >> Their run time is their app. Their run time assembly is their code sandwich, not to say the network. >> Just as in serverless, I don't think anyone doubts that the first run of serverless is going to be built on containers. But the philosophy is completely divorced for them. So I'll give you an example. One of the things that we have in VPP is we have an ultra high performance, ultra high scalability userspace TCP stack. We're talking the kind of thing that can trivially handle ten million simultaneous connections with 200,000 new connections coming in every second. And right now, you can scope that to an isolation scope of a container. But there's no reason, with the technology we have, you can't scope it all the way down to a process. So you control the network access at the level of a process. So there's a lot of headroom to go even smaller than containers, even lighter weight than containers. But the serverless philosophy changes not a wit as you have that improvement come in. >> That's beautiful. Ed, thanks so much for coming on theCUBE. We really appreciate your perspective. I'd like you to get one final word in to end the segment. Describe what's happening here because the OS Summit, or the Open Source Summit, is the first of its kind, a big tent event. What's your take on it? What's the purpose of the event? What's your experience? Share with the folks who aren't here what this event is all about. >> It's really exciting, because as much as we love The Linux Foundation, and as much as we've all enjoyed things like LinuxCon in the past, the truth is, for years it's been bleeding beyond just Linux. I don't see the OS Summit so much as a shift in focus, as a recognition of what's developed. Last year we had the Open Source Summit here. We just called it LinuxCon. The year before we had the Open Source Summit here. We just called it LinuxCon. And so what's really happening is, we're recognizing what is. There's actually no new creation happening here. It's the recognition of what's evolved. >> And that is open source as a tier one reality that goes way beyond Linux, which is by the way super valuable at the kernel. >> Ed: Oh, we all love Linux. >> All Linux apps... The only apps are Linux apps. But it's a bigger thing. The growth and scale that's coming is unprecedented. I think a lot of people still are pitching themselves, Stu and I were commenting, that what's coming is going to change the face of software development for generations to come. There's an exponential scale of software libraries coming on board. Up to 400 million was forecast by 2026? >> That sounds conservative to me. (laughs) >> You think so? Well, I mean, just to get the scale. So there's going to be some leadership opportunities for the community, in my opinion. >> Absolutely. And this is where the Open Source Summit actually... I mean, words matter because they shape the way we think about things. So where I think the shift to the Open Source Summit has huge value is that it starts to shift the thinking into this broader space. It's not just a recognition of what's happened. It's a new load of software here for the community. >> This is not a marking then, it's a recognition of what's actually happening. I love that quote. Open Source Summit, brilliant move by The Linux Foundation. Create a big tent event for cross-pollination, sharing of ideas. This is the ethos of open source. Ed, thanks so much for coming on theCUBE. This is theCUBE with live coverage from the Open Source Summit in North America, formerly LinuxCon and all the other great events here in Los Angeles. I'm John Furrier with Stu Miniman. More live coverage after this short break. (electronic music)