>> (soft upbeat music) >> Announcer: From around the globe, it's the cube with digital coverage of Ansible Fest 2020, brought to you by RedHat. >> Hello, welcome to the cubes coverage of Ansible Fest 2020. We're not in person, we're virtual. I'm John Furrier , your host of theCube. We've got a great power panel here of RedHat engineers. We have Brad Thorton, Senior Principle Software Engineer for Ansible networking. Adam Miller, Senior Principle Software Engineer for Security and Jill Rouleau, who's the Senior Software Engineer for Ansible Cloud. Thanks for joining me today. Appreciate it. Thanks for coming on. >> Thanks. >> Good to be here. >> We're not in person this year because of COVID, a lot going on but still a lot of great news coming out of Ansible Fest this year. Last year, you guys launched a lot since last year. It's been awesome. Launched the new platform. The automation platform, grown the collections, certified collections community from five supported platforms to over 50, launched a lot of automation services catalog. Brad let's start with you. Why are customers successful with Ansible in networking? >> Why are customers successful with Ansible in networking? Well, let's take a step back to a bit of classic network engineering, right? Lots of CLI interaction with the terminal, a real opportunity for human error there. Managing thousands of devices from the CLI becomes very difficult. I think one of the reasons why Ansible has done well in the networking space and why a lot of network engineers find it very easy to use is because you can still see an attack at the CLI. But what we have the ability to do is pull information from the same COI that you were using manually, and showed that as structured data and then let you return that structured data and push it back to the configuration. So what you get when you're using Ansible is a way to programmatically interface and do configuration management across your entire fleet. It brings consistency and stability, and speed really to network configuration management. >> You know, one of the big hottest areas is, you know, I always ask the folks in the cloud what's next after cloud and pretty much unanimously it's edge, and edge is super important around automation, Brad. What's your thoughts on, as people start thinking about, okay, I need to have edge devices. How does automation play into that? And cause networking, edge it's kind of hand in hand there. So what's your thought on that? >> Yeah, for sure. It really depends on what infrastructure you have at the edge. You might be deploying servers at the edge. You may be administering IOT devices and really how you're directing that traffic either into edge compute or back to your data center. I think one of the places Ansible is going to be really critical is administering the network devices along that path from the edge, from IOT back to the data center, or to the cloud. >> Jill, when you have a Cloud, what's your thoughts on that? Because when you think about Cloud and Multicloud, that's coming around the horizon, you're looking at kind of the operational model. We talked about this a lot last year around having Cloud ops on premises and in the Cloud. What should customers think about when they look at the engineering challenges and the development challenges around Cloud? >> So cloud gets used for a lot of different things, right? But if we step back Cloud just means any sort of distributed applications, whether it's on prem in your own data center, on the edge, in a public hosted environment, and automation is critical for making those things work, when you have these complex applications that are distributed across, whether it's a rack, a data center or globally. You need a tool that can help you make sense of all of that. You've got to... We can't manage things just with, Oh, everything is on one box anymore. Cloud really just means that things have been exploded out and broken up into a bunch of different pieces. And there's now a lot more architectural complexity, no matter where you're running that. And so I think if you step back and look at it from that perspective, you can actually apply a lot of the same approaches and philosophies to these new challenges as they come up without having to reinvent the wheel of how you think about these applications. Just because you're putting them in a new environment, like at the edge or in a public Cloud or on a new, private on premise solution. >> It's interesting, you know, I've been really loving the cloud native action lately, especially with COVID, we're seeing a lot of more modern apps come out of that. If I could follow up there, how do you guys look at tools like Terraform and how does Ansible compare to that? Because you guys are very popular in the cloud configuration, you look at cloud native, Jill, your thoughts. >> Yeah. So Terraform and tools like that. Things like cloud formation or heat in the OpenStack world, they do really, really great at things like deploying your apps and setting up your stack and getting them out there. And they're really focused on that problem space, which is a hard problem space that they do a fantastic job with where Ansible tends to come in and a tool like Ansible is what do you do on day two with that application? How do you run an update? How do you manage it in the longterm of something like 60% of the workloads or cloud spend at least on AWS is still just EC2 instances. What do you do with all of those EC2 instances once you've deployed them, once they're in a stack, whether you're managing it, whatever tool you're managing it with, Ansible is a phenomenal way of getting in there and saying, okay, I have these instances, I know about them, but maybe I just need to connect out and run an update or add a package or reconfigure a service that's running on there. And I think you can glue these things together and use Ansible with these other stack deployment based tools really, really effectively. >> Real quick, just a quick followup on that. what's the big pain point for developers right now when they're looking at these tools? Because they see the path, what are some of the pain points that they're living right now that they're trying to overcome? >> I think one of the problems kind of coincidentally is we have so many tools. We're in kind of a tool explosion in the cloud space, right now. You could piece together as as many tools to manage your stack, as you have components in your stack and just making sense of what that landscape looks like right now and figuring out what are the right tools for the job I'm trying to do, that can be flexible and that are not going to box me into having to spend half of my engineering time, just managing my tools and making sense of all of that is a significant effort and job on its own. >> Yes, too many may add, would choke in years ago in the big data search, the tools, the tool train, one we call the tool shed, after a while, you don't know what's in the back, what you're using every day. People get comfortable with the right tools, but the platform becomes a big part of that thinking holistically as a system. And Adam, this comes back to security. There's more tools in the security space than ever before. Talking about tool challenges, security is the biggest tool shed everyone's got tools they'd buy everything, but you got to look at, what a platform looks like and developers just want to have the truth. And when you look at the configuration management piece of it, security is critical. What's your thoughts on the source of truth when it comes into play for these security appliances? >> So these are... Source of truth piece is kind of an interesting one because this is going to be very dependent on the organization. What type of brownfield environment they've developed, what type of things that they rely on, and what types of data they store there. So we have the ability for various sources of truth to come in for your inventory source and the types of information you store with that. This could be tagged information on a series of cloud instances or series about resources. This could be something you store in a network management tool or a CMDB. This could even be something that you put into a privilege access management system, such as, CyberArk or hashivault. Like those are the things and because of Ansible flexibility and because of the way that everything is put together in a pluggable nature, we have the capability to actually bring in all of these components from anywhere in a brownfield environment, in a preexisting infrastructure, as well as new decisions that are being made for the enterprise as I move forward. And, and we can bring all that together and be that infrastructure glue, be that automation component that can tie all these disjoint loosely coupled, or complete disc couple pieces, together. And that's kind of part of that, that security posture, remediation various levels of introspection into your environment, these types of things, as we go forward, and that's kind of what we're focusing on doing with this. >> What kind of data is stored in the source of truth? >> I mean... So what type of data? This could be credential. It could be single use credential access. This could be your inventory data for your systems, what target systems you're trying to do. It could be, various attributes of different systems to be able to classify them ,and codify them in different ways. It's kind of kind of depending, be configuration data. You know, we have the ability with some of the work that Brad and his team are doing to actually take unstructured data, make it structured, bullet into whatever your chosen source of truth is, store it, and then utilize that to, kind of decompose it into different vendors, specific syntax representations and those types of things. So we have a lot of different capability there as well. >> Brad, you were mentioned, do you have a talk on parsing, can you elaborate on that? And why should network operators care about that? >> Yeah, welcome to 2020. We're still parsing network configuration and operational state. This is an interesting one. If you had asked me years ago, did I think that we would be investing development time into parsing with Ansible network configurations? I would have said, "Well, I certainly hope not. "I hope programmability of network devices and the vendors "really have their API's in order." But I think what we're seeing is network containers are still comfortable with the command line. They're still very familiar with the command line and when it comes time to do operational state assessment and health assessment of your network, engineers are comfortable going to the command line and running show commands. So really what we're trying to do in the parsing space is not author brand new parking and parsing engine ourselves, but really leverage a lot of the open source tools that are already out there bringing them into Ansible, so network engineers can now harvest the critical information from usher operational state commands on their network devices. And then once they've gotten to the structure data, things get really interesting because now you can do entrance criteria checks prior to doing configuration changes, right? So if you want to ensure a network device has a very particular operational state, all the BGP neighbors are, for example before pushing configuration changes, what we have the ability to do now is actually parse the command that you would have run from the command line. Use that within a decision tree in your Ansible playbook, and only move forward when the configuration changes. If the box is healthy. And then once the configuration changes are made at the end, you run those same health checks to ensure that you're in a speck can do a steady state and are production ready. So parsing is the mechanism. It's the data that you get from the parsing that's so critical. >> If I had to ask you real quick, just while it's on my mind. You know, people want to know about automation. It's top of mind use case. What are some of these things around automation and configuration parsing, whether it's parsing to other configuration manager, what are the big challenges around automation? Because it's the Holy grail. Everyone wants it now. What are the couches? where's the hotspots that needs to be jumped on and managed carefully? Or the easiest low hanging fruit? >> Well, there's really two pieces to it, right? There's the technology. And then there's the culture. And, and we talk really about a culture of automation, bringing the team with you as you move into automation, ensuring that everybody has the tools and they're familiar with how automation is going to work and how their day job is going to change because of automation. So I think once the organization embraces automation and the culture is in place. On the technology side, low hanging fruit automation can be as simple as just using Ansible to push the commands that you would have previously pushed to the device. And then as your organization matures, and you mature along this kind of path of network automation, you're dealing with larger pieces, larger sections of the configuration. And I think over time, network engineers will become data managers, right? Because they become less concerned about the network, the vendors specific configuration, and they're really managing the data that makes up the configuration. And I think once you hit that part, you've won at automation because you can move forward with Ansible resource modules. You're well positioned to do NETCONF for RESTCONF or... Right once you've kind of grown to that it's the data that we need to be concerned about and it could fit (indistinct) and the operational state management piece, you're going to go through a transformation on the networking side. >> So you mentioned-- >> And one thing to note there, if I may, I feel like a piece of this too, is you're able to actually bridge teams because of the capability of Ansible, the breadth of technologies that we've had integrations with and our ability to actually bridge that gap between different technologies, different teams. Once you have that culture of automation, you can start to realize these DevOps and DevSecOps workflow styles that are top of everybody's mind these days. And that's something that I think is very powerful. And I like to try to preach when I have the opportunity to talk to folks about what we can do, and the fact that we have so much capability and so many integrations across the entire industry. >> That's a great point. DevSecOps is totally a hop on. When you have software and hardware, it becomes interesting. There's a variety of different equipment, on the security automation. What kind of security appliances can you guys automate? >> As of today, we are able to do endpoint management systems, enterprise firewalls, security information, and event management systems. We're able to do security orchestration, automation, remediation systems, privileged access management systems. We're doing some threat intelligence platforms. And we've recently added to the I'm sorry, did I say intrusion detection? We have intrusion detection and prevention, and we recently added endpoint security management. >> Huge, huge value there. And I think everyone's wants that. Jill, I've got to ask you about the Cloud because the modules came up. What use cases do you see the Ansible modules in for the public cloud? Because you got a lot of cloud native folks in public cloud, you've got enterprises lifting and shifting, there's a hybrid and multicloud horizon here. What's some of the use cases where you see those Ansible modules fitting well with public level. >> The modules that we have in public cloud can work across all of those things, you know. In our public clouds, we have support for Amazon web services, Azure GCP, and they all support your main services. You can spin up a Lambda, you can deploy ECS clusters, build AMI, all of those things. And then once you get all of that up there, especially looking at AWS, which is where I spend the most time, you get all your EC2 instances up, you can now pull that back down into Ansible, build an inventory from that. And seamlessly then use Ansible to manage those instances, whether they're running Linux or windows or whatever distro you might have them running, we can go straight from having deployed all of those services and resources to managing them and going between your instances in your traditional operating system management or those instances and your cloud services. And if you've got multiple clouds or if you still have on prem, or if you need to, for some reason, add those remote cloud instances into some sort of on-prem hardware load balancer, security endpoint, we can go between all of those things and glue everything together, fairly seamlessly. You can put all of that into tower and have one kind of view of your cloud and your hardware and your on-prem and being able to move things between them. >> Just put some color commentary on what that means for the customer in terms of, is it pain reduction, time savings? How would you classify their value? >> I mean, both. Instead of having to go between a number of different tools and say, "Oh, well for my on-prem, I have to use this. "But as soon as I shift over to a cloud, "I have to use these tools. "And, Oh, I can't manage my Linux instances with this tool "that only knows how to speak to, the EC2 to API." You can use one tool for all of these things. So like we were saying, bring all of your different teams together, give them one tool and one view for managing everything end to end. I think that's, that's pretty killer. >> All right. Now I get to the fun part. I want you guys to weigh in on the Kubernetes. Adam, if you can start with you, we'll start with you go in and tell us why is Kubernetes more important now? What does it mean? A lot of hype continues to be out there. What's the real meet around Kubernetes what's going on? >> I think the big thing is the modernization of the application development delivery. When you talk about Kubernetes and OpenShift and the capabilities we have there, and you talk about the architecture, you can build a lot of the tooling that you used to have to maintain, to be able to deliver sophisticated resilient architectures in your application stack, are now baked into the actual platform, so the container platform itself takes care of that for you and removes that complexity from your operations team, from your development team. And then they can actually start to use these primitives and kind of achieve what the cloud native compute foundation keeps calling cloud native applications and the ability to develop and do this in a way that you are able to take yourself out of some of the components you used to have to babysit a lot. And that becomes in also with the OpenShift operator framework that came out of originally Coral S, and if you go to operator hub, you're able to see these full lifecycle management stacks of infrastructure components that you don't... You no longer have to actually, maintain a large portion of what you start to do. And so the operator SDK itself, are actually developing these operators. Ansible is one of the automation capabilities. So there's currently three supported there's Ansible, there's one that you just have full access to the Golang API and then helm charts. So Ansible's specifically obviously being where we focus. We have our collection content for the... carries that core, and then also ReHat to OpenShift certified collection's coming out in, I think, a month or so. Don't hold me to the timeline. I'm shoving in trouble for that one, but we have those things going to come out. Those will be baked into the operator's decay that we fully supported by our customer base. And then we can actually start utilizing the Ansible expertise of your operations team to container native of the infrastructure components that you want to put into this new platform. And then Ansible itself is able to build that capability of automating the entire Kubernetes or OpenShift cluster in a way that allows you to go into a brownfield environment and automate your existing infrastructure, along with your more container native, futuristic next generation, net structure. >> Jill this brings up the question. Why don't you just use native public cloud resources versus Kubernetes and Ansible? What's the... What should people know about where you use that, those resources? >> Well, and it's kind of what Adam was saying with all of those brownfield deployments and to the same point, how many workloads are still running just in EC2 instances or VMs on the cloud. There's still a lot of tech out there that is not ready to be made fully cloud native or containerized or broken up. And with OpenShift, it's one more layer that lets you put everything into a kind of single environment instead of having to break things up and say, "Oh, well, this application has to go here. "And this application has to be in this environment.' You can do that across a public cloud and use a little of this component and a little of that component. But if you can bring everything together in OpenShift and manage it all with the same tools on the same platform, it simplifies the landscape of, I need to care about all of these things and look at all of these different things and keep track of these and are my tools all going to work together and are my tools secure? Anytime you can simplify that part of your infrastructure, I think is a big win. >> John: You know, I think about-- >> The one thing, if I may, Jill spoke to this, I think in the way that a architectural, infrastructure person would, but I want to try to really quick take the business analyst component of it as the hybrid component. If you're trying to address multiple footprints, both on prem, off prem, multiple public clouds, if you're running OpenShift across all of them, you have that single, consistent deployment and development footprint for everywhere. So I don't disagree with anything they said, I just wanted to focus specifically on... That piece is something that I find personally unique, as that was a problem for me in a past life. And that kind of speaks to me. >> Well, speaking of past lives-- >> Having me as an infrastructure person, thank you. >> Yeah. >> Well, speaking of past lives, OpenStack, you look at Jill with OpenStack, we've been covering the Cuba thing when OpenStack was rolling out back in the day, but you can also have private cloud. Where you used to... There's a lot of private cloud out there. How do you talk about that? How do people understand using public cloud versus the private cloud aspect of Ansible? >> Yeah, and I think there is still a lot of private cloud out there and I don't think that's a bad thing. I've kind of moved over onto the public cloud side of things, but there are still a lot of use cases that a lot of different industries and companies have that don't make sense for putting into public cloud. So you still have a lot of these on-prem open shift and on-prem OpenStack deployments that make a ton of sense and that are solving a bunch of problems for these folks. And I think they can all work together. We have Ansible that can support both of those. If you're a telco, you're not going to put your network function, virtualization on USC as to one in spot instances, right? When you call nine one one, you don't want that going through the public cloud. You want that to be on dedicated infrastructure, that's reliable and well-managed and engineered for that use case. So I think we're going to see a lot of ongoing OpenStack and on-prem OpenShift, especially with edge, enabling those types of use cases for a long time. And I think that's great. >> I totally agree with you. I think private cloud is not a bad thing at all. Things that are only going to accelerate my opinion. You look at the VM world, they talked about the telco cloud and you mentioned edge when five G comes out, you're going to have basically have private clouds everywhere, I guess, in my opinion. But anyway, speaking of VMware, could you talk about the Ansible VMware module real quick? >> Yeah, so we have a new collection that we'll be debuting at Ansible Fest this year bore the VMware REST API. So the existing VMware modules that we have usually SOAP API for VMware, and they rely on an external Python library that VMware provides, but with these fare 6.0 and especially in vSphere 6.5, VMware has stepped up with a REST API end point that we find is a lot more performance and offers a lot of options. So we built a new collection of VMware modules that will take advantage of that. That's brand new, it's a lighter way. It's much faster, we'll get better performance out of it. You know, reduced external requirements. You can install it and get started faster. And especially with these sphere seven, continuing to build on this REST API, we're going to see more and more interfaces being exposed so that we can take advantage. We plan to expand it as new interfaces are being exposed in that API, it's compatible with all of the existing modules. You can go back and forth, use your existing playbooks and start introducing these. But I think especially on the performance side, and especially as we get these larger clouds and more cloud deployments, edge clouds, where you have these private clouds and lots and lots of different places, the performance benefits of this new collection that we're trying to build is going to be really, really powerful for a lot of folks. >> Awesome. Brad, we didn't forget about you. We're going to bring you back in. Network automation has moved towards the resource modules. Why should people care about them? >> Yeah. Resource modules, excuse me. Probably I think having been a network engineer for so long, I think some of the most exciting work that has gone into Ansible network over the past year and a half, what the resource modules really do for you is they will reach out to network devices. They will pull back that network native, that vendor native configuration. While the resource module actually does the parsing for you. So there's none of that with the resource modules. And we returned structured data back to the user that represents the configuration. Going back to your question about source of truth. You can take that structure data, maybe for your interface CONFIG, your OSPF CONFIG, your access list CONFIG, and you can store that data in your source of truth under source of truth. And then where you are moving forward, is you really spend time as every engineer managing the data that makes up the configuration, and you can share that data across different platforms. So if you were to look at a lot of the resource modules, the data model that they support, it's fairly consistent between vendors. As an example, I can pull OSPF configuration from one vendor and with very small changes, push that OSPF configuration to a different vendor's platform. So really what we've tried to do with the resource modules is normalize the data model across vendors. It'll never be a hundred percent because there's functionality that exists in one platform that doesn't exist and that's exposed through the configuration, but where we could, we have normalized the data model. So I think it's really introducing the concept of network configuration management through data management and not through CLI commands anymore. >> Yeah, that's a great point. It just expands the network automation vision. And one of the things that's interesting here in this panel is you're talking about, cloud holistically, public multicloud, private hybrid security network automation as a platform, not just a tool, we're still going to have all kind of tools out there. And then the importance of automating the edge. I mean, that's a network game Brad. I mean, it's a data problem, right? I mean, we all know about networking, moving packets from here to there, but automating the data is critical and you give have bad data and you don't have... If you have misinformation, it sounds like our current politics, but you know, bad information is bad automation. I mean, what's your thoughts? How do you share that concept to developers out there? What should they be thinking about in terms of the data quality? >> I think that's the next thing we have to tackle as network engineers. It's not, do I have access to the data? You can get the data now for resource modules, you can get the data from NETCONF, from RESTCONF, you can get it from OpenConfig, you can get it from parsing. The question really is, how do you ensure the integrity and the quality of the data that is making up your configurations and the consistency of the data that you're using to look at operational state. And I think this is where the source of truth really becomes important. If you look at Git as a viable source of truth, you've got all the tools and the mechanisms within Git to use that as your source of truth for network configuration. So network engineers are actually becoming developers in the sense that they're using Git ops to worklow to manage configuration moving forward. It's just really exciting to see that transformation happen. >> Great panel. Thanks for everyone coming on, I appreciate it. We'll just end this by saying, if you guys could just quickly summarize Ansible fast 2020 virtual, what should people walk away with? What should your customers walk away with this year? What's the key points. Jill, we'll start with you. >> Hopefully folks will walk away with the idea that the Ansible community includes so many different folks from all over, solving lots of different, interesting problems, and that we can all come together and work together to solve those problems in a way that is much more effective than if we were all trying to solve them individually ourselves, by bringing those problems out into the open and working together, we get a lot done. >> Awesome, Brad? >> I'm going to go with collections, collections, collections. We introduced in last year. This year, they are real. Ansible2.10 that just came out is made up of collections. We've got certified collections on automation. We've got cloud collections, network collections. So they are here. They're the real thing. And I think it just gets better and deeper and more content moving forward. All right, Adam? >> Going last is difficult. Especially following these two. They covered a lot of ground and I don't really know that I have much to add beyond the fact that when you think about Ansible, don't think about it in a single context. It is a complete automation solution. The capability that we have is very extensible. It's very pluggable, which has a standing ovation to the collections and the solutions that we can come up with collectively. Thanks to ourselves. Everybody in the community is almost infinite. A few years ago, one of the core engineers did a keynote speech using Ansible to automate Philips hue light bulbs. Like this is what we're capable of. We can automate the fortune 500 data centers and telco networks. And then we can also automate random IOT devices around your house. Like we have a lot of capability here and what we can do with the platform is very unique and something special. And it's very much thanks to the community, the team, the open source development way. I just, yeah-- >> (Indistinct) the open source of truth, being collaborative all is what it makes up and DevOps and Sec all happening together. Thanks for the insight. Appreciate the time. Thank you. >> Thank you. I'm John Furrier, you're watching theCube here for Ansible Fest, 2020 virtual. Thanks for watching. (soft upbeat music)

