>> Announcer: From around the globe, it's theCUBE! With digital coverage of AnsibleFest 2020. Brought to you by Red Hat. >> Hello, everyone. Welcome back to theCUBE's coverage of AnsibleFest 2020. I'm your host with theCUBE John Furrier. And we've got two great guests. A CUBE alumni, Robyn Bergeron, senior manager, Ansible community team. Welcome back, she's with Ansible and Red Hat. Good to see you. And Matt Jones, chief architect for the Ansible Automation Platform. Again, both with Red Hat, Ansible was acquired by Red Hat. Robyn used to work for Red Hat, then went to Ansible. Ansible got bought by Red Hat. Robyn, great to see you, Matt, great to see you. >> Yep, thanks for having me back again. It's good to see you. >> We're not in person. It's the virtual event. Thanks for coming on remotely to our CUBE virtual, really appreciate it. I want to talk about the, and I brought that Red Hat kind of journey Robyn. We talked about it last year, but it really is an important point. The roots of Ansible and kind of where it's come from and what it's turned into and where it is today, is an interesting journey because the mission is still the same. I would like to get your perspectives because you know, Red Hat was acquired by IBM, Ansible's under Red Hat, all part of one big happy family. A lot's going on around the platform, Matt, you're the chief architect, Robyn you're on the community team. Collections, collections, collections, is the message, content, content, content, community, a lot going on. So take a minute, both of you explain the Ansible roots, where it is today, and the mission. >> Right, so beginning of Ansible was really, there was a small team of folks and they'd actually been through an iteration before that didn't use SSH called Funk, but you know, it was, let's make a piece of software that is open source that allows people to automate other things. And we knew at the time that, you know, based on a piece of research that we had seen out of Harvard that having a piece of software be architected in a modular fashion wasn't just great for the software, but it was also great for developing pathways and connections for the community to actually contribute stuff. If you have a car, this is always my analogy. If you have a car, you don't have to know how the engine works in order to swap out the windshield wipers or embed new windshield wipers, things like that. The nice thing about modular architectures is that it doesn't just mean that things can plug in. It means you can actually separate them into different spots to enable them to be plugged in. And that's sort of where we are today with collections, right? We've always had this sense of modules, but everything except for a couple of points in time, all of the modules, the ways that you connect Ansible to the vast array of technologies that you can use it with. All of those have always been in the full Ansible repository. Now we've separated out most of, you know, nearly everything that is not absolutely essential to having in a, you know, a very minimal Ansible installation, broken them out into separate repositories, that are usually grouped by function, right? So there's probably like a VMware something and a cloud something, and a IBM, z/OS something, things like that, right? Each in their own individual groups. So now, not only can contributors find what they want to contribute to in much smaller spots that are not a sea of 5,000 plus folks doing work. But now you can also choose to use your Ansible collections, update them, run them independently of just the singular release of Ansible, where you got everything, all the batteries included in one spot. >> Matt, this brings up the point about she's bringing in more advanced functionality, she's talking about collections. This has been kind of the Ansible formula from the beginning in its startup days, ease of use, easy, fast automation. Talk about the, you know, back in 2013 it was a startup. Now it's part of Red Hat. The game is still the same. Can you just share kind of what's the current guiding principles around Ansible this year? Because lots going on, like I said, faster, bigger, a lot going on, share your perspective. You've been there. >> Yeah, you know, what we're working on now is we're taking this great tool that has changed the way that automation works for a lot of people and we want to make it faster and bigger and better. We want it to scale better. We want it to automate more and be easier to automate, automate all the things that people want to do. And so we're really focusing on that scalability and flexibility. Robyn talked about content and collections, right? And what we want to enable is people to bring the content collections, the collections, the roles, the models, and use them in the way that they feel works best for them, leaving aside some of the things that they maybe aren't quite as interested in and put it together in a way that scales for them and scales for a global automation, automation everywhere. >> Yeah, I want to dig into the collections later, Robyn, for sure. And Matt, so let's, we'll put that on pause for a minute. I want to get into the event, the virtual event. Obviously we're not face to face, this year's virtual. You guys are both keynoting. Matt, we'll start with you. If you can each give 60 seconds, kind of a rundown of your keynote talk, give us the quick summary this year on the keynotes, Matt, we'll start with you. >> Yeah. That's, 60 seconds is- >> If you need a minute and a half, we'll give you 90 seconds, Robyn, that's going to be tough. Matt, we'll start with you. >> I'll try. So this year, and I mentioned the focus on scalability and flexibility, we on the product and on the platform, on the Ansible Automation Platform, the goal here is to bring content and flexibility of that content into the platform for you. We focused a lot on how you execute, how you run automation, how you manage your automation, and so bringing that content management automation into the system for you. It's really important to us. But what we're also noticing is that we, people are managing automation at a much larger scale. So we are updating the Ansible Tower, Ansible AWX, the automation platform, we're updating it to be more flexible in how it runs content, and where it can run content. We're making it so that execution of automation doesn't just have to happen in your data center, in one data center, we recognize that automation occurs globally, and we want to expand that automation execution capability to be able to run globally and all report back into your central business. We're also expanding over the next six months, a year, how well Ansible integrates with OpenShift and Kubernetes. This is a huge focus for us. We want that experience for automation to feel the same, whether you're automating at the edge, in devices and virtual machines and data centers, as well as clusters and Kubernetes clusters anywhere in the world. >> That's awesome. That's why I brought that up earlier. I wanted to get that out there because it's worth calling out that the Ansible mission from the beginning was similar scope, easy to do and simplify, but now it's larger scale. Again, it's everywhere, harder to do, hence complexity being extracted away. So thank you for sharing. We'll dig into that in a second. Okay, Robyn, 60 seconds or more, if you need it, your keynote this year at AnsibleFest, give us the quick rundown. >> All right. Well, I think we probably know at this point, one of the main themes this year is called automate to connect and, you know, the purpose of the community keynote is really to highlight the achievements of the community. So, you know, we are talking about, well, we are talking about collections, you know, going through some of the very broad highlights of that, and also how that has contributed, or, not contributed, how that is included as part of the recent release of Ansible 2.10, which was really the first release where we've got it very easy for people to actually start using collections and getting familiar with what that brings to them. A good portion of the keynote is also just about innovation, right? Like how we do things in open source and why we do things in certain ways in open source to accelerate us. And how that compares with the Red Hat, traditional product model, which is, we kind of, we do a lot of innovation upstream. We move quickly so that if something is maybe not the right idea, we can move on. And then in our products, that's sort of the thing that we give to our customers that is tried, tested and true. All of that kind of jazz. We also talk about, or I guess I also talk about the, all of our initiatives that we're doing around diversity and inclusiveness, including some of the code changes that we've made for better, more inclusive language in our projects and our downstream products, our diversity and inclusion working group that we have in the community land, which is, you know, just looking to embrace more and more people. It's a lot about connectivity, right? To one of Matt's points about all the things that we're trying to achieve and how it's similar to the original principles, the third one was, it's always, we need to have it to be easy to contribute to. It doesn't necessarily just mean in our community, right? Like we see in all of these workplaces, which is one of the reasons why we brought in Automation Hub, that folks inside large organizations, companies, government, whatever it is, are using Ansible and there's more and more, and, you know, there's one person, they tell their friend, they tell another friend, and next thing you know, it's the whole department. And then you find people in other departments and then you've got a ton of people doing stuff. And we all know that you can do a bunch of stuff by yourself, but you can accomplish a lot more together. And so, making it easy to contribute inside your organization is not much different than being able to contribute inside the community. So this is just a further recognition, I think, of what we see as just a natural extension of open source. >> I think the community angle is super important 'cause you have the community in terms of people contributing, but you also have multiple vendors now, multiple clouds, multiple integrations, the stakeholders of collaboration have increased. It was just like, "Oh, here's the upstream and et cetera, we're done, and have meetings, do all that stuff." And Matt, that brings me to my next question. Can you talk about some of the recent releases that have changed the content experience for the Ansible users in the upstream and within the automation platform? >> Well, so last year we released collections, and we've really been moving towards that over the 2.9, 2.10 timeframe. And now I think you're starting to see sort of the realization of that, right? This year we've released Automation Hub on cloud.redhat.com so that we can concentrate that vendor and partner content that Red Hat supports and certifies. In AnsibleFest you'll hear us talk about Private Automation Hub. This is bringing that content experience to the customer, to the user of this content, sort of helping you curate and manage that content yourself, like Robyn said, like we want to build communities around the content that you've developed. That's the whole reason that we've done this with collections is we don't want to bind it to Ansible core releases. We don't want to block content releases, all of this great functionality that the community is building. This is what collections mean. You should be free to use the collections that you want when you want it, regardless of when Ansible core itself has released. >> Can you just take a minute real quick and just explain what is collections, for folks out there who are rich? 'Cause that's the big theme here, collections, collections, collections. That's what I'm hearing resonate throughout the virtual hallways, if you will. Twitter and beyond. >> That's a good question. Like what is a collection itself? So we've talked a lot in the past about reusable content for Ansible. We talk a lot about roles and modules and we sort of put those off to the side a little bit and say, "These are your reusable components." You can put 'em anywhere you want. You can put 'em in source control, distribute them through email, it doesn't matter. And then your playbooks, that's what you write. And that's your sort of blessed content. Collections are really about taking the modules and roles and plugins, the things that make automation possible, and bundling those up together in groups of content, groups of modules and roles, or standing by themselves so that you can decide how that's distributed and how you consume that, right? Like you might have the Azure, VMware or Red Hat satellite collection that you're using. And you're happy with that. But you want a new version of Ansible. You're not bound to using one and the same. You can stick with the content that matters to you, the roles, the modules, the plugins that work for you. And you decide when to update those and you know, what the actual modules and plugins you're using are. >> So I got to ask the content question, you know, I'm a content producer. We do videos as content, blog posts content. When you talk about content, it's code, clarify that role for us because you got, you're enabling developers with content and helping them find experts. This is a concept. Robyn, talk about this. And Matt, you can weigh in, too, define what does content mean? It means different things. (indistinct) again, content could be. >> It is one of those words, it's right up there with developers, you know, so many different things that that can mean, especially- >> Explain content and the importance of the semantics of that. Explain it, it's important that people understand the semantics of the word "content" with respect to what's going on with Ansible. >> Yeah, and Matt and I actually had a conversation about the murkiness of this word, I believe that was yesterday. So what I think about our content, you know, and I try to put myself in the mind, my first job was a CIS admin. So I try to put myself in the mind of someone who might be using this content that I'm about to attempt to explain. Like Matt just explained, we've always had these modules, which were included in Ansible. People have pieces of code that show very basic things, right? If I get one of the AWS modules, it would, I am able to do things like "I would like to create a new user." So you might make a role that actually describes the steps in Ansible, that you would have to create a new user that is able to access AWS services at your company. There may be a number of administrators who want to use that piece of stuff, that piece of code over and over and over again, because hopefully most companies are getting bigger and not smaller, right? They want to have more people accessing all sorts of pieces of technology. So making some of these chunks accessible to lots of folks is really important, right? Because what good is automation, if, sure we've taken care of half of it, but if you still have to come up with your own bits of code from scratch every time you want to invoke it, you're still not really leveraging the full power of collaboration. So when we talk about content, to me, it really is things that are constantly reusable, that are accessible, that you tie together with modules that you're getting from collections. And I think it's that bundle, you can keep those pits of reusable content in the collections or keep them separate. But, you know, it's stuff that is baked for you, or that maybe somebody inside your organization bakes, but they only have to bake it once. They don't have to bake it in 25 silos over and over and over again. >> Matt, the reason why we're talking about this is interesting, 'cause you know what this points out, in my opinion, it's my opinion. This points out that we're talking about content as a word means that you guys were on the cutting edge of new paradigms, which is content, it's essentially code, but it's addressable, community it's being shared. Someone wrote the code and it's a whole 'nother level of thinking. This is kind of a platform automation. I get it. So give us your thoughts because this is a critical component because the origination of the content, the code, I mean, I love it. Content is, I've always said content, our content should be code. It's all data, but this is interesting. This is the cutting edge concept. Could you explain what it means from your perspective? >> This is about building communities around that content, right? Like it's that sharing that didn't exist before, like Robyn mentioned, like, you know, you shouldn't have to build the same thing a dozen times or 100 times, you should be able to leverage the capabilities of experts and people who understand that section of automation the best, like I might be an expert in one field or Robyn's an expert in another field, we're automating in the same space. We should be able to bring our own expertise and resources together. And so this is what that content is. Like, I'm an expert in one, you're an expert in another, let's bring them together as part of our automation community and share them so that we can use them iterate on them and build on them and just constantly make them better. >> And the concepts are consumption, there's consumption of the content. There's the collaboration of the content. There's the sharing, all this, and there's reputation, there's expertise. I mean, it's a multi sided marketplace here, isn't it? >> Yeah. I read a article, I don't know, a year or two ago that said, we've always evolved in the technology industry around, if you have access to this, first it was the mainframes. Then it was, whatever, personal computers, the cloud, now it's containers, all of this, but, once everybody buys that mainframe or once everybody levels up their skills to whatever the next thing is that you can just buy, there's not much left that actually can help you to differentiate from your competitors, other than your ability to actually leverage all of those tools. And if you can actually have better collaboration, I think than other folks, then that is one of those points that actually will get you ahead in your digital transformation curve. >> I've been harping on this for a while. I think that cloud native finally has gone, when I say "mainstream" I mean like on everyone's mind, you look at the container uptake, you're looking at containers. We had IDC on, five to 10% of the enterprises are containerizing. That's huge growth opportunity. The IPO of, say, Snowflake's on Amazon. I mean, how does this happen? That's a company that's went public, It's the most valuable IPO in the history of IPOs on Wall Street. And it's built on Amazon, it has its own cloud. So it's like, I mean, this points to the new value that's being created on top of these new cloud native architectures. So I really think you guys are onto something big here. And I think you're starting to see this, new notions of how things are being rethought and reimagined. So let's keep it, while I've got you guys here real quick, Ansible 2.1 community release. Tell us more about the updates there. >> Oh, 2.10, because, yeah. Oh, that's fine. I know I too have had, I'm like, "Why do we do that?" But it's semantic versioning. So I am more accustomed to this now, it's a slightly different world from when I worked on Fedora. You know, I think the big highlight there is really collections. I mean, it's collections, collections, collections. That is all the work that we did, it's under the hood, over the hood, and really, how we went from being all in one repo to breaking things out. It's a big line for, we're advancing both the tool and also advancing the community's ability to actually collaborate together. And, you know, as folks start to actually use it, it's a big change for them potentially in how they can actually work together in their organizations using Ansible. One of the big things we did focus on was ensuring that their ease of use, that their experience did not change. So if they have existing Ansible stuff that they're running, playbooks, mod roles, et cetera, they should be able to use 2.10 and not see any discernible change. That's all the under the hood. That was a lot of surgery, wasn't it, Matt? Serious amounts of work. >> So Matt, 2.10, does that impact the release piece of it for the developers and the customers out there? What does it change? >> It's a good point. Like at least for the longer term, this means that we can focus on the Ansible core experience. And this is the part that we didn't touch on much before now with the collections pieces that now when we're fixing bugs, when we're iterating and making Ansible as an engine of automation better, we can do that without negatively impacting the automation that people actually use. We could focus on the core experience of actually automating itself. >> Execution environments, let's talk about that. What are they, are they being used in the community today? What do you guys react to that? >> We're actually, we're sort of in the middle of building this right now. Like one of the things that we've struggled with is when you, you need to automate, you need this content that we've talked about before. But beyond that, you have the system that sits underneath the version of Linux, the kernel that you're using, going even further, you need Python dependencies, you need library dependencies. These are hard and complicated things, like in the Ansible Tower space, we have virtual environments, which lets you install those things right alongside the Ansible Tower control plane. This can cause a lot of problems. So execution environments, they take those dependencies, the unit that is the environment that you need to run your automation in, and we're going to containerize it. You were just talking about this from the containerization perspective, right? We're going to build more easily isolated, easy to use distinct units of environments that will let you run your automation. This is great. This lets you, the person who's building the content for your organization, he can develop it and test it and send it through the CI process all the way up through production, it's the exact same environment. You could feel confident that the automation that you're running against the libraries and the models, the version of Ansible that you're using, is the same when you're developing the content as when you're running it in production for your business, for your users, for your customers. >> And that's the Nirvana. This is really where you talk about pushing it to new limits. Real quick, just to kind of end it out here for Ansible 2020, AnsibleFest 2020. Obviously we're now virtual, people aren't there in person, which is really an intimate event. Last year was awesome. Had theCUBE set right there, great event, people were intimate. What's going on for what you guys have for people that obviously we got the videos and got the media content. What's the main theme, Robyn and Matt, and what's going on for resources that might be available for folks who want to learn more, what's going on in the community, can you just take a minute each to talk about some of the exciting things that are going on at the event that they should pay attention to, and obviously, it's asynchronous so they can go anywhere anytime they want, it's the internet. Where can they go to hang out? Is there a hang space? Just give the quick two second commercial, Robyn, we'll start with you. >> All right. Well of course you can catch the keynotes early in the morning. I look forward to everybody's super exciting, highly polite comments. 'Cause I hear there's a couple people coming to this event, at least a few. I know within the event platform itself, there are chat rooms for each track. I myself will be probably hanging out in some of the diversity and inclusion spaces, honestly, and I, this is part of my keynote. You know, one of the great things about AnsibleFest is for me, and I was at the original AnsibleFest that had like 20 people in Boston in 2013. And it happened directly across the street from Red Hat Summit, which is why I was able to just ditch my job and go across the street to my future job, so to speak. We were... Well, I just lost my whole train of thought and ruined everything. Jeez. >> We got that you're going to be in the chat rooms for the diversity and community piece, off platform, is there a Slack? Is there like a site? Anything else? 'Cause you know, when the event's over, they're going to come back and consume on demand, but also the community, is there a Discord? I mean, all kinds of stuff's going on, popping up with these virtual spaces. >> One thing I should highlight is we do have the Ansible Contributor Summit that goes on the day before AnsibleFest and the day after AnsibleFest. Now, normally this is a pretty intimate event with the large outreach that we've gotten with this Fest, which is much bigger than the original one, much, much, much bigger, we've, and signing up for the contributor summit is part of the registration process for AnsibleFest. So we've actually geared our first day of that event to be towards new or aspiring contributors rather than the traditional format that we've had, which is where we have a lot of engineers, and can you remember sit down physically or in a virtual room and really talk about all of the things going on under the hood, which is, you know, can be intimidating for new people. Like "I just wanted to learn about how to contribute, not how to do surgery." So the first day is really geared towards making everything accessible to new people because turns out there's a lot of new people who are very excited about Ansible and we want to make sure that we're giving them the content that they need. >> Think about architects. I mean, SREs are jumping in, Matt, you talked about large scale. You're the chief architect, new blood's coming in. But give us an update on your perspective, what people should pay attention to at the event, after the event, communities they could be involved in, certainly people want to tap into you are an expert and find out what's going on. What's your comment? >> Yeah, you know, we have a whole new session track this year on architects, specifically for SREs and automation architects. We really want to highlight that. We want to give that sort of empowerment to the personas of people who, you know, maybe you're not a developer, maybe you're not, operations or a VP of your company. You're looking at the architecture of automation, how you can make our automation better for you and your organization. Everybody's suffered a lot and struggled with the COVID-19. We're no different, right? We want to show how automation can empower you, empower your organization and your company, just like we've struggled also. And we're excited about the things that we want to deliver in the next six months to a year. We want you to hear about those. We want you to hear about content and collections. We want you to hear about scalability, execution environments, we're really excited about what we're doing. You know, use the tools that we've provided in the AnsibleFest event experience to communicate with us, to talk to us. You can always find us on IRC via email, GitHub. We want people to continue to engage with us, our community, our open source community, to engage with us in the same ways that they have. And now we just want to share the things that we're working on, so that we can all collaborate on it and automate better. >> I'm really glad you said that. I mean, again, people are impacted by COVID-19. I got, it sounds like all channels are open. I got to say of all the communities that are having to work from home and are impacted by digital, developers probably are less impacted. They got more time to gain, they don't have to travel, they could hang out, they're used to some of these tools. So I think I guess the strategy is turn on all the channels and engage in new ways. And that seems to be the message, right? >> Yeah, exactly. >> Alright, Robyn Bergeron, great to see you again, Matt Jones, great to chat with you, chief architect for Ansible Automation Platform and of course, Robyn senior manager for the community team. Thanks so much for joining me today. I appreciate it. >> Thank you so much. >> Okay. It's theCUBE's coverage. I'm John Furrier, your host. We're here in the studio in Palo Alto. We're virtual. This is theCUBE virtual with AnsibleFest virtual. We're not face to face. Thank you for watching. (calm 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)