(upbeat music) >> Hello, welcome to theCUBE's coverage of AnsibleFest 2021 virtual; I'm John Furrier, your host of theCUBE. We've got a great power panel here from Kyndryl whose great company has spun out of IBM. IT services great, technology, great conversation. Scott Kinane, director of worldwide automation, Anand Gopalakrishnan, chief automation architect, love the title, from Kyndryl, and Lisa Chavez, automations architect from Kyndryl. Guys, thanks for coming on. Appreciate the conversation. Looking forward to it. >> Thanks John glad to be here. >> Thank you. >> Scott, we covered you guys at IBM Think 2021, the new name, everything's happening. The extreme focus, the tactical execution has been pretty much on cloud, cloud native automation. This is the conversation. Knowing how much has gone behind the new name, can you just take a minute to share, give us an update on who Kyndryl is and how that's going? >> Yeah, I'd love to. You know, as Kyndryl, we really have the privilege of being responsible for designing, building, managing, and modernizing, you know, the mission critical systems that the world depends on every day, you know? When our thousands of clients span every industry and are leaders in their industries, right? You run the mission critical application environments for, you know, seven of the 10 largest airlines, 28 of the top 50 banks, right? All the largest mobile providers. You know, most of the largest retailers out there, and so on and so forth, right? That these companies really trust us to ensure that their business operations are really flawlessly being run. And operating our scale, and with the quality that these clients demand, is only possible by doing enterprise strength automation. Right? It's only, you know, it's not only about reactive automation, but using intelligent automation so we can predict and prevent issues before they really become a problem. Right? And because of our intelligent approach to automation, our clients have a... you know, they get tremendous business benefits for it, right? Retailers can open stores faster because systems and services are deployed more efficiently, right? Banks ATM's right, we all depend on those day to day, you know. They're working when you need them with our automation behind the scenes. You know, healthcare systems are more robust and responsive because we monitor for potential breaks and prevent them before they occur, right. Data processing systems, right. We hear about breaches all the time, right? Our clients are more secure because their environments are checked into, are checked to ensure that security exposures are quickly discovered and intermediated, right? So like automation, orchestration, intelligence, driving the world's digital economy, right. If you ask what Kyndryl is it, you know, that's our DNA. And it's really what we do well. >> Yeah, what's interesting, I want to get you to just quick followup on that because the name implies kind of a fresh perspective, working together. There's a lot of shared experiences and that. And the new normal now is honestly with hybrid and virtual continuing, people are doing things differently. And I would like you, if you don't mind taking a minute to share about the automation environment that you guys are operating in, because it's a different approach, but the game is still the same. Right? (John and Scott laugh) You got to make sure that these things are scaling and people are working again. So it's a combination of people and technology, in a new equation. Take a minute to talk about that. >> Yeah, I'd love to. You know, and you're right, right; the game is really changing. And automation is really ingrained into, needs to be ingrained in the way everybody's approaching what they do day to day. And if you talk about automation, in a way it's really included in what we do in our BAU delivery operations, right. And we do it at a tremendous scale, right. Where we have, you know, millions of infrastructure components and applications managed with automation, right. We're going to talk a little bit about CACF here in a few minutes, right? We've got over half a million devices themselves boarded onto that, and we're running over 11 million automations on a month to month basis through that, through the, the Red Hat technology that that's built on, right. We've got RPA as a key part of our environment, running millions of transactions through that on a yearly basis, right. And our automation's really covering the entire stack, right? It's not just about traditional IT, but we cover public cloud, private cloud, hybrid, you know, network components, applications and business processes, right? You talked about people, right. Help desk, right. We cover automation to automate a lot of the help desk processes are happening behind the scenes; security and resiliency. And it's really about driving all that through, you know, not just prescriptive reactions, but you know, us using our experience; insights we have from our data lakes, and intel, and AI ops technologies, and really making proactive based decisions based on that to really help drive the value back for our clients and to ensure that they're operating the way they need to. >> Yeah, that systems mindset, outcome driven focus is unique. That's awesome, congratulations. And onto Lisa, we're going to get into the architect side of it, because you're seeing more and more automation at the center of all the conversation. Reminds me of the machine learning AI vibe a couple of years ago. It's like, oh yeah, everything's MLAI. Automation, now everything's automation. Anand, your title is chief automation architect, love that title. What do you do? Like, I mean, you're architecting more automation, are you? Could you take a minute to explain your role? I love the title. And automation is really the technology driving a lot of the change. What do you do? >> Thank you, John. So let me first thank you for allowing us to come and speak to you and inform here about what we have done using Ansible and the other Red Hat products. So Ansible is one of the many products that we have used within Red Hat to support the solution that we have deployed, Paul, as our automation community framework, right? So, Scott touched upon it a few minutes earlier in terms of what are we doing for our clients? How do we make sure that our client's environment is secure? How do we make sure that our client environment is available all the time? So that... Are the infrastructure services that we're providing for our clients has a direct impact for their clients. So this is where the implementation of automation using the products that we have from Red Hat has helped us achieve. And we'll continue, we will continue to expand on supporting that, right. So let me break this into two parts. One is from an infrastructure standpoint, how we have implemented the solution and scaled it in such a way that we can support the number of devices that Scott was referring to earlier, And also the number of clients that we have touched on. And the second part, I'll let my colleague Lisa talk about the application architecture and the application scalability that we have, right? So firstly, we touch on infrastructure. So if you look at the way we needed to establish a capability to provide support for our clients, we wanted to make sure our infrastructure is available all the time, right? That's very important. So, before we even basically say, hey, we're going to make sure that our client's infrastructure is available all the time or our client's infrastructure is secure. And also we provide, we are able to provide the automation services for the infrastructure service that we're providing, right? So the stack that we built was to support our solution to be truly cloud native. So we began with of course, using OCP, which is the OpenShift cloud platform that we have. We relied on Red Hat CoreOS, which is basically enabling the automation platform to be deployed as a true cloud native application; that can be scalable to not just within one country, but multiple countries. Supporting data privacy that we need to have, supporting the compliance parts of that we need to support, and scalable to support the half a billion devices that we are supporting today. Right? So essentially, if you look at what we have, is a capability enabled on the entire stack of the Red Hat products that we have. And we are able to focus on ensuring that we are able to provide the automation by gaining efficiencies, right? If you look at a lot of automations that we have it's about biggest in complexities, right? So just think about the amount of risk that we are removing, and the quality that we are assuring from the qualified and standardized changes that we are basically implementing. Or, just, the amount of risk that we are able to eliminate by removing thousands of manual labor hours as well. So if you look at the automation need, it's not just about efficiency of the removal of labor hours, but efficiency of providing standards and efficiency of providing the capabilities that support our clients, who their needs; i.e. making sure that their infrastructure is compliant, their infrastructure is secure, and their infrastructure is highly available all the time. So it just basically making sure that we are able to address what we call as day one and day two activities, while we are able to support their day two infrastructure services activities; i.e. right from ground up. Building the server, which is provisioning, doing some provisioning activities, and deploying applications, and basically supporting the applications once they are deployed. So look at the scale, we have quite a bit there. >> So, you got the cloud native platform... >> Hey, careful Anand... >> You've got the cloud native platform, right? Let me just summarize that; cloud native platform for scale. So that means you're aligning, and targeting, and working with people who will want to do cloud native applications. >> Absolutely. >> And they want fast speed. (John laughing) >> Yes, and they want... >> They want everything to go faster. And by the way, the compliance piece is super important because if you can take that away from them, for waiting for the answers from the compliance department or security department, then that's the flywheel. Is that what you're getting at? This is the trend? >> Absolutely. So I'm going to turn it over to Lisa, who's going to help us. >> Yeah >> Go ahead Lisa >> Lisa, weigh in on the flywheel here. (Lisa chuckles) >> Yeah. Sure, sure. Yeah. So, so one of the things that CACF allows us to do, right, and it's again, as Anand described, `it's a very robust, powerful infrastructure. Supports many, many clients as we run a lot of applications through this infrastructure. And we do things like run security health checks on all our client's servers, and process the data real time and get that data out to our teams to address issues almost immediately, right? Scott touched on the fact that we are monitoring incident data real time and taking automated actions to correct problems in the environment. These are just really, really powerful capabilities that we're able to offer. We also have other use cases, we do a lot of identity management, primary and secondary controls through the CACF infrastructure. So we're able to have one point of connectivity into our client's environments. It's agentless, right, so you set up one connection to their servers and we can do a whole lot of management of various things through this single automation platform. So... >> So I, so that just to call this up, this is actually very powerful. And first of all, you mentioned the CACF that's the cloud automation community framework. >> Yes, correct. >> Right. >> Okay, so that's the platform. (Lisa chuckles) >> Yes >> Okay, so now the platforms' there; and now talk about the advantages. Because the power here is this truly highlights the transformation of DevOps, infrastructure as code, and microservices, coming around the corner where the developer; And I know developers want to build security into the applications from day one and take advantage of new services as they come online. That is now one. That puts the pressure on the old IT teams, the old security teams, who have been the NoOps. No, you can't do or slow, are slower. This is a trend, this is actually happening. And this culture shift is happening. Could you guys weigh in on that because this is a really important part of this story. >> Yeah. I mean, I think, you know, if you go back, circa 2019 or so, right. You know, we were back then and we were recognized as a leader in the automation space by a lot of the analysts. But we kind of look at that culture change you were just talking about and look at, you know, how do we become more agile? How do we go faster and what we're doing, right. And then I'm working with Jason McKerr and the Red Hat's Ansible automation platform team. We kind of define this platform that Lisa and Anand are talking to, right. Wrapping together, the OpenShift and Ansible, and 3scale with, you know, our services platform with Watson, and, and, you know, it really gave us the ability to leverage two of our core capabilities, right? The first, you know, in order for us to go faster, was our community model, right? Our community experience, right? So we've got a large delivery community that's out there really experts in a lot of, experts in a lot of technologies and industries. And, and by putting this in place, it gave us a way to really leverage them more in that community model development, so they could create, and we can harvest more of the automation playbooks. A lot of the different use cases that Lisa was talking incident remediation, patch scanning and deployment, security compliance, checking and enforcement. You know, basically anything that needs to get done as part of our what we'd call day one or day two operations we do for a client, right. And Steve's approach really to, to do a lot of high quality automation and get to the point where we could get thousands of automation modules that our clients could, that we could use as a part of our, a part of our services we delivered to the client environments. And, you know, that type of speed and agility, and being able to kind of leverage that was something that wasn't there previously. It also gave us a way to leverage, I guess they are one of our other core capabilities, right; which is a systems integrator, right? So we were able to focus more, by having that core engine in place, we were able to form focus more on our integrator experience and integrate, you know, IBM technologies, ServiceNow, ScienceLogic, VMware, and many more, right to the engine itself. So you know, basically, you know, all the applications out there that the, the clients then depend on for their business environments integrate directly with them; so we could more seamlessly bring the automation to their, to their environments, right. So it really gave us both the, the ability to change our culture, have a community model in place that we didn't before and really leveraged that services integrator expertise that we bring to the table, and act really fast on behalf of our clients out there. >> That's great stuff. Lisa, Lisa if you don't mind, could you share your thoughts on what's different about the community platform, and because automation has been around for a while, you do a couple of times, you do something repetitive, you automate it. Automate it out of way, and that's efficiency. Anand was the one saying that. >> Yeah but within Kyndryl, we have a very strong community and we have very strong security guidelines around what the community produces and what we deliver to our clients, right? So, we give our teams a lot of flexibility, but we also make sure that the content is very secure; we do a lot of testing. We have very strong security teams that do actual physical, penetration testing, right. They actually could try and come in and break things. So, you know, we really feel good about, you know, not only do we give our teams the flexibility, but we also, you know, make sure that it's safe for our clients. >> How's the relationship with Ansible evolving? Because as Ansible continues to do well with automation; automations now, like in automation as code, if things are discoverable, reuse is a big topic in the community model. How is Ansible factoring into your success? >> So... So firstly, I want to break this again into two discussions, right? One is the product itself. And second is how we have collaborated very closely with our colleagues at Red Hat, right? So essentially it's the feedback that we get from our clients, which is then fed into our solution, and then from our solution, we basically say, does it meet what our client's requirements are? If it doesn't, then we work with our Red Hat colleagues and say, hey, you know, we need some enhancements to be made. And we've been, we've been lucky enough to work with our colleagues at Red Hat, very closely, where we have been able to make some core product changes to support our clients requirements, right. And that's very, very important in terms of the collaboration from, with Red Hat, from a, you know, from a client standpoint. That's number one. Number two, from a product standpoint, Ansible, and the use of Ansible itself, right? Or Ansible Tower as the automation hub that we've been using. So we began this with a very base product capability, which was through what we call event automation. That was our first. Then we said, no, I think we can certainly look at expanding this to beyond event automation. I.e. can we do, when we say event that is very typically BAU activities, day two activities. But then we said, can we, can we do day one, day two infrastructure services automation? We said yes, why not? And then we worked again with our colleagues at Red Hat, identifying opportunities to improve on those. And we basically enhanced the framework to support those additional use cases that we basically identified. And as a matter of fact, we are continually looking at improving as well. In terms of not just hey, using the base product as is, but also receiving that feedback, giving that feedback to our Red Hat colleagues, and then implementing it as we go. So that's the, that's the approach we have taken. >> And what's the other half of the subject? Split it in two, What's the other half? >> Yep. But the other half is the actual implementation itself. So we like, which is basically expanding the use cases to go from beyond event automation to back from building the server, to also patching compliance. And now we're actually looking at even what we call service requests automation. By this is we basically want to be able to say hey user, we want a specific action to be performed on a particular end point. Can we take it to that next level as well? So that's where we are basically looking at as we progress. So we're not done. I would say we're still at the beginning of expansion. >> Yeah. >> Well no, I totally agree. I think it's early days, and I think a lot of it's, you mentioned day two operations; I love that. Day zero, day one, day two. Does anyone want to take a stab at defining what day two operations is? (John laughing) >> Do you want to go? >> Well, I got the experts here. It's good to get the definitions out there. >> Absolutely. >> 'Cause day one you're provisioned, right? >> Day zero, you provision. >> Day zero you provision. >> So day zero they look at... Yeah, so day zero you look at what is the infrastructure, what's the hardware that's there. And then day one you do what we call post provisioning activities, configuring everything that we need to do, like deploying the middleware applications, making sure the applications are configured properly, making sure that our, you know, the operating systems that we need to have. Whether it is a base operating system or operating systems for supporting the containers that are basically going to be enabled, all those will need to be looked at, right? So that's day one. Then day two is business as usual. >> Everything breaks on day two. (everyone laughs) >> Although I... >> Day one's fun, everything's good, we got everything up and running. We stood it up, and day two it breaks; And like, you know it's his fault. >> Exactly. >> Who's fault is it? (everyone laughing) So if you look at the approach that we took was, we said, let's start with the day two, then get to day zero, right. So which time where we have lots of lessons learned as we go through. And that's the expansion of how we are looking at Ansible. >> Well this is, all fun aside. First of all, it's all fun to have, to have to have jokes like that; but the reality is that the hardened operational discipline required to go beyond day one is critical, right? So this is where we start getting into the ops side where security downtime, disruptive operations, it's got to be programmable. And by the way, automation is in there too. So which means that it's not humans it's software running. Right? So, edge is going to complicate the hell out of that too. So, day two becomes super important from an architecture standpoint. You guys are the architects; what's the strategy, what should people be doing? What, what, how should, because day one is fun. You get it up, stand it up. But then it starts getting benefit; people start paying attention. >> Yep. _ And then you need to scale it and harden it. What's the strategy? What should people do? >> Yeah. I mean, if you think about automation, right? It's not... oh, I should, I meant to say John, you know, if it breaks, it's always Anand's fault, always Anand's. (John, Lisa, and Anand laugh) Don't ask any of that. >> I agree. >> Exactly. Thank you, Lisa. (everyone laughing) But, but automate, you know, you know, automation in a lot of conversations, people talk about it as gaining efficiency. And you know, it's not just that, you know, Automation is about de-risking complexities. Right? Think about all the risk that's removed, you know, and quality assured from the codified and standardized changes, right. Think about all the risk removed from eliminating, you know, tens of thousands of manual labor hours that have to be done. And those various things, right, that get done. So, for, we talk about day two operations, what we're doing, getting more automation in there, you know, our focus is definitely how do we de-risk changes? How do we make it safer for the clients? How do we make it more secure for the clients? And how do we ensure that their business operations, you know, are operating at their peak efficiencies? >> Yeah. And as I mentioned, we really go above and beyond on the security. We have much, much, much automated testing. And we also have the penetration testing I was talking about, so. We take security very seriously. Yeah. >> Yeah. >> I think what's interesting about what you guys are doing with the platform is, it's cloud native. You start to see not just the replatforming, but the fun parts. When you start thinking about refactoring applications and benefits start to come out of nowhere; I go new benefits, new net, new use cases. So I think the outcomes side of this is interesting. A lot of people talk about, okay let's focus on the cost, but there's now net new positive, potentially revenue impact for your customers. This is kind of where the game changes a lot. What do you guys think about that; 'cuz that's, you know, you always have this argument with folks who are very cost centric, repatriated for getting off the cloud, or let's look at the net new opportunities that are going to be enabled by rapid programming, identifying new workflows, automating them, and creating value. >> Yeah. I mean, this is, you know, you're talking about the future where we're going, things that we do, you know, obviously getting more closer to, and being directly aligned with the DevSecOps teams that are out there. You talk about day two, you know, the closer we are to those guys, the better for, for us and everybody else that's going there, going forward. You know, and as you know, businesses keep returning to their pre COVID level levels, you know, automation gives the possibility and that ones that we were doing gives possibility for hopefully the clients to do more of that revenue capture, right. Being able to, you know, be ahead a little bit earlier, being able to stand up retail stores faster, right. Being able to deploy business-based applications that are, generating revenue for the clients at a you know, you know, at a moment's notice. Things like that are really possible with automation, and possible with the way we've done this solution with Red Hat and our clients, right. And I think we've got tons of benefits there. We're seeing, you know, we've got almost 900 clients supported on it today, right. You know Anand hit on, we've got half a million plus devices that are connected to this, right. And we're seeing things where, you know, the clients are, are, that are on this are, are getting results, you know, Something such as 61% of all tickets being resolved with no human intervention, you know, 84% of their entire service base server base is being checked automatically for security and compliance daily. And, and, you know, we could go through lots of those different metrics, but the, you know, the fact we can do that for our clients gives, gives through automation, gives, you know, our engineers, our delivery community, the ability to closely more closely work with the client to do those revenue generation activities; to help them capture more, more revenue in the market. >> We'll just put that in context, the scale and speed of what's happening with those numbers; I mean, it's significant. It's not like it's a small little test. That's like large scale. Scale's the advantage of cloud. Cloud is a scale game. The advantage is scaling and handling that scale. What's your thoughts? >> Absolutely. So if you basically, again, when we started this, we started small, right. In terms of the use cases that we wanted to tackle, the number of devices that we said we could basically handle, right. But then once we saw the benefits, the initial benefits of how quickly we were able to fix some of the problems from a day one day, two standpoint; or address some of the compliance and patching issues that we needed to look at, right. We, we quickly saw opportunities and said, how fast can we go? And in terms of, well, it's not just how fast can we go in terms of setting up our own infrastructure by you know, saying, hey, we are cloud native. I can just spin up another container and, you know, make sure that I can have another a hundred servers onboarded to support, or a hundred that network devices to be onboarded to support and so on, right. So it was also the scale from a automation standpoint, where we needed to make sure that our resources were skilled, to develop the automations as well. So the scale is not in terms of just the infrastructure, but the scale is also in terms of people that can do the automation in terms of, you know, providing the services for our infrastructure, right. So that's how we approached it. People and then an application and infrastructure. So that included providing education in, in Kyndryl today rose to about 11,000 people that we have trained on Ansible, the use of Ansible, and the use of Ansible Tower, and just even doing development of the playbooks using Ansible. That's a theme. if you look at, if you look at, it's not just infrastructure scale. It's infrastructure scale, application to be able to scale to that infrastructure, and people to be able to scale to what we're trying to do to support our clients as well. >> I think the people think is huge because you have a side benefit here as harmony, and the teams. You got cohesiveness that breeds peace, not war. (everyone laughs) >> Absolutely. >> That's between teams. >> If you look at the, you know, the words that we said; cloud automation, community framework. If you really break it down, right, it's a framework, but for who? It's for the community. >> Yeah. >> But, what are they doing? They're building automation. >> Yeah >> And that is what >> The Security team wants to, >> the cloud is about, right? >> The security team wants to, make the apps go faster, The apps want to be fast, they don't want to be waiting. Everything's about going faster; Pass, shoot, score, as they say in sports. But, but, okay, I love this conversation. I think it's going to be the beginning of a big wave. How do people engage and how do I get involved if I want to use the cloud automation community framework? What's the consumption side for, how do you guys push this out there, and how do people engage with you? >> Scott do you want to take that one? >> Yeah. I mean the, the easiest way is, you know, Kyndryl, you know, we're, we're out there. We're, coming forward with our company, a spin off from IBM, come engage with our sales reps, come engage with our, our outsourcing, our social risk management service delivery organizations, and, and, you know, happy to get them engaged, get them on board, and get them using the automation framework we've got in place. >> That's awesome. Great. Well, great stuff. Love the automation conversation. Automation and hybrid are the big, big trends that are never going to stop. It's going to be a hybrid world we live in. And the edge is exciting. It's got, you mentioned the edge; it's just more and more action. It's a distributed computing paradigm. I mean, it really the same. We've seen this movie before Anand. Yeah, in tech. So now it's automation. So great stuff. Lisa, thank you for coming on; I appreciate it. >> Thank you. >> Thanks. >> Thank you, John. >> Thank you, John. We have coverage for Ansible Fest 2021. Power panel breaking down automation with Kyndryl. The importance of community, the importance of cohesiveness with teams, but more importantly, the outcome, the speed of development and security. I'm John for theCUBE, thanks for watching. (upbeat music)

(melodic music) >> Narrator: From around the globe, it's theCUBE. With digital coverage of AnsibleFest 2020. Brought to you by Red Hat. >> Hey, welcome back. Get ready, Jeff Frick here with theCUBE. Welcome back to our ongoing coverage of AnsibleFest 2020, it's virtual this year. But we've had a lot of great interviews and just coming off the keynotes, want to invite John Furrier in, he's been doing a lot of the keynotes and attending this thing for years. So John, first off, get your impressions of AnsibleFest 2020. >> Hey Jeff, great to cover this event. It's too bad we're not in person, we're virtual, theCUBE virtual AnsibleFest is virtual. Last year was in person, it's a really intimate event last year. And again with that theme, a similar vibe here for 2020 again, not face-to-face, but the content has that same kind of community vibe. Just some notable things just of the Keynote and some of the news is obviously last year they launched the Ansible Automation Platform. They've grown their collections community from five supported platforms to 50. And they launched the automation services catalog. So, you starting to see from the Keynotes, the positioning of Red Hat and Ansible. Just a series of announcements at AnsibleFest that include a lot integrations. Okay, and I think that's the key thing, obviously Kubernetes we heard at VMworld continued to take center stage in cloud native and CI/CD Pipeline. So yeah, with that, that's the vibe collections, collections, collections, and some new terminology, which could be confused depending on where you come from, but the word 'content' means something here and content is code and there's a collaboration aspect. And so, overall you seeing that positioning of agile, DevOps, security network automation and obviously community, a big part of Red Hat and Ansible is the core community and this future development environment of easy to consume, easy to code, easy to troubleshoot and built-in security and make it collaborative. That's the open-source ethos. And that's really the focus of AnsibleFest 2020 virtual. >> Yeah, I thought it was interesting. Richard Henshaw you know came out with, and it really reinforced the theme that automate and connect. And it's pretty interesting 'cause he talks about Ansible being the language of collaboration and how important collaboration is. And as we know with COVID and everybody working from home, now kind of the traditional methods of development teams getting together and a DevOps culture and doing daily stand-ups and having this kind of co-mingling of people isn't available anymore really as an option. So the pressure to collaborate is harder than ever before. So really an interesting twist for Ansible taking that tack that they are the language of collaboration. >> I liked his philosophy and some of his narrative around, he used to be a developer. They had a different group from their network-op brethren and they had different kind of siloed bill work together, it's all IT back in the day. But as things have become more cloud native, they have to integrate more and work together. And so this notion of collections is a big deal at Ansible. It's the idea of having these, these playbooks and having people be responsible for their playbooks and share those playbooks. They have a thing called content, which is how you can share these playbooks as content to be consumed and also collaborated and built on and with. But ultimately the theme around Ansible has always been a tool for automation. And now as a platform, the focus is making that automation platform wide across multiple environments, not just public cloud or on premises, it's edge, it's multicloud. So this idea of network automation has moved resources across the environments. And security is a big part of it. The automation platform for instance has a new 2.10 release, which brings back a huge amount of change releases where you don't have to be tied to the local host where you have this module updates are not directly tied to release cycles. Now this means that there's more availability of code. So network automation and updates, synchronous updates are huge. They talked about the VMware collection, IBM Z collections, all these things point to integrations. And that's really the focus of this integrate, this cloud native is, can I play well with others? This is again an extension to the community theme of open source. And if you're not integrating well in cloud native, you probably not going to be around longer. And that's a good theme for them. >> Yeah. So John, I wonder if you can unpack it a little bit, Robyn Bergeron and her Keynote went through this concept of the collection that I'm checking my notes here. They actually have three different types, they've got playbooks, roles, modules, PES, docks and plugins. And she talked about this is a way to basically aggregate information and share it in a bundle that other people can take full advantage of. >> Yeah, and I think that's the key of these collections. And I asked each of them when I was talking to them on camera prior to the event. And I say, what's the big theme for AnsibleFest this year? And they all said, Robyn was like collections, collections, collections. But the idea of writing code in a collection is all about Integry, so the VMware for instance is a great example. IBM Z, which is their mainframe piece. Ansible now part of Red Hat, and now Red Hat's part of IBM, you seeing that they now have more innovation going on with let's say mainframes. So the IBM Z integration allows Ansible to be compatible and bring a modern error to the mainframes. And this speaks to how people are working with these new roles and can leverage code in a new way. So, I think that's a real big thing about providing that last mile innovation and bringing it in other environments. Not just being on Ansible, but really integrating in with others. >> The other piece getting a lot attention John is OpenShift and the rule of OpenShift and the play of OpenShift. So how should people think about how OpenShift fits in this whole puzzle? >> I think OpenShift brings the Red Hat, a hybrid cloud automation piece to it, to Ansible, which is the, where the developers are playing with the CI/CD Pipeline. So the combination of, if you remember back in the days of OpenStack when we covered Red Hat and when OpenShift kind of really hit the scene, that was around private cloud. And then OpenShift adopted Kubernetes and that kind of cloud native vibe. And then since then the growth has been phenomenal. So when you take Red Hat's OpenShift, which is the cloud platform and you bring it to the automation platform of Ansible, it allows customers to have an easy to use capability to do hybrid and multicloud automation. And where this matters is where containers are getting traction. IDC was reporting numbers where only five to 15% of the enterprise, depending upon how you look at it are containerized, which means there's a huge surge of opportunity in these enterprises to bring containers into the cloud model. So for lift and shift and for modern workloads. So the OpenShift provides that path. So it's a nice compliment for the two together to work. So when we heard customers talking about the game system, one customer we talked about using Ansible Tower and the entire cloud, private cloud environment across data centers. So it's a good fit, automation with cloud. And honestly that's where the magic is. >> Right, right. The other piece that we keep hearing about over and over and over, and there's a play here as well as the edge, right. And really moving the compute closer to the place the data is generated and closer to the place that the data is consumed. But where do you see kind of the edge, the edge play here at AnsibleFest? (deep breath) >> Well this kind of ties into the earlier question about OpenShift and Ansible, that kind of automation meets hybrid cloud and addressing this like last mile aspect that Ansible provides in terms of load balancing, configuration, applications, application servers, pushing the apps to the edge. That's a big deal. And as 5G comes out and as edge becomes more, more important, you're going to need to have automation, the surface area of things (chuckles) to automate becomes critical. So the whole discussion is, it's larger scale, more devices, more code being shipped. This is where the engineers got to get involved early, bake security in from the beginning. But also have that automation capability, so it's not context switching between I ship some code, I got to troubleshoot it. They can all do it from within the Ansible platform. (hands rubs together) And that's where the traction with developers is. And this notion, this was the notion of sharing and collections and content become important because you have more people involved. And the betterment of the, of the collections and the crowd and the developers make sense. So edge is real and you got to have a software defined operational model. And you got to have a cloud piece like OpenShift, and you got to have an automation component like Ansible. So, this is a critical, whether you're talking space or 5G or inside an office or on a person, software defined operations will be the key. And that is a big trend that we're seeing right now. >> Yeah, so final question, John, what are you hoping to get out of this show, AnsibleFest 2020? Are there any open questions that you're hoping to get, get kind of answered or closed? Or what are you hoping to walk away with at the end of this event? >> Well, I'm curious to see how they handle the virtual event. Obviously the face to face is a very important intimate part of their community model. So I want to see how that goes. I want to see, I want to hear and look and squint through and connect the dots on the relationship with the Red Hat IBM acquisition, because Ansible is part of Red Hat and Red Hat is now (chuckles) part of IBM. So I think that's going to be a huge lift for Ansible, because once Ansible gets into the slipstream of IBM sales channels, that acceptance is going to be a really important factor for their growth. And then ultimately what's the developer trend? What new things are developers doing with automation that help customers have modern applications so that more, better apps can be deployed coming out of COVID, and as CXO's and the ivory tower of businesses change their business models, what new things are developers doing and how did that scale? So that's my, my key focus. >> All right, well that's great. Well, John, thanks for sharing your thoughts, your insight. And enough of us talking. Let's get to the tech athletes at AnsibleFest 2020. >> Awesome, thanks. >> Alright, he's John I'm Jeff. You're watching theCUBE with ongoing coverage of AnsibleFest 2020. Thanks for watching. We'll see you next time. (melodic music)

>> Announcer: From around the globe, it's The Cube. With digital coverage of Ansible Fest 2020 brought to you by Red Hat. >> Hello, welcome back to The Cube's coverage of Ansible Fest 2020. This is The Cube. Cube Virtual. I'm your host, John Furrier with The Cube and Silicon Angle. Two great guests here. Two engineers and architects. Michael McCarthy who is a architect at Delivery Engineering, who's giving a talk with Gamesys and Jurgen Grech who's a technical architect for the platform engineering team at Gamesys. Gentlemen, welcome to The Cube, thanks for coming on. >> Hello. >> Nice to see you. >> Coming in from London, coming in from Malta, you guys are doing a lot of engineering. You're a customer of Ansible, want to get into some of the cool things you're doing obviously Kubernetes automation, platform engineering, this is what everyone's working on right now that's going to be positioned for the future. Before we get started though, tell me a little bit about what Gamesys does and you guys' role. Michael, we'll start with you. >> Sure, so we're a gaming operator, we run multiple bingo-led and casino-led gaming websites, some of them are B2B, some are B2C. I think we've been doing it now for probably 14 or 15 years at least. I've been there for 12 and a half of those. So we essentially run gaming websites where people come and play their favorite games. >> And what's your role there? What do you do? >> So I'm in the operation side of things, I used to be a developer for 12 or so years. We make sure that everything's kind of up and running, we keep the systems running. My team in particular focuses on the speed of delivery for developers so we're constantly looking at, how long has it taken to get things in front of the customers, can we make it faster, can we make it easier, can we put cool stuff out there quicker? So it's a kind of platformy type role that I do, and I enjoy it a lot, so it's good. >> Jurgen you're platform engineering that sounds deep. >> Yes. >> Which is your role? (laughing) >> Well, I've been with Gamesys also for eight and a half years now. I hold the position of technical architect at the moment within this platform engineering group which is mostly tasked with all things ops related. I am responsible for designing, implementing and validating strategies for continuous deployment, whilst always ensuring high availability on both production and pre-production systems. I'm also responsible for the design and implementation of automated dynamic environment to support the needs of the development teams and also collaborating with other architects, especially those on the development floors in order to optimize the deployment and operational strategies for both existing and new types of services alike. >> Awesome, thanks for sharing that. Good, good context. Well, I mean, you don't have to be a rocket scientist to figure out that when you talk about gaming it's uptime and a high availability is critical. You know, having people, being the login you got to have the right data strategies, it can't be down, right. (laughs) It's a critical app. People are not going to enjoy it if they're not at, so I can see how scale's huge. Can you guys talk about how Ansible fits in because automation's been the theme here, you guys have been having a journey with automation. What's been your automation solution with Ansible? >> I'll go Michael. >> Yeah sure. >> So, basically back in July 2014, we started to look at Ansible to replace those commonly used, day to day, best scripts, which our ops team use to execute and which could lead to some human error. That was our main original goal of using Ansible at the time. At the time was our infrastructure looked considerably different. Definitely much, much smaller than the current private cloud footprint. And as I said, as early adopters within the operations team it was imperative for us to automate as much as possible. Those repetitive tasks, which involved the execution of various scripts and were prone to human error. Since then however, aware Ansible usage, it worked quickly. Since 2014, we went through two major infrastructure overhauls and automation using Ansible was always at the heart of each of those overhauls. In fact, our latest private cloud which is based on OpenStack is completely built from the ground up using Ansible code. So this includes the provision and co-visual machines, our entire networking stacks, so switches, routers, firewall, the SDN which OpenStack is built up on, our internal DNS system. Basically all you need to have a fully functional private cloud. At Gamesys we also have some workloads running in two different public clouds. And even in this case, we are running against the build code to set up all the required infrastructure components. Again, since we were fairly new adopters at the time of this technology, without all of those Ansible code, using the original as the case, cover now this has worked considerably and with enhancements of litigated modules polished public cloud, we've made the code look much cleaner, readable and ad approved. >> You made some great progress. Michael, you want to weigh in on this? Any thoughts on? >> Yeah, I think it's kind of, I mean, adding to what Jurgen said I think it's kind of everywhere. So, you know, you mentioned, you mentioned high availability, you mentioned kind of uptime, you know, imagine the people that operate the infra, the people who get called out and they're working 24 seven, you know, a lot of the things that they would do, the kind of run books they would use to, you know, restart something they're Ansible as well. So it's the deployment scripts, it's the kind of scripts that keep things running, it's the stuff that spins up the environments as Jurgen said. I've noticed a lot on the development side where, you know, we look at continuous delivery, people are running their own build servers. A lot of the scripting that people do, which, you know you'd imagine, might be done with say Bash, I think I've seen a lot of Ansible being used there amongst developers, I guess. Yeah, it's got an easy learning curve. It's all of those modules. A lot of the scripting around CD I think is Ansible. It plays quite nicely, you know, URI module and file modules and yeah, I think it's kind of everywhere I think. It's quite pervasive. >> Once again I said, when to get something going. Good, it's awesome. >> Yeah. Automation get great success. So it's been a big theme of Ansible Fest 2020 automation collectors, et cetera. But the question I have for you guys as customers, is how large of an IT estate were you looking to automate and where was the most imperative places to automate first? >> The most imperative items we wanted to automate first as I said, were those operational day to day tasks handled by our network operations team. Our estate is massive. So we are running our infrastructure across five different data centers around the world, thousands of virtual machines, hundreds of network components. So we, we deal with customers all around the world. So our point of presence is spread out around the world as well. And you can't really handle such kind of size without some sort of automation. And Ansible fit the bill perfectly, in my opinion. >> And so your goal is to automate the entire landscape. Are you there now? Where are you on that progress? >> I would say we're at a very advanced stage in that process. Since 2014 we've made huge strides. All of our most recent private cloud setups as I said, have been built from the ground up using Ansible. And I would say a good 90% plus of our operational tasks are handled using some kind of Ansible playbook. >> Yeah, that makes total sense. Michael you brought up the, you start early in people's, it spreads. Those are my words, but you were saying that. What kind of systems do people tend to start with at Ansible? And what's, where's that first sticky moment where it lands and expands and which teams jump on it first? Is it the developers? Is it more the IT? Take us through some of the how this all gets started and how it spreads. >> I think in the, the first time I remember using it was probably I think 2014, 2015. And it was what Jurgen mentioned. I was on the Dev side and we wanted a way to have consistency in how we deployed. We wanted to be able to deploy the exact same way, you know into earlier environments, into Dev environments as we did in staging and production. And, you know, someone kind of found Ansible and then someone in operations kind of saw it and they were happy with it and they felt comfortable using the, kind of getting up to speed. And I think it was hard to know where it really started first, but you sort of looked around and every team, every team kind of had it. So, you know, who actually started I'm not sure, but it's all over the place. >> He did. (laughs) >> Yeah. I think, you know, where people start with it first it probably depends if you're on the ops or the dev side, I think on the dev side you know, we're encouraging people to own their own deployment playbooks you know, you're responsible for the deployment of your system to production. Obviously you've got the network operations the not group sort of doing it for you, but you know, your first exposure is probably going to be writing a playbook to deploy your app or maybe it's around some build tooling, spinning up your own build environment but that's something you'll be doing. I know with Ansible and it's especially around this point of stuff because everything's in git, there's that collaboration which I never saw, obviously I saw people chatting over kind of slack in teams but in terms of being able to sort of raise PR's having developers raise PR's, having operations comment on them the same the other way around, that's been a massive change which I think has come from using Ansible. >> The collaboration piece is huge. And I think it's one of those things early on out of all the Ansible friends that I know that use it and customers and in the company product was just good. It just word of mouth, spreads it around and be like, this is workable, saves a lot of time and it's a pain point remover. Also enables some things to happen with now automation, but now it's mature. Right? So Jurgen I got to ask you in the maturation of all this automation you're talking about scale, you mentioned it. OpenStack, you guys got the private clouds, people use it for public cloud, I now see Red Hat has a angle on that. But when you think about the current modern state of the art today, you can't go anywhere without talking about Kubernetes. >> Yup. >> Kubernetes has really emerged on the scene to manage these clusters but yet it's just getting started. You have a lot of experience with Ansible and Kubernetes. Can you share your journey with Kubernetes and Ansible, and what's your reaction to that? >> Yes, so back in June 2016 Gamesys was developing a new gaming platform which was stood on now Kubernetes. Kubernetes at the time was fairly new to many at an enterprise level with only a handful of production systems online. So we were tasked to assess how we're going to bring Kubernetes into production. So we first, we identified the requirements to set up a production grade cluster and given our experience with Ansible, we embarked on a journey to automate the installation process. Again using Ansible this would ensure that all the required installation and configuration parameters as Michael mentioned, we are committing it, the code is shared with all the respective development teams for ease of collaboration and feedback. And we decided to logically divide our code into two. And we said, we're going to have an installation code in order to provide Kubernetes as a service. So this basically installs Docker onto every worker node. It installs cube lit, all the master playing components of Kubernetes installs core DNS, the container storage interface, and they full blown and cluster monitoring stack. Then we also had our configuration code which basically sets up name spaces, it labels nodes for specific uses at certain security policies according to the cluster use case and creates all the required role based access configurations. This need to split the code in two came about really with the growing adoption of Kubernetes because at the inception stage we only had the one team which had a requirement to use Kubernetes. However, with various teams getting on board each required their own flavor with their particular unique configurations. This is of course well managed quite easily to reduce of different Ansible inventories. And it's all integrated now within Ansible Tower with different unique drop templates to install and configure the Kubernetes clusters. We started as I said with just one pre-production or staging cluster in 2010 16. Today we manage 42 different Kubernetes clusters including six which are in production. >> What problems >> So, as I mentioned earlier >> I got to ask you 'cause Kubernetes certainly when it came out, I mean, that was a big fan boy of that. I was promoting Kubernetes from the beginning. I saw it as a really great opportunity to bring things together with containers. It turns out that developers love it for that reason. What, so getting your hands on is great, but as you moved it in to practice, what problems did it solve for you? >> So using Ansible, definitely solve the problem of ensuring that all of our 42 clusters across all the different data centers are running the same configuration. So they're running the same version. They're running the same security policies. They're running the same name space, according to the type. Each team has a similar deployment token. And it's very, very convenient to roll out changes and upgrades especially when all of our code has been integrated with Ansible Tower through a simple user interface click. >> How's Ansible Tower working for you? Is that going well? Ansible Tower? >> Eh, I would say so, yes. Most of our code now is integrated with Ansible Tower. It's allowed us to also share some of the tasks with a wider group of people. Within Peg we are the guardians of the production environments really. However, we share the responsibility of staging environments with the respective development teams, who primarily those environments. So as such, through the use of Ansible Tower we've managed to also securely and consistently share the same way how they can install and upgrade these clusters themselves without our involvement. >> Thank you. Michael you're giving, oh sorry go ahead. Go ahead Jurgen. >> Sorry is no no. >> Michael, you're giving a presentation breakout session at Ansible Fest. Can you give us a sneak peek >> Yup. >> Of what you're going to talk about? >> Yeah sure. So we, I said we've been using Tower for a long time. We've been using it since 2015 I think. Think we've probably made some mistakes along the way, I guess, or we've learned a lot of stuff from how we started then to now. So what it does is it follows this sort of timeline of how we started, why there was this big move to making an effort to put all of our deployment playbooks in Ansible. Why you would go to Tower over and above Ansible itself. It talks about our early interactions with quite an old version of Tower and now version two, things that we struggled with, then we saw version three came out there was loads and loads of really good stuff in version three. And it's really about kind of how we've used the new features, how it's worked out for us. It's kind of about what Gamesys have done with Tower but I think it's probably applicable to everyone and anyone that uses Tower I think will, they'll probably come across the same things, how do I scale it for multiple teams? How do I give teams the ownership to kind of own their own playbooks? How do I automate Tower itself? It talks about that. Sort of check pointing every few years about where we'd got to and what was going well and what was going less well. So, and a bit of a look forward to, what's going to come next with Tower. So we're constantly keeping up to date and we've got kind of roadmap for where we want to go. >> What's interesting about you guys is you think about look at OpenStack and then how Cloud came on the scene and Private Cloud has emerged with hybrid and obviously public, you guys are right on the wave of all this large scale stuff and your gaming app really kind of highlights that. And you've been through the paces with Ansible. So I guess my question, and you've got a lot of scar tissue and you got success to show for it too, a lot of great stuff. What advice would you give people who are now getting on the new wave, the bigger wave that's coming which is more users, more scale, more features more automation, microservices are coming around the corner. As long as I get more scale. What advice would you give someone who's coming on board with Ansible for the first time? >> I think there was, you were talking before about Kubernetes and it was so where we were, I think we'd got into containers kind of relatively early. And we were deploying Docker and we had some pretty big, kind of scary playbooks and they managed low balances and deployed Docker containers. And it was always interesting thinking how is this all going to change when Kubernetes comes along? And I think that's been really smooth. I think there's a really nice Ansible module that's just called gates. And I think it's really simple actually, it simplified a lot of the playbooks. And I think that the technologies can coexist quite happily. I don't think you have to feel like Kubernetes is going to change all of the investment you've made into Ansible. Even if you go down the route of Kubernetes operators, you can write them in Ansible. So I still think it's a very relevant tool even with Kubernetes being so kind of prevalent. >> Jurgen what's your thoughts on folks getting in now, who want to jump in and take advantage of the automation, all the cool stuff with Ansible? What advice would you give them? >> Yes, I would definitely recommend to look at their infrastructure set ups as they would look at their code. So break it down into small manageable components, start small, build your roles, make sure to build your roles properly for each of that small component. And then definitely look at Ansible Tower as a way to visualize and control the execution of your code. Make sure you're running it with the proper security policies with the proper credentials and all, they're not, of course so break anything which is at the production level. >> Michael McCarthy, Jurgen Grech two great engineers at Gamesys. Congratulations on your success and love to unpack the infrastructure and the scale you have and certainly automation, great success path. And it's going to get easier. I mean, that's what everyone's saying, it's going to get easier. Thanks for coming on. I appreciate the conversation. Thank you very much. >> Thank you, welcome >> Thank you, take care. Bye bye. >> I'm John Furrier with The Cube here in Palo Alto California. We're virtual, The Cube virtual for Ansible Fest 2020 virtual. Thank you for watching. (upbeat music)

>> Welcome back to AnsibleFest. I'm Matthew Jones, I'm the architect of the Ansible Automation Platform. And today I want to talk to you a little bit about what we've got coming in 2021, and some of the things that we're working on for the future. Today, I really want to cover some of the work that we're doing on scale and flexibility, and how we're going to focus on that for the next year. I also want to talk about how we're going to help you grow and manage and use your content on the Automation platform. And then finally, I want to look a little bit beyond the automation platform itself. So, last year we introduced Ansible Content Collections. Earlier this year, we introduced the Ansible Automation Hub on Red Hat Cloud. And yesterday you heard Richard mentioned on private automation hub that's coming later this year. And automation hub, Ansible tower, this is really what the automation platform means for us. It's bringing together that content, with the ability to execute and run and manage that content, that's really important. And so what we really want to do, is we want to help you bring Red Hat and partner content that you trust together with community content from galaxy that you may need, and bring this together with content that you develop for yourself, your roles, your collections, the automation that you actually do. And we want to give you control over that content and help you curate that content and build a community around your automation. We want to focus on a seamless experience with this automation from Ansible Tower and from Automation Hub for the automation platform itself, and make it accessible to the automation and infrastructure that you're managing. Now that we've talked about content a little bit, I want to talk about how you run Ansible. Today an Ansible Tower, use virtual environments to manage the actual execution of Ansible, and virtual environments are okay, but they have some drawbacks. Primarily they're not very portable. It's difficult to manage dependencies and the version of Ansible. Sometimes those dependencies conflict with the other systems that are on the infrastructure itself, even Ansible Tower. So what we've done is created a new system that we call execution environments. Execution environments are container-based. And what we're doing is bringing the flexibility and portability of containers to these Ansible execution environments. And the goal really is portability. And we want to be able to leverage the tools that the community develops as well as the tools that Red Hat provides to be able to produce these container images and use them effectively. At Ansible we've developed a tool called Ansible Builder. Ansible builder will let you bring content collections together with the version of Ansible and Red Hats base container image so that you can put together your own images for execution environments. And you'll be able to host these on your own private registry infrastructure. If you don't already have a container registry solution, Automation Hub itself provides that registry. The idea here is that, unlike today where your virtual environments and your production execution environments diverge a little bit from what your developers, your content developers and your automation developers experience, we want to give you the same experience between your production environments and your development environments, all the way through your test and validation workloads. Red Hat's also going to provide some prebuilt execution environments. We want to have some continuity between the experience that you have today on the Ansible tower and what you'll have next year, once we bring execution environments into production. We want you to be able to trust the Ansible, the version of Ansible that's running on your execution environments, and that you have the content that you expect. At the same time, we're going to provide a version of the execution environment, that's just the base execution environment. All it has is Ansible. This will let you take those using Ansible builder, take the collections that you've developed, that you need in your automation and combine them without having to bring in things that you don't need, or that you don't want in your automation and build them together into a very opinionated, container image. If you're interested in execution environments and you want to know how these are built and how you'll use them, we actually have them available for you to use today. Shane McDonald and Adam Miller are giving a talk later with a walk through how to build execution environments and how you'll use them. You can use this to make sure that you're ready for execution environments coming to the automation platform next year. Now that we've talked about how we build execution environments, I want to talk about how execution runs in your infrastructure. So today when you deploy Ansible tower, you're deploying a monolithic web application. Your execution capability is tied up into how you actually deploy Ansible tower. This makes scaling Ansible tower and your automation workloads difficult, and everything has to be co-located together in the same data center. Isolated nodes solve this a little bit, but they bring about their own sort of opinionated challenges in setting up SSH and having direct connectivity between the control nodes and the execution nodes themselves. We want to make this more flexible and easier to use. And so one of the things that we've created over the last year and that we've been working on over the last year is something that we call receptor. Receptor is an overlay network that's an Automation Mesh. And the goal here is to separate the execution capability of your Ansible content from the control plane capability, where you manage the web infrastructure, the users, the role-based access control. We want to draw a line between those. We want you to be able to deploy execution environments anywhere. Chris Wright earlier today mentioned Edge. Well Edge Cloud, we want you to be able to manage data centers anywhere in the world, and you can do this with the Automation Mesh,. The Automation Mesh connects your control plane with those execution nodes, anywhere in the world. Another thing that the Automation Mesh brings is, we're going to be able to draw the lines between the control plane themselves and each Automation Mesh node. This means that if you have an outage or a problem on your network and on your infrastructure, if you can draw a line between the control plane itself and the node that needs to execute, the sensible work, the Automation Mesh can route around problems. The Automation Mesh in the way it's deployed, also allows this to fit closer with ingress and egress policies that you have between your infrastructure. It doesn't matter which direction the Automation Mesh itself connects in. Once the connection is established, automation will be able to flow from the control systems to the execution nodes and get responses back. Now, this all works together with automation of the content collections that we mentioned earlier, the execution environments that we were just talking about and your container registries. All of these work together with these Automation Mesh nodes. They're very lightweight and very simple systems. This means you can scale up and scale down execution capacity as your needs increase or decrease. You don't need to keep around a lot of extra capacity just in case you automate more, just because you're not sure when your execution capacity needs will increase and decrease. This fits into an automated system for scaling your infrastructure and scaling your execution capacity. Now that we've talked about the content that you use to manage, and how that execution is performed and where that execution is performed. I want to look a little bit beyond the actual automation platform itself. And specifically, I want to talk about how the automation platform works with OpenShift and Kubernetes. Now we have an existing installer for Ansible tower that we'll deploy to OpenShift Kubernetes, and we support OpenShift and Kubernetes as a first-class system for deploying Ansible tower. But I mentioned automation hub and Ansible tower as this is what the automation platform is for us. So we want to take that installer and replace it with an operator-based full life cycle approach to deploying and managing the automation platform on OpenShift. This operator will be available in OperatorHub. So there's no need to manage complex YAML files that represent the deployment. Since it's available in OperatorHub, you have one place that you can go to manage deployments, upgrades, backup and restore. And all of this work seamlessly with the container groups feature that we introduced last year. But I want to take this a little bit beyond just deploying and upgrading the automation platform from the operator. We want to look at what other capabilities that we can get out of those operators. So beyond just deploying and upgrading, we're also creating a resource operators and CRDs that will allow other systems running in OpenShift or Kubernetes to directly manage resources within the automation platform. Anything from triggering jobs and getting the status of jobs back, we want to enable that capability if you're using OpenShift and Kubernetes. The first place we're starting with this, is Red Hats Advanced Cluster Management system. Advanced Cluster Management brings together the ability to manage OpenShift and Kubernetes clusters to install them and manage them, as well as applications and products in managing the life cycle of those across your clusters. So what we really want to do, is give you the ability to connect traditional and container-based workloads together. You're already using the Ansible automation platform to manage workloads with Ansible. When using Advanced Cluster Management and OpenShift and Kubernetes, now you have a full system. You can manage across clouds across clusters, anywhere in the world. And this sort of brings me back to one of the areas of focuses for us. Our goal is complete end-to-end automation. We want to connect your people, your domains and the processes. We want to help you deliver for you and your customers by expanding the capabilities of the Ansible automation platform. And we want to make this a seamless experience to both curate content, control the content for your organization, and run the content and run Ansible itself using the full suite of the Ansible automation platform. So the Advanced Cluster management team is giving a talk later where you'll actually be able to see Advanced cluster Management and the Ansible automation platform working together. Don't forget to check out Adam and Shane's talk on execution environments, how those are built and how you can use those. Thank you for coming to AnsibleFest, and we'll see you next time.

>> Live from Orlando, Florida, it's The Cube, covering Cisco Live 2018. Brought to you by Cisco, Net App and The Cube's ecosystem partnership. >> Welcome back, we're here live at The Cube here in Orlando, Florida, for Cisco Live 2018. I'm John Furrier, Stu Miniman have been co-hosts all week here for three days live coverage. Day one and I'm winding down. Great keynotes, CEO of Cisco laying out the next generation network and it's not just the old networking, it's a whole nother thing. Our next guest is Salman Asadullah, who is the CTO and VP in Engineering at Netnology.io. Like technology, Netnology.io, former Cisco fellow been twenty- >> Distinguished engineer. >> Distinguished engineer, sorry, fellow engineer, well you look distinguished today. So how many years have you been at Cisco? >> 22 years. >> 22 years, welcome to The Cube. Thanks for joining us. >> Thank you for the invitation. >> So I got to ask you, before I get into the company, which we were talking before we came on camera, you doing really, I think you're on the front end of a big wave we see, certainly in The Cube, but you've been at Cisco 20 years and I've been working with Cisco since the beginning of time, 1993, in some capacity or another in the industry and I've had friends that have sold companies to Cisco. There's always been a debate within Cisco's engineering organization as to how to move up the stack. One team, yes no. So there's been but now it's time. Can you add some color and reaction to that because I think that's kind of where it is now. So all those conversations, even go back 15 years ago, where in the stack should we go? What's the right time? How about some of the history of Cisco and now they're moving up the stack. >> Yeah so I think first of all just to start with, our company name is Netnology.io but our tagline is full stack system integrator because we call ourselves a full stack system integrator because we know end networking, we know Cisco but we know how to move up in the stack as well. With the APIs and the STKs and what not. So the thing what is happened when you kind of look into this from Cisco's perspective, and I was there for 22 years, I am what I am because of Cisco, like when people say in Cisco when they work in Cisco I am Cisco but I still say I am Cisco because all of our business, 70% of our business is around Cisco. But the thing is when people are in Cisco, from Cisco's perspective when they say okay we are a software company and all of that good stuff, they look at the software from a networking perspective but the world, the industry when they say software, they are kind of talking about up in the stack from the application perspective. This is what you see even in Cisco they are sort of trying to pivot and all of the requisitions which are happening is around that. That they are acquiring companies which are basically up in the stack. There are more application based companies and also they are building organically some stuff in there as well. >> What's interesting is that the trend is their friend right now because they are getting to have their cake and eat it too. They are going to have best of both worlds. The networking is becoming more and more important with something to find and then you've got Kubernetes which Google Cloud is out there on the stage today. You've got Kubernetes and containers and Service Mesh is coming on that all look like networking. It's got words like policy, QOS, I mean this is networking world moving it up the stack. What does that mean for a customer? Is that the path in your mind? >> Yeah and I'm a big believer of that. I'm a big believer of that even before leaving Cisco for last five years of Cisco, I was basically working around all of these SDN, NFE, APIs and making sure in organizations I was leading or I was part of that how do I enable our engineering force to do some of that, to gain those capabilities. This is what we are trying to mimic on a much smaller scale in our company. That the way we sort of call it we are a bunch of hybrid engineers. The people who are CCIs but they can also code as well. This is our sort of a focus because just like what you said John, five years ago or three years ago when people talked about this stuff it was only about if you are a data center, cloud these things matter. But now, if you really see all Cisco's solutions are around APIs, around STKs, around SDN and NFE concepts. So let's say if you look into Cisco enterprise solution like SDA or SDVAN it's all around that. If you look into collaboration, Spark, Intropo it's all around that. So the point is that for any network, for any engineer or any organization to get to the next level they have to go through this evolution. >> And that's scaling too then. The network's got to scale and the new software environment. >> You bet. >> So there has been a big debate in the networking world, Salman, for many years, okay I ran networks, wait I have to be a coder. Maybe there's not that skillset. Will my solution providers and my software providers and the platforms I build on take care of some of that or is the traditional role of the network dead? You're saying your company's got a hybrid role but what percentage of people that are the CCIEs and the network admins today, how many of them need to be coding, developing, working with APIs and everything in the future? >> Yeah I think the way I sort of look at it that there's some push back. There is some push back but mainly more in the younger generation. They get it, they get it because if I give you an example of our company, we have 15 to 20 people company, the last two hires we had these were fresh grads, computer science grads and what I asked them to do, first six months go get your CCNA so then they start to understand some of the basics of the networking so they can work with our senior CCI engineers who know how to write 50 lines of five tone script but they can work with the coders to get bigger things developed. >> That's the new strategy from millennials. Throw them in CIE training, get them up to speed. Okay I got to ask you the question, because I want Netnology, the company that you're the co-founder of, is small but you're doing a unique thing. You're taking and SIE approach, obviously Cisco DNA is in your blood, you in the Cisco family if you will, but you still got to work with other platforms like Amazon and what not, as you guys go out there is a trend towards automation and we're seeing that professional services, whether they are from global SIs, the trend is towards accelerating down the cycle of deployment, faster, faster, faster, it's almost like the old days was eight months to roll out an SAP deployment, now that's eight weeks, now is it going to be eight minutes. This is the trend, it requires automation, what is your vision on how this is going to pan out going forward because this is the beginning of a new kind of Cloud scale at a service level. What's your vision? >> So if you really see from the compute world guys they were already doing that stuff for the longest time and they always asked us, the networking people, how come if my CAPEX is 30% but my OPPEX is 70% when it comes to the networking because we were lacking all of those capabilities. And the reason was that all the vendors they had these closed systems but now with this whole trend of SDN, NFE, people want to have more control. Cisco, and a lot of the vendors, they have all opened up their APIs and given the SD case so now you have the capability to go and take this talk to the compute guys. Say you are ahead of the game but we are catching up as well. By using all of these different tools what we are using in our deployments day in and day out. So if I give you an example, recently we did a project for a customer which was a multi-vendor fabric, VXLAN fabric, for data center, and we automated that whole deployment using Ansible Tower. So the thing is that if you would have done that manually, my God it would have taken a long time but now you can do it in minutes. >> Sal, talk about the Devnet explosion, because obviously we've reported all day today it came out in the keynote, over half a million developers are on Devnet, Susie Wee who's heading up Devnet and now Devnet Create which is the Cloud version of Devnet. Those two worlds are coming together and you're seeing network guys, even old school folks, adopting Cloud Navis. A natural migration and the younger guys are going and get networking as you pointed out. Devnet's been popular, you're seeing some great demos here. You can get a free Meraki Switch if you can code a little bit, take it home with you and play with it. A lot of tools, a lot of APIs as you're talking about, this is the new software development environment. What are you guys doing with Devnet? Can you share some insight into some of the things that you're doing that's relevant? Things that you're kicking the tires on? What's up? >> So first of all, to start with, we do a lot of work with Cisco Devnet and we are so humbled and honored by that because we get to learn while we are working on a lot of cool stuff. Then we can go sell that to our customers. Just to kind of tell you tomorrow, Susie Wee is announcing Devnet's cord exchange you might have heard about. So we are among those few partners who have contributed to that cord exchange. So we have put our code for everybody go get it, play with it, like we couple of use cases we have shared on that cord exchange, free for everybody. Think about you have Cisco VNFs running on AWFs how would you use cisco Cloud Center to model and deploy that service on AWFs? Using the APIs and then in the back end we have done scripting using Python and Shell and Ansible. These sort of things. And also we have a booth over here at the Devnet zone partner village and we are demonstrating some of these demos over there as well. >> That's really the standard now, people are getting the scale up in multiple clouds then deploying. That seems to be the big trend, automation there. >> Oh yeah, because as I said, the way we are partnered with Cisco we are also partnering with AWS and GCP so we have close to 35 certifications in our team including 13 CCIs. >> You're a veteran at Cisco, obviously to work at Cisco that long it's very entrepreneurial inside so it's always kind of been there. It's still a big company even when you were there but not you're an entrepreneur. What's it like on the other side? >> Oh my god, I'm living someone's dream. I'm blessed to be afford to do this. It's an awesome time for us. Of course it's a little stressful. >> Heavy lift there huh? It's not easy right? >> Me being in the silicon valley and I wanted to kind of do this but I tell you I recently Cisco included me in the Cisco designated VIP, which is a very selected group of people and worldwide, so I'm one of those people and I wrote a blog about that and I said something in there that although I have left Cisco but I don't feel like I've left Cisco because I'm still you know- >> Extended family. >> Yeah extended family. >> So what's up for the company, what's next? What's you're mission? Are you hiring? What are you working on? Share some insight into what's next for you guys? What's on your road map? >> So it's the growing pains. It's the growing pains, we are growing, our work is expanding. We are basically hiring some good talent. But more exciting something that we are also building a platform. So hopefully in the next six months we are going to be releasing something around that as well. Because again, think about we are recently named as a top 10 SDN providers by Enterprise Networking Magazine, so we are focusing on three Cisco SDN solutions. SDI in data center, SDA in branch and campus, and SDVAN on the VAN side. Now think about that you have segmentation in all of these solutions. How you can simplify this whole thing. How you can map these different perimeters between these three different solutions. So we are working on some cool ideas and some product as well so that's something really exciting for us. >> Are you guys self funded? >> Until now we are all privately funded. >> Sal, I'll put the hard question to you. As a startup, congratulations by the way, we know all about startups, we started a startup ourselves, it's growing pains but it's fun. It's hard work but it's a whole different joy. What problem are you solving? When you look at hiring an engineer what's the tough problem that you guys are trying to tackle? If you could boil it down into, the full stack great mission, what's the hard problem that you guys are trying to solve? >> So we just want to further simplify the Cisco story. As a matter of fact, in some of these SDN NFE based environments, that's our goal. How we can further simplify it. We are small enough that we can tackle some of these things. >> So tackle the complexity, that's where your mission is? >> Yes. >> Salman, thanks for coming on The Cube. Great to meet you, great to have you here. Thanks for sharing your insight here on The Cube with us live here- >> Very good, I appreciate the opportunity. >> Yeah let's follow up, love what you do. I think the future is going to be changing the game on how professional services are built, deployed and leveraged. Certainly code sharing. Collaboration is the new competitive behavior. You don't have to beat the other guy to win, you can work together. This is the new normal. This is what's going on at Cisco Live. Here in The Cube we're bringing you all the content. Stay with us, we'll see you tomorrow for day two of coverage. Thanks for watching.

>> Red Hat OpenShift Container Platform >> Announcer: Live from Boston, Massachusetts, it's theCube Covering Red Hat Summit 2017. Brought to you by Red Hat. >> Welcome back to theCube's coverage, I'm Rebecca Knight your host, here with Stu Miniman. Our guest now is Andrius Benokraitis, he is the Principle Product Manager at Ansible Red Hat Network Automation, thanks so much Andrius. >> Thanks for having me I appreciate it. >> This is your first time on the program. >> Andrius: First time. >> We're nice, >> Really nervous, so, okay. we don't bite. >> Start a little bit with your new to the company relatively >> Andrius: Relatively. >> networking guy by background, can you give us a little bit about your background. >> Sure, I mean, I actually started at Red Hat in 2003. And then did about four five jobs there for about 11 years. And then jumped, went to a startup named Cumulus Networks for about two years. Great crew, and then, now I'm at Ansible, been there since about December, so working on the Network Automation Use Case for Ansible. >> Alright, so networking, has a little bit of coverage here, I remember, you know, something like the Open Daylight stuff and I have, actually there are a couple of Red Hatters that I interviewed at one show ended up forming a company that got bought by Dockers, so you know, there's definitely networking people, but maybe give us a broad view of where networking fits into this stuff that you're working on specifically. >> Yeah, sure thing. I think it's interesting to point out that as everything started in the compute side, and everything started to get disaggregated, the networking side has come along for the ride per se. It's been a little bit behind. When we talk about networking a lot of people just think automatically that's the end. And we're actually trying to think a little bit lower level, so layer one, layer two, layer three, so switching, routing, firewalls, load balancers, all those things are still required in the data center. And when people started using Ansible, it started five years ago on the compute side, a lot of the people started saying, I need to run the whole rec, and I'm not a CCIE, and I don't really know what to do there but I've been thrown in to do something, I'm a cloud admin, the new title right. I have to run the network, so what do I do. I don't know anything about networking, I'm just trying to be good enough, well, I know Ansible, so why don't I just treat switches like servers, and just treat them like, like what I know, they just have a lot more interfaces, but they just treat it that way. So a lot of the expertise came from the ground up with the opensource model and said this is the new use case. >> Well, Jay Rivers, the founder of Cumulus, it's like networking will just be a Linux operating model, you know, extended to the network, which is always like, hey, sounds like a company like Red Hat should be doing that kind of stuff. >> Exactly, it's interesting to see a Bash prompt in the networking right, it's familiar to a lot of people, in the devop space, absolutely. >> So it's a very rapidly changing time, as we know, in this digital computing age, the theme of this conference is the power of the individual, celebrating that individual, the developer, empowering the developers to take risks, be able to fail, make changes, modify. You're not a developer, but you manage developers, you lead developers, how do you work on creating that context, that Jim Whitehurst talked about today. >> I think it starts with, the true empowerment, you have the majority of the networking platforms are still proprietary and walled off, walled off gardens, they're black boxes you can't really do much with them, but you still have the ability to SSH into them, you have familiar terms and concepts from the server side in the networking side. So as long as you have SSH in the box and you know your CLI commands to make changes, you can utilize that in part of Ansible to generate larger abstractions to use the play books in order to build out your data center, with the terms and the Lexicon of YAML, the language of Ansible, things that you already know and utilizing that and going further. >> Can you speak to us a little bit about customers, you know, what's holding them back, how are you guys moving them forward to the more agile development space? >> Our customers are mostly brownfield, they're trying to extend what they already have. They have all their gear, they have everything they have that they need but they're trying to do things better. >> I don't find greenfield customers when it comes to the network side of the house, I mean we've all got what I have and we knew that IT's always additive, so, I mean that's got to be a challenge. >> It's a huge challenge. >> Something you can help with right? >> It's a huge challenge, and I think from the network operators and network engineers, a lot of them are saying, again, they're looking at their friends on the compute side, and they can spin up VMs and provision hardware instantaneously, but why does it have to take four to six weeks to provision a VLAN or get a VLAN added to a network switch? That sounds ridiculous, so a lot of the network engineers and operators are saying, well I think I can be as agile as you, so we can actually work together, using a common framework, common language with Ansible, and we can get things done, and we can get all of this stuff I hate doing, and we don't have to do that anymore, we can worry about more important things in our network, like designing the next big thing, if you want to do BGP, design your BGP infrastructure, you want to move from a layer two to a layer three or an SDN solution. >> I love that you talk about everybody, kind of the software wave and breaking down silos, network and storage people are like, oh my God, you're taking my job away. >> Exactly, completely, no, we're not taking your job. We are augmenting what you already have. We're giving you more tools in your tool belt to do better at your job, and that's truly it, we don't have to, people can be smarter so, if you want to add a VLAN, that can be a code snippet created by the sys admin, it can be in Git, and then the network engineer can say, oh yeah, that looks good, and then I just say, submit. What we see today with some of the customers is, yeah, I want to automate, I really want to automate, and you say, great, let's automate. But then you start getting, you peel back the onion, and you start seeing that, well, how are you managing your inventory, how are you managing your endpoints. And they're like, I have a spreadsheet? And you're like, as a networking guy I guess you, (excited clamoring) >> Networking is scary for a lot, >> It's super scary, yeah. >> So how, do you break that down? >> You do what you can, you do it in small pieces, we're not trying to change the world, we're not trying to say, you're going to go 100% devops in the network. Start small, start with something, like again, you really hate doing, if you want to change, something really low risk, things you really hate doing, just start small, low risk things. And then you can propagate that, and as you start getting confidence, and you start getting the knowledge, and the teams, and every one starts, everyone has to be bought in by the way. This is not something you just go in and say, go do it. You have to have everyone on board, the entire organization, it can't be bottom up, it can't be top down, everyone has to be on board. >> And Andrius, when I talk to people in the networking space, risk is the number one thing they're worried about. They buy on risk, they build on risk, and the problem we have with the networks, they're too many things that are manual. So if I'm typing in some you know, 16 digit hexadecimal code >> From notepad, manually you're copying and pasting >> from like a spreadsheet. Copying and pasting, or gosh, so things like that, the room for error is too high. So there's the things that we need to be able to automate, so that we don't have somebody that's tired or just, wait, was that a one or an L or an I. I don't know, so we understand that it actually should be able to reduce risk, increase security, all the things that the business is telling you. >> All these network vendors have virtual instances. You can do all your testing and deployment, all your testing and your infrastructure, and you can do everything in Jenkins and have all your networking switches, virtually, you can have your whole data center in a virtual environment if you want. So if you talk about lower risk, instead of just copying and pasting, and oh was that a slash 24 or a slash 16, oops, I mean that looked right, but it was wrong, but did it go through test, it probably didn't. And then someone's going to get paged at three in the morning, and a router's down, an edge router's down and your toast. So enabling the full devops cycle of continuous integration. So bringing in the same concepts that you have on the compute side, testing, changes, in a full cycle, and then doing that. >> You talked about the importance of buy in and also the difficulties of getting buy in. How much of that is an impediment to the innovation process, but one of the things we've been talking about, is can big companies innovate? What are the challenges that you see, and how do you overcome them? >> That is the number one, that is the biggest issue right now in the network space, is getting buy in. Whether it's someone who has done it on their own, someone can just install Ansible and do something, and then deploy a switch, but if they leave the company and there's no remediation, if it's not in the MOP, if it's not in the Method of Procedure, no one knows about it. So it has to be part of your, you want to keep all the things you have, all the good things you have today with your checks and balances in the networking, and the CIOs and the people at the top have to understand, you can keep all that stuff, but you have to buy in to the automation framework, and everyone has to be onboard to understand how it fits in in order to go from where you are today to where you want to be. >> At the show here what's exciting your customers? You know, give us a little bit of a viewpoint for people that are checking out your stuff, what to expect. >> Well I think the one thing is they're not used to seeing, they think it's black magic, they think it's just magic. They're like, I can use the same things for everything? I say, yeah, you can. The development processes, the innovation in the community, you know for example, if you want to assist, go ACI Module, it's in GitHub, it's in Cisco's GitHub, you can just go ahead and do that. Now we're trying, starting to migrate those things into core. So the more that we get innovation in the community, and that we have the vendors and the partners driving it, and you're seeing that today, you know, we have F5 here we have Cisco, we have Juniper we have Avi, all those people, you know, they have certified platforms with Ansible, Ansible Core, which is going to be integrated with Ansible Tower, we have full buy in from them. They want to meet with us and say how can we do better. How can we innovate with you to drive the nexgen data centers with our products. >> You talked about yourself as a boomerang employee, what is the value in that, and are you seeing a lot of colleagues who are bouncing around and then coming back from ... >> Absolutely, I think pre acquisition Ansible, the vast majority of the people, I believe were ex-Red Hatters that went to Ansible. So what's really nice to come back home and understand the people that left, that came back to understand already what the, >> And people feel that way, it's a coming home? >> Yeah, it's a coming home, it really is. They understand, you know, they came back, they understood the values of opensource and the culture, again, I started Red Hat in 2003, I see the great things, I see new people getting hired and I see the same things I saw back then, 2003, 2004, with all the great things that people are doing, and the culture. You know, Jim's done a great job at keeping the culture how it is, even way back then when there was only 400 people when I started. >> Andrius, extend that culture, I think about the network community and opensource and you know, you talk about, there's risk there, and you know, you think about, I grew up with kind of enterprise, infrastructure mentality, it's like, don't touch it, don't play with it. We always joked, I got every thing there, really don't walk by it and definitely, you know, some zip tie or duct tape's going to come apart. Are we getting better, is networking embracing this? >> Yes, for sure. I think the nice thing is you start seeing these communities pop up. You're starting to see network operators and engineers, they've been historically, if they don't know the answer, they won't go find it. They kind of may be shy, shy to ask for help, per se. >> If it wasn't on their certification, >> Exactly. >> They weren't going to do it. >> If it wasn't there I'm not going to go, we're bringing them into, so we have, whether there's slack instance, there are networking communities, networking automation, communities, just for network automation. And there's one, there's an Ansible channel, on the network decode, select channel, has almost 800 people on it. So they're coming and now they have a place, they have a safe place to ask questions. They don't have to kind of guess or say, you know what, I'm not going to do that. And know they have a safe place for network engineers, for network engineers to get into the net devop space. >> Another one of the sort of sub themes of this summit is people's data strategy, and customers and vendors, how they're dealing with the massive amounts of data that they're customers are generating. What is your data strategy, and how are you using data? >> So there's two aspects here. So the data can be the actual playbooks themselves, the actual, the golden master images, so you can pull configs from switches, and you can store them and you can use them for continuous compliance. You can say, you know, a rogue engineer might make a change, you know, configuration drift happens. But you need to be able to make those comparisons to the other versions. So we're utilizing things like Git, so you're data strategy can be in the cloud, it can be similar on your side, you can do Stash locally. For part of the operations piece, you can use that. A second piece is, log aggregation is a big piece of the Ansible. So when you actually want to make sure that a change happens, that it's been successful, and that you want to ensure continuous compliance, all that data has to go somewhere, right? So you can utilize Ansible Tower as an aggregator, you can go off using the integrations like Splunk and some other log aggregation connectors with Ansible Tower to help utilize your data strategy with the partners that are really the driving, the people that know data and data structures, so we can use them. >> And one of the other issues is the building the confidence to make decisions with all the data, are you working on that too with your team? >> Yes, we are working with that, and that's part of the larger tower organization, so it goes beyond networking. So, whatever networking gets, everyone else gets. When we started developing Ansible Core and the community and Ansible Tower in-house, we think about networking and we think about Windows, that's a huge opportunity there, you know, we're talking about AWS in the cloud. So cloud instances, these are all endpoints that Ansible can manage, and it's not just networking, so we have to make sure that all of the pieces, all of the endpoints can be managed directly. Everyone benefits from that. >> Andrius thank you so much for your time we appreciate it. >> Thanks again for having me. >> I'm Rebecca Knight for Stu Miniman, thank you very much for joining us. We'll be back after this.