>> Live, from Barcelona Spain, it's theCUBE, covering Cisco Live! Europe. Brought to you by Cisco and its ecosystem partners. >> Welcome back to theCUBE, here at Cisco Live! 2019 in Barcelona, Spain, I'm Stu Miniman, happy to welcome to the program a first-time guest, but someone I've known for many years, Jason Edelman, who is the founder of Network to Code. Jason, great to see you, and thanks for joining us. >> Thank you for having me, Stu. >> Alright, Jason, let's first, for our audiences, this is your first time on the program, give us a little bit about your background, and what led to you being the founder of Network to Code. >> Right, so my background is that of a traditional network engineer. I've spent 10+ years managing networks, deploying networks, and really, acting in a pre-sales capacity, supporting Cisco infrastructure. And it was probably around 2012 or 13, working for a large Cisco VAR, that we had access to something called Cisco onePK, and we kind of dove into that as the first SDK to control network devices. We have today iPhone SDKs, SDKs for Android, to program for phone apps, this was one of the first SDKs to program against a router and a switch. And that, for me, was just eye-opening, this is kind of back in 2013 or so, to see what could be done to write code in Python, Seer, Java, against network devices. Now, when this was going on, I didn't know how to code, so I kind of used that as the entrance to ramp up, but that was, for me, the pivot point. And then, the same six-week period, I had a demo of Puppet and Ansible automated networking devices, and so that was the pivot point where it was like, wow, realizing I've spent a career architecture and designing networks, and realizing there's a challenge in operating networks day to day. >> Yeah, Jason, dial back. You've some Cisco certifications in your background? >> Sure, yes, CCIE, yeah. >> Yeah, so I think back, when this all, OpenFlow, and before we even called it Software-Defined Networking, you were blogging about this type of stuff. But, as you said, you weren't a coder. It wasn't your background, you were a network guy, and I think the Network to Code, a lot of the things we've been looking at, career-wise, it's like, does everyone need to become coders? How will the tools mature? Give us a little bit about that journey, as how you got into coding and let's go from there. >> Yeah, it was interesting. In 2010, I started blogging OpenFlow-related, I thought it was going to change the world, saw what NICRO was doing at the time, and then Big Switch at the time, and I just speculated and blogged and really just envisioned this world where networks were different in some capacity. And it took a couple years to really shed light on management and operations of networking, and I made some career shifts. And I remember going back to onePK, at the time, my manager then, who is now our CEO at Network to Code, he actually asked, well, why don't you do it? And it was just like, me? Me, automate our program? What do you mean? And so it was kind of like a moment for me to kind of reflect on what I can do. Now, I will say I don't believe every network engineer should know how to code. That was my on-ramp because of partnership with Cisco at the time, and learning onePK and programming languages, but that was for me, I guess, what I needed as that kick in the butt to say, you know what? I am going to do this. I do believe in the shift that's going to happen in the next couple years, and that was where I kind of just jumped in feet first, and now we are where we are. >> Yeah, Jason, some great points there. I know for myself, I look at, Cisco's gone through so much change. A year ago, up on stage, Cisco's talking about their future is as a software company. You might not even think of us as networking first, you will talk to us about software first. So that initial shift that you saw back in 2010, it's happening. It's a different form than we might have thought originally, and it's not necessarily a product, but we're going through that shift. And I like what you said about how not everybody needs to code, but it's this change in paradigms and what we need to do are different. You've got some connections, we're here in the DevNet Zone. I saw, at the US show in Orlando last year, Network to Code had a small booth, there were a whole bunch of startups in that space. Tell us how you got involved into DevNet, really since the earliest days. >> Yes, since the early days, it was really pre-DevNet. So the emergence of DevNet, I've seen it grow into, the last couple years, Cisco Live! And for us, given what we do at Network to Code, as a network-automation-focused company, we see DevNet in use by our clients, by DevNet solutions and products, things like, mentioned yesterday on a panel, but DevNet has always-on sandboxes, too. One of the biggest barriers we've seen with our clients is getting access to the right lab gear on getting started to automate. So DevNet has these sandboxes always on to hit Nexus API or Catalyst API, right? Things like that. And there's really a very good, structured learning path to get started through DevNet, which usually, where we intersect in our client engagement, so it's kind of like post-DevNet, you're kind of really showing what's possible, and then we'll kind of get in and craft some solutions for our clients. >> Yeah, take us inside some of your clients, if you can. Are most of them hitting the API instead of the COI now when they're engaging? >> Yeah, it's actually a good question. Not usually talked about, but the reality is, APIs are still very new. And so we actively test a lot of the newer APIs from Cisco, as an example. IOS XE has some of the best APIs that exist around RESTCONF, NETCONF, modeled from the same YANG models, and great APIs. But the truth is that a lot of our clients, large enterprises that've been around for 20+ years, the install base is still largely not API-enabled. So a lot of the automation that we do is definitely SSH-based. And when you look at what's possible with platforms, if it is something like a custom in Python, or even an ANSEL off the shelf, a lot of the integrations are hidden from the user, so as long as we're able to accomplish the goal, it's the most important thing right now. And our clients' leaderships sometimes care, and it's true, right? You want the outcome. And initially, it's okay if we're not using the API, but once we do flip that switch, it does provide a bit more structure and safety for automating. But the install base is so large right now that, to automate, you have to use SSH, and we don't believe in waiting 'til every device is API-enabled because it'll just take a while to turn that base. >> Alright, Jason, a major focus of the conference this year has been around multi-cloud. How's that impacting your business and your customers? >> So, it's in our path as a company. Right now, there's a lot of focus around multi-cloud and data center, and the truth is, we're doing a lot of automation in the Campus networking space. Right, automating networks to get deployed in wiring closets and firewalls and load balancers and things like that. So from our standpoint, as we start planning with our clients, we see the services that we offer really port over to multi-cloud and making sure that with whatever automation is being deployed today, regardless of toolset, and look at a tool chain to deploy, if it's a CI/CD Pipeline for networking, be able to do that if you're managing a network in the Campus, a data center network, or multi-cloud network, to make sure we have a uniform-looking field to operations, and doing that. >> Alright, so Jason, you're not only founder of your company, you're also an author. Maybe tell us about the, I believe it's an update, or is it a new book, that recently got out. >> Yes, I'm a co-author of a book with Matt Oswalt and Scott Lowe, and it's an O'Reilly book that was published last year. And look, I'm a believer in education, and to really make a change and change an industry, we have to educate, and I think the book, the goal was to play a small part in really bringing concepts to light. As a network engineer by trade, there's fundamental concepts that network engineers should be aware of, and it could be basics and a lot of these, it could be Python or Jinja templating in YAML and Git and Linux, for that matter. It's just kind of providing that baseline of skills as an entrance into automation. And once you have the baseline, it kind of really uncovers what's possible. So writing the book was great. Great opportunity, and thank you to Matt and Scott for getting involved there. It really took a lot of the work effort and collaborated with them on it. >> Want to get your perception on the show, also. Education, always a key feature of what happens at the show. Not far from us is the Cisco bookshop. I see people getting a lot of the big Cisco books, but I think ten years ago, it was like, everybody, get my CCIE, all my different certifications updated, here. Here in the DevNet Zone, a lot of people, they're building stuff, they're building new pieces, they're playing in the labs, and they're doing some of these environments. What's your experience here at the show? Anything in particular that catches your eye? >> So, I do believe in education. I think to do anything well, you have to be educated on it. And I've read Cisco Press books over the years, probably a dozen of them, for the CCIE and beyond. I think when we look at what's in DevNet, when we look at what's in the bookstore, people have to immerse themselves into the technology, and reading books, like the learning labs that are here in the DevNet Zone, the design sessions that are right behind us. Just amazing for me to have seen the DevNet Zone grow to be what it is today. And really the goal of educating the market of what's possible. See, even from the start, Network to Code, we started as doing a lot of training, because you really can't change the methodology of network operations without being aware of what's possible, and it really does kind of come back to training. Whatever it is, on-demand, streaming, instructor-led, reading a book. Just glad to see this happen here, and a lot more to do around the industry, in the space around community involvement and development, but training, a huge part of it. >> Alright, Jason, want to give you the final word, love the story of network engineer gone entrepreneurial, out of your comfort zone, coding, helping to build a business. So tell us what you see, going forward. >> So, we've grown quite a bit in the past couple years. Right now, we're over 20 engineers strong, and starting from essentially just one a couple years ago, was a huge transformation, and seeing this happen. I believe in bringing on A-players to help make that happen. I think for us as a business, we're continuing to grow and accelerating what we do in this network automation space, but I just think, one thought to throw out there is, oftentimes we talk about lower-level tools, Python, Git, YAML, a lot of new acronyms and buzzwords for network engineers, but also, the flip side is true, too. As our client base evolves, and a lot of them are in the Fortune 100, so large clients, looking at consumption models of technology's super-important, meaning is there ITSM tools deployed today, like a ServiceNow, or Webex teams, or Slack for chat integration. To really think through early on how the internal customers of automation will consume automation, 'cause it really does us no good, Cisco, vendors, or clients no good, if we deploy a great network automation platform, and no one uses it, because it doesn't fit the culture of the brand of the organization. So it's just, as we continue to grow, that's really what's top of mind for us right now. >> Alright, well Jason, congratulations on everything that you've done so far, wish you the best of luck going forward, and thank you so much, of course, for watching. We'll have more coverage, three day, wall-to-wall, here at Cisco Live! 2019 in Barcelona. I'm Stu Miniman, and thanks for watching theCUBE. (electronic music)

