(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)

>> Announcer: Live from San Francisco, it's theCUBE covering DevNet Create 2017 brought to you by Cisco. >> Hey, welcome back everyone, we are here live in San Francisco for theCUBE's exclusive two days of coverage of Cisco's new inaugural event called DevNet Create. An extension of their classical developer group DevNet, DevNet Create really going into the ethos of DevOps, the infrastructruous code targeting cloud-native and app developers, the collision between applications and infrastructure. A new direction for Cisco, this is theCUBE, I'm John Furrier with my co-host Peter Burris. Our next guest is Bhavana Srines- >> Bhavana: Srinivas. >> Srinivas, solutions architect at PubNub, which provides real-time pubs. Welcome to theCUBE, thanks for coming on. >> Thank you, it's great to be here and talk to you guys. >> So, PubNub, you couldn't get PubSub but it relates. Explain what you guys do real quick. >> Yeah, so what PubNub is is it provides real-time infrastructure as a service. So we realized that a lot of people were trying to build these real-time, always-on applications wherein when something happens in real life, you want that message or event to be translated to several of your friends or other users instantly. So, everyone is trying to build a real-time app like, say, a taxi dispatcher like Lyft or for example, a chat application where if I send a message my friends need to receive it instantly. Anyone trying to build these kind of real-time applications were building the infrastructure before they even got to the best part, which is their business logic. So, we decided that we will provide that infrastructure, we'll provide that plumbing. We'll build a global distributed network for all of these app developers to build their always-on applications. So, what we do is provide this real-time, bidirectional communication between devices in a very scalable manner and it's very, it focuses on real-time communication. >> And the key there is that most apps are mobile, you require this so you want to get them accelerated because, let's face it, most apps don't make it, right? So why build all the plumbing? >> Bhavana: Right. >> Focus on getting to figuring out the best app experience. >> Exactly, so it's for mobile, web, and even for IoT devices because everyone now wants to talk to each other. You're not going to let that gradual sit by itself, you want to connect it. So, like you said, it's meant to go to market quickly. Like you said, not every company has the resources or the time and the effort to put in to building this infrastructure, so why don't we provide this as a service? So now they're focusing on their business logic and try and make that app look pretty. >> So you're clearly in the world of cloud-native, which really is pure cloud, mostly startups. Because why have a data center? If you're a startup, I mean anyone that does a startup these days, if you have data center you're either crazy or you have so much case you just want to spend it. Why would you want to do it? You just go right to the cloud. >> Right, right, right, so we call ourselves more of a network because we're not... Think of it as a CDN but for real-time data. It's not longer static files- >> Peter: CDN is smaller messages deterministic performance. >> Exactly, exactly, you nailed it. So, what we're- >> John: You nailed it. >> Peter: I'm the man! (laughter) >> All right, so talk to me about where your use cases are. Give us some examples of customers and some specific apps that are on the network. >> For sure, so, if you take eBay for instance. They use PubNub for buyer-seller chat. So, you go on eBay, you want to talk to that buyer before you actually buy that thing. So, that chat application is powered by PubNub. Or for instance, you go to Logitech and then you want to control all these devices in your house, and PubNub is what enables that from your mobile phone to all the devices in your house. That is PubNub in play there. Or, if for instance, Lyft uses us for to see where exactly the driver is in real-time. So you're able to see every instantly. So, it's such a low-lying infrastructure that we play in almost 35 different industries. Whether it's real-time chat or taxi dispatch, multiplayer game, like Pocket Gems uses us. That's where it's real-time at it's core, right? So, you have two screens, people are playing a game. You want to see what the other person is doing, right? That's the essence of a multiplayer game. And so you can imagine how important it is to be real-time in such a use case, and that's where PubNub fits in. >> But just so we're clear, we're not talking about scada kinds of, system control kinds of things. Low-level IoT protocols, we're talking about a machine that serve human types of speeds. >> Bhavana: Exactly. >> A few hundred milliseconds, that kind of stuff. >> Exactly, exactly, so we're protocol, we call ourselves protocol agnostic. So, as long as a device can speak ECP it can understand PubNub. So, all you're dealing with is that high-level application level APIs. >> Peter: So you're still layer seven? >> Yes, very much layer seven. >> Peter: That's important. >> Yeah, but then the way we provide that layer seven API is by building out this very robust network. >> All right, so explain to us how you guys play with microservices because you're doing a topic on, Always-on Apps are Driving Microservices to the Edge. >> Yeah, yeah, yeah, yeah. So, so far you understood that PubNub's almost like a message pipeline between devices. If you have a message to throw out, PubNub will route it for you anywhere in the world. So then we decided that people are sending all these small bits of data through our network, but let's do something with that data. So, maybe if there's a chat application and people are talking to each other, maybe you want to translate it in-stream. So you put in a function there on the PubNub network that says, "Hey, if my destination is going to a "Spanish-speaking person, translate it." Or if I want to do sentiment analysis because I have a customer support kind of app, data's flowing between an agent and a customer, then let's do some sentiment analysis on it. So, what we added to this humongous network is the ability to put small pieces of logic on it. So that it acts on the data flowing though the network. And so it becomes easy to spin up these microservices through PubNub and that's what I'm going to be talking about. So it's, yeah-- >> John: So it's a brand new innovation. >> Bhavana: Sorry? >> A new innovation opportunity for you guys-- >> Bhavana: Exactly. >> To apply logic into a data stream while it's in motion. >> Of course, yes, so we recently even did have a BLOCK, we call this BLOCK, event handlers. So, we have a BLOCK with Cisco Spark. So if you wanted to do any kind of collaboration using that Cisco Spark, you can now send data through PubNub and instantly, in real-time it will sync up with Cisco Spark. >> So, Bhavana I got to get your perspective on something. We talk to a lot of enterprises and you're involved with a lot of cutting edge companies. Microservices, cloud-native, they're doing cutting edge stuff. They don't have time to be bothered with old-fashioned stuff because they have no baggage. There's no legacy, a lot of these enterprises have legacy environments, they're trying to be relevant, and they're looking to design great apps. Is there a pattern that you've seen or observation that you've noticed on these successful new, emerging companies that could be an opportunity for someone to look at and say, "Hmm, I should to more of that." What's the trend? >> (laughs) That's a loaded question. But we talk to a lot of small and medium businesses and also a lot of enterprise level companies. But then, it's just that the sales cycles are much slower. You can't go to a company and say that, "Hey, I know you're building a technical product. "Speed up your development process," right? So it's up to them to do that. So with enterprises at least they have the resource and time to do so. But, like you said, they have a lot of legacy systems. So, it's hard to tear that down and-- >> John: Build new. >> Build new stuff that you have, which might be more optimized but we try to make it work. So we're trying to now, like I said, if you're within the PubNub eco-system, you can use our BLOCKS but then everyone understands https. So we've now included a BLOCKs endpoint, where if you just dock http, you can get in to the PubNub network. So ways to use our network using their infrastructure. So we're trying to make this network accessible for anyone, irrespect of whether they use-- >> John: So integrate easily into these older legacy environments. >> Bhavana: Exactly. >> Well, but so one of the places where at least PubSub initially started was the idea that you could have a published without having to know who the clients were. >> Bhavana: Right, right, right, right. >> So you anticipate, does PubNub anticipate that you're actually going to be in a position to say, I as a real-time device, who has a real-time service, can put something into PubNub and then devices out there can subscribe to it? So a device manufacturer may sell something, it takes advantage of that centralized service, but have it operate in a deterministic, high-quality high-reliability way? Is that kind of the direction you're taking? >> Yeah, but at the end of the day, someone has to build an application. >> Peter: Sure. >> So for instance, even in Insteon, they use PubNub. They integrate PubNub within their devices and they're now selling it at Best Buys and whatnot. So it's like when I as a customer buy an Insteon product, I don't know there's PubNub in there. But then using PubNub, Insteon's now able to collect data about my usage patterns or where I can be saving energy, et cetera so the- >> But then the alternative for them is to build a full-stack system, manage it, have system integrators, have operators-- >> I mean, that was exactly the case at Insteon. They had 23 on-call support agents all day, every day, trying to do exactly what PubNub did for them without that. >> John: Yeah, they save all that cost. It's kind of like why people use Amazon. >> Right, exactly. >> (laughs) I don't need a data center, I don't need staff. All right, what did you think about this event? Obviously, Cisco has been first in a lot of markets and succeeded in networking but didn't really knock it out of the park on smart home or-- >> Peter: Linksys. >> (laughs) And so on and so forth but now, with cloud-native, we're saying is that the opportunity for them? >> Bhavana: Yeah. >> What's your take on Cisco's moving up the stack? >> I mean, I think it's great. This is one of the first conferences that DevNet is hosting for developers, right? I just got here but we've had a booth here and people are saying really great things. And there's been a steady crowd. And apparently there have been great talks. So I'm actually very excited to give my talk and then go on. >> Peter: What time is your talk, today? >> Yeah, today at 5 p.m. and then I'm here tomorrow as well. So, excited to check out the whole experience. >> Great to have you on theCube and thanks for sharing PubNub and we look forward to getting more updates from you. And congratulations on your success. >> Bhavana: Thank you. >> And your customers, thanks for sharing. >> It was great to be here, thank you so much. >> John: Thanks so much. >> So you should stop by our booth when you- >> We'll stop by and check out PubNub, the real-time pub-sub service used by all cutting edge companies in the cloud-native. This is theCUBE, Cube Cloud. Check out our content at youtube.com/siliconangle. That's our Cube Cloud, all the content there for you. I'm John Furrier with Peter Burris. Stay with us for more live, exclusive coverage from Cisco's inaugural event, DevNet Create, after this short break. (upbeat music) >> Hi, I'm April Mitchell and I'm the Senior Director of Strategy and Planning.