>> Host: Live, from Santa Clara, California, it's TheCUBE covering Open Networking Summit 2017. Brought to you by the Linux Foundation. (upbeat music) >> Hey, welcome back everybody, Jeff Frick here with theCUBE. We are coming to the end of day two at Open Networking Summit. We just got here today, it's a great show. Everyone who's talking everything about software-defined networking is here. And along with Scott Raynovich we're joined by Dave Ward, one of the luminaries doing panels, doing keynotes. >> Here we are in TheCUBE. >> And here we are. Dave is the CTO of Engineering and Chief Architect at Cisco Systems. So Dave, great to see you as always. >> Great to see you guys. >> So what's the buzz of the show, you've been here for a couple of days, any surprises? >> No real big surprises to be honest, always there's some great announcements and great launches going on. But really what I'm finding surprising is that this is the sixth year of this conference, can you believe that? So year six from where we started, and I may be the first person to say this, have you ever had anybody in theCUBE today talking about openflow? >> Jeff: No. >> Remember those days? >> Now, nothing against open flow that's not my point, but think about how far we've gone and so. >> Scott: Actually, yeah, Martin was talking about it. >> Course he did. Course he did. He's not going to let it go. (laughter) But love you Martin. But really my point is, look how far we've come in six years. Six years ago we had a protocol, small community, one group working on this stuff, really working in standards, there was no open-source associated with that at that time, now look where we are. Basically the place to do work is now in open-source and come together as a community. So, the buzz for me really is holy shit, this thing is real! There's a lot of people investing a lot of money and time and really trying to work together to improve and build the ecosystem around networking, around network functions, what services are being delivered and building a business off networking again, so networking is back. It's cool again. >> Jeff: Right. Great. And then there's this whole new thing coming down the pike in the form of 5G, and IoT that's just opening up a new opportunity kind of redefine, what are these standards, and how is this going to help push things along? >> Well, it's kind of interesting and so I'm just ripping for a second. When you take a look at where we've come over the last several years and it was SDN controllers and configuring the network. Then it was virtualizing the network. There was a lot of talk yesterday and today about analytics and creating a reactive network. All of that has been built in the those six years and come together in different open-source communities to build those pieces. We've got SDN controllers, projects like OpenDaylight, projects like FD.io, projects like PNDA, P-N-D-A-.io. That's the SDN virtualized network and data analytics piece, but when you get to 5G and IoT, one thing I'll be talking about tomorrow in my keynote, is that there're big blocks missing in the industry. So, let's dial it back to historically, remember when the HVAC contractor logged on to the network and that malware on that laptop stole 70 million credit cards, remember that? >> Yes. >> Still haven't solved that problem yet. And so the reason why I'm bringing this up is what's missing, identity. So we had this notion that networks controlled by IT operators that are going to go in and config and provision that network. Well, we're now to the point where we need to link people and things to be able to drive what that intent is on the network, and whether its buzz words, which is real functionality by the way, of micro-segmentation. HVAC contractor goes into a micro-segment, can't get to the point of sale, can't steal the credit cards. Basic bread and butter stuff we want from the network. This is what SDN is supposed to deliver, virtualized services like firewalls and other sporadic security, we'll just hold that for a second. But that linking of who the person is, what device they're on, where they are on campus, where they are in the world, etc., etc., time of day, whatever the case may be, are now the variables that need to go into the top of this system, into a policy engine that then drives that reactive network. We've made a couple of great strides in six years, but to get to 5G, and in particular to get to IoT, we have to have another couple of major blocks come into the industry to make that work well. Hopefully it's open-source where that's going to go, and it's not just a standards body and not just open-source, cuz we still need things to be manufactured and interoperable and the rest of it. So hopefully these things come together as we've seen the maturing of those two big groups. >> I was going to say, it kind of begs the question, what is the interplay between standards bodies versa or together with open-source projects? Cuz before you didn't really have open-sources standards really set. Set the regs. Now you've got these open-source projects, which have a main channel, they might start forking, there's all kinds of places that they can go, and how do the two kind of work together? >> Well there's been a ton of effort, and coming out of the SDN open-source movement around model-driven networking, and although it sounds kind of geeky, the main way of representing those models is through representation called YANG. The interesting thing about YANG is that's been not only adopted in SDN, as the main object and way of representing the models being converted to network and equipment computes, computers etc. But the IETF has taken that up and really driven a service approach through the IETF which is I want to deliver a VPN service, I want to deliver load engineering on the network versus what we did with SNMP, or what the industry did, which was I'm going to fully distribute this out to all the protocols and all the functions and everybody's going to write a NIB etc., etc. and we know how that turned out. So the craze for model-driven networking, the standards bodies picking this up, IETF, MEF, which is metro ethernet forum, broadband forum, BBF. All these organizations have now taken on that mantra that came out of open-source SDN of model-driven networking and are working towards creating those models so that way we will have a standardized way to program the network. But what's next is the telemetry coming out. Those objects need to be standardized so that way whether it's a Cisco device or somebody else's device, it's actually sending out the same data that can be collected and can be interpreted properly. Does it mean that it's a NIB? Does it mean that it's only going to go over one particular transport? I don't think anybody in the industry really cares whether it's JSON, Google RPC, Protobuffs, Netconf, or any of these pieces, they're all perfectly fine, they have different semantics associated with them, but nonetheless those common objects and common data models have been what has been the key to keeping the industry working together, the common architectural philosophy, and then the standards bodies have thankfully picked that up over the last couple of years. >> Yeah we were talking here earlier, I mean you just threw out a bunch of alphabet soup there and I understand 80% of it, but it does raise the issue we were talking about earlier about these standards development organizations and the IETF, the TM Forum, the MEF. Now we have open-source, so we have the Linux Foundation. We have a lot of these different organizations and I think while you would know better than I as a CTO, people are becoming challenged by tracking and following all this stuff, do you think we need some sort of consolidation of these standards or at least some more unification, we just saw ECOMP and Open-O merge so there seems to be some consolidation. What will we see going forward? What's going to help you as the CTO? >> There's no doubt if there's consolidation, that would be easier to track and easier place to develop, but in reality, Scott, it's 50 shades of YANG. (laughter) >> And the reason why I say that is each and every standards body has done their own specific function, again whether it's Metro Ethernet or its broadband access or its mobility, each one of those standards bodies is redefining themselves to be SDN capable. There's no doubt. If there's a one stop shop, it would be the most optimal way to get something done the fastest, but that's not the way the world works. So actually I think we are going to see a continuous increase of more folks working on this, more foundations being build, etc., etc. Although, what we have witnessed over the last couple days in the last year, is that the communities, the open-source communities in particular, are coming together and trying to integrate the pieces together versus just islands of cool technology that there's a few geeks interested in, no. Thankfully the operators and some enterprises have come in and said I need this stuff to work and I need this stuff to work together and that discipline is actually fundamentally new and different than the way either standards bodies worked or open-source worked in the past. So I'd love to say that there'd be even more consolidation. There's frankly a bit of fatigue over, not saying it's wack-a-mole but you have to chase, you have to really figure out and track where all this stuff is going on in the industry to really keep abreast and understand how wide and how deep it goes. >> It's interesting this trend lately where people are just donating ... The project is just being absorbed into Linux Foundation. So now there's at least kind of a consistency across all these various projects, in terms of the way things are managed, the shows, the communication, and them helping standardize a process to help those projects be more successful in their distribution and adoption in the company. >> Linux Foundation has done the industry a huge service. They understand governance. They've gone through a zillion different experiences of how to build communities. What works well when there's competing factions that need to come together and work, on board marketing team, on board legal team, able to build foundations as necessary, or what's been experimented with over the last couple of years is, if you remember when we started to number these, you need to have a 503C, you need to have a foundation, there was frankly a high cost associated with these. Now, open-source is being contributed there's no foundation, and there's no cost. And so there's a whole continuum of things that the industry, the networking industry I should say, is learning about how to build communities and although this sounds cliche, you may launch a product, but you don't launch a community, you actually have to build it. And it's not all one company that's doing the donating or doing the working and that will produce, that'll create the longevity of that particular project. And that is what the Linux Foundation knows how to do well or at least catalyzed people to come together to do that well. >> Now you mentioned one of the big questions that always comes up with open-source is well how do we make money, right? Cause it's all free. It's like, you know ... >> Are we on Jerry Maguire? What's going on? (laughter) >> Jeff: Free like a puppy. (laughing) >> Still my favorite. >> Free like a puppy, yeah, you guys still got to change the newspaper. So you were on a panel today there was a big discussion about the commercialization and how does, I mean obviously Cisco has to stare at this big puppy in the room if you will, you know. What's going to happen to our licensing model with all this open-source, what came out of that discussion, what came out of the panel about how do you make money in this open-source world? >> So a couple of things, one thing that was discussed was not only how to make money, is which comes first, cost reduction, total cost of ownership, or new service revenue. And really the outcome there, and AT&T, Comcast, and Lightspeed Ventures was also in the panel with me. Needless to say it's a combination of both. If you're coming in with a project and the project is please spend this money so you can save this money, we know how to do that math. We can add up the rows and columns and can understand whether or not money will be saved over time. But the new service revenue really certainly in an enterprise space, is really what's being discussed. In particular, can I get these new services, I need these new security functions, I want to manage all my branches from the cloud or whatever the case might be. So new service revenue is depending on which use case, which technology, which layer. Both of those two balance out and they both are required in the algorithm. Now, can people make money off of it? And the answer is, needless to say, Lightspeed Ventures colleague said, "Hey man, if there's a community "and there's a technology, "you can list off a zillion cases of where that community "is turned into a true company that can provide value-add "and additional IP and move forward." Now, let's move this from just startups to big companies like Cisco or AT&T and Comcast and not only do we all use open-source in our projects, all those companies are contributing to open-source. And in Cisco's case, we're contributing to open-source for a couple of key reasons, one is there are gaps in the industry, which were limiting the industry. So let me give an example. We open-sourced a virtual switch router, which you might think, okay it's Cisco they're going to do something in networking, but the reason why we open-sourced it, and it's a piece that we actually use in our products, was there was not a virtual switch or router that had the scale, performance, or features that enabled the industry to utilize all the capabilities of the hardware underneath, whether it's computer or networking or security. And so the industry literally would have stalled with a limited feature set versus being able to utilize decades of networking knowledge and experience in things that are key and necessary, encapsulations, features, filters, quality of service etc., etc. There's a zillion of these pieces. And so there's a couple different ways, how can somebody make money off of this really is the fundamental question. We contribute into open-source communities and use that open-source to build products as well. And we can do this across video, we can do this in networking, and we do this in NFV, we do this in orchestration in these pieces and we also catalyze an ecosystem around these projects and then potentially around our portfolio as well. And so we continuously expand our ecosystem into startups that are using this technology, advancing the technology, enabling the industry to move faster, and trying to fundamentally create those business outcomes that our customers want. >> I just love that you just innately understand the value of an active community and that really comes through, so but unfortunately the janitors have rolled in, the vacuums are going, the garbage cans are rolling, so before they unplug all of our gear, I want to give you the last word Dave. What are some of your top priorities for 2017? >> So top priorities for 2017 really comes down to working towards filling the gaps I mentioned, identity and policy, but additionally number one, make sure that the automation orchestration policy around networking in a containerized stack is created. So we live through a long era of hypervisors and what it was like to work with open stack and what it was like in open-source and have to invent all this technology. We learned a ton. But it doesn't exist in a containerized world. So for 2017, fill the big gaps in the industry and work towards orchestrating and automating networking, compute, storage, and security in a containerized world. >> Pretty simple. I think that's the answer. I was going to say 42 is usually the answer, but I think that was it Dave. (laughter) >> I love 42. (laughing) >> Thanks Dave, so he's Dave Ward, Scott Raynovich, I'm Jeff Frick, you're watching TheCUBE from Open Networking Summit 2017. We'll see you tomorrow. Thanks for watching. (upbeat electronic music) >> You're also an entrepreneur, right? You know the business, you've been in the business.