>> Announcer: From around the globe, it's theCUBE with digital coverage of Ansible Fest 2020, brought to you by Red Hat. >> Everyone welcome back to theCUBEs, virtual coverage of Ansible Fest 2020. I'm John Furrier, host of theCUBE, we're here virtual, we're not face to face obviously because of COVID. So we're doing a virtual event Ansible Fest coverage. We have Mary Johnston Turner, research Vice President of Cloud Management at IDC international data Corp. Mary great to see you, thanks for coming on for Ansible Fest 2020. >> Thanks for inviting me. >> So obviously Cloud Management, everything's Cloud native we're seeing that at VM world, we've got Re-invent coming up, Azure has got growth. The enterprises have gotten some religion on Cloud Native, COVID certainly is forcing that. What are you seeing from your research at IDC around the convergence of Cloud strategies. What's the data tell you, what's the research show? >> Well, obviously with COVID a lot of folks have pivoted or accelerated their move to the Cloud in many ways. And I think what's happening is that we're seeing many, many organizations recognizing they continue to have need for On-prem resources. They're building out edge, they've got remote work from home, they've got traditional VM workloads, They've got modern Cloud Native container-based workloads running On-Prem and in public Clouds and public Cloud services. So it's really kind of a striking world of connected Clouds is how I'm talking about it increasingly. And I think what that means from an operational perspective is that it's getting more and more challenging for organizations to maintain consistent configuration, stable APIs, security, compliance and conformance. And they're really starting to look at Automation as the way to deal with the increasing scale and velocity of change because that's one of the things that's happening. And I think COVID accelerated that is we've seen organizations stand up applications they never thought they were going to have to stand up and they not only stood them up very quickly, but then they continue to update them with great frequency often multiple times a day or a week. And and the infrastructure has had to pivot and the workloads have had to migrate. So it's really been a very challenging time for many organizations. And I think those that are coping the best with it are the ones who have been investing in Automation particularly Automation in CICD pipeline and code based environment. >> Yeah, you know, you're seeing the releases, obviously Automation has helped on the agile side, VMs and containers have been a great way to automate, how are customers looking at this? Because it seems to be Automation is like the first step towards everything as a service, right? So it's XAAS as it's says, as it's called in the industry. Services is ultimately the holy grail in all this because you get, when the Automation and services used to be Automation, Automation, Automation. Now you're hearing as a service, as a service, as a service as the top three priorities. So it seems to be a trajectory. How are customers getting first of all... Do you agree with that? And then how do customers think about this? Cause sometimes we're ahead of the customers. Automation is the first step. What's your take on this, and what are customers planning when it comes to Automation? Are they thinking as a service? What'd you hearing from the customers? >> Let's talk a little bit about what we mean by as a service. Cause that's a really interesting concept, right? And I've been hearing this conversation with folks as a service started a decade or more ago, taking things that particularly software that ran On-prem infrastructure or software. And putting it into share Data Centers where we could run Multi tenant Environments we could scale it, and each Cloud provider basically got that scale by investing in their own set of infrastructure Automation. So whether it was Azure or VMware or whoever, they build a whole repeatable, scalable environment that they could control. What's happening now is that we're seeing these control planes get stretched back to On-prem resources. And I think what's really happening is that the line about where does the thing physically have to run? Becomes more of a discussion around the physics of the matter, Latency, Data Volumes, transaction processing cost of installed equipment. And every organization is making its own choice about what's the right mix, in terms of where physically do things have to run, and how they want to manage them. But I think that we're starting to see a abstraction layer coming in between that. And a lot of that abstraction is Automation that's portable that can be applied across all these environments. And that can be used to standardize configurations, to maintain standard APIs, to deploy at very fast speed and consistency across all these different resources. And so Automation and the related management layer to me is that new abstraction layer that actually is going to allow most enterprises to stop worrying quite so much about (chuckles) what kind of as a service am I buying? And focus more on the economics and the performance and the physics of the infrastructure, and then maintain consistency with highly Automated, Repeatable, Programmable Style Environments that are consistent across all these different platforms. >> Yeah, that's a great point. It's great insight, I love that. It's almost, as you can almost visualize the boardroom. We need to change our business model as a service. Go do it, climb that hill, get it done, what are you talking about? What you're trying to manage workloads inside our enterprise and outside as they started looking at the workload aspect of it, it's not trivial to just say it, right? So your containers has barely filled the void here. How are customers and how are people getting started with this initial building block of saying okay, do we just containerize it? Cause that's another hand waving activity which has a lot of traction. Also you put some containers has got some goodness to it, are many people getting started with solving this problem? And what are some of the roadblocks of just managing these workloads inside and outside the enterprise? >> Well, again I think, yeah many organizations are still in the early stages of working with containers. Right now I think our research shows that maybe five to 10% of applications have been containerized. And that's a mix of lift and shift of traditional workloads as well as net new Cloud Native. Over the next couple of years almost enterprise has tell us to think a third of their workloads could be containerized. So it's ramping very, very quickly. Again, I think that the goal for many organizations is certainly containers allow for faster development, very supportive microservices, but increasingly it's also about portability. I talk to many organizations that say, yeah, one of the reasons I'm moving, even traditional workloads into containers is so that I have that flexibility. And again, they're trying to get away from the tight coupling of workloads to physical resources and saying I'm going to make those choices, but they might change over time or I might need to go what happens. I have to scale much faster than I ever thought. I'm never going to be able to do that my own data center, I'm going to go to the Cloud. So I think that we're seeing increasing investments in, Kubernetes and containers to promote more rapid scaling and increased business agility. And again, I think that means that organizations are looking for those workloads to run across a whole set of environments, geographies, physical locations, edge. And so they're investing in platforms and they count on Automation to help them do that. >> So your point here is that in five, 10% that's a lot of growth opportunity. So containers is actually happening now so you starting to see that progression. So that's great insight. So I've got to ask you on the COVID impact, that's certainly changed some orientation because hey, this project let's double down on this is a tailwind for us, work from home this new environment and these projects, maybe we want to wait on those, how do we come out of COVID? Some people have been saying, some spending in some areas are increasing, some are not, how are customers spending money on infrastructure with COVID impact? What are you seeing from the numbers? >> Well, that's a great question, and I do see one of the major things we do is track IT markets and spending and purchasing around the world. And as you might expect, if you go back to the early part of the year, there was a very rapid shift to Cloud, particularly to support work from home. And obviously there was a lot of investment in virtual desktops and remote work kinds of and collaboration very early on. But now that we're sort of maturing a little bit and moving into more of ongoing recovery resiliency sort of phase, we continue to see very strong spending on Cloud. I think overall it's accelerated this move to more connected environments. Many of the new initiatives are being built and deployed in Cloud environments. But again, we're not seeing a Whole Hog exit from On-prem resources. The other thing is Edge. We're seeing a lot of growth on Edge, both again there's sort of work from home, but also more remote monitoring, more support for all kinds of IOT and remote work environments, whether it's Lab Testing or Data Analysis or Contact Tracing. I mean, there's just so many different use cases. >> I'm going to ask you about Ansible and Red Hat. I see you've been following Ansible since the acquisition by Red Hat. How do you think they're doing Visa Vie the market, their competitors that have also been acquired? What's your take on their performance, their transition, their transformation? >> Well, this infrastructure is code or Automation is code market has really matured a lot over the last 10 or more years. And I think the Ansible acquisition was about five years ago now. I think we've moved from just focusing on trying to build elegant Automation languages, which certainly was an early initiative. Ansible offered one of the earlier human readable Python based approaches as opposed to more challenging programming languages that some of the earlier solutions had. But I think what's been really interesting to me over the last couple years with Red Hat is just what a great job they've done in promoting the community and building out that ecosystem, because at the end of the day the value of any of these infrastructures code solutions is how much they promote the connectivity across networks, Clouds, servers, security, and do that in a consistent, scalable way. And I think that's what really is going to matter going forward. And then that's probably why you've seen a range of acquisitions in this market over the last couple of years, is that as a standalone entity, it's hard to build those really robust ecosystems, and to do the analytics and the curation and the support at large scale. So it kind of makes sense as these things mature that they become fun homes with larger organizations that can put all that value around it. >> That's great commentary on the infrastructure as code, I totally agree. You can't go wrong by building abstraction layers and making things more agile. I want to get your take on some announcements that are going on here and get your thoughts on your perspective. Obviously they released with the private Automation hub and a bunch of other great stuff. I mean, bringing Automation, Kubernetes, and series of new features to the platform together, obviously continuation of their mission. But one of the things when I talked to the engineers is I say, what's the top three things, Ansible Fest, legal collections, collections, collections, so you start to see this movement around collections and the platform. The other thing is, it's a tool market and everyone's got tools we need a platform. So it's a classic tools. As you saw that in big data other areas where need start getting into platform, and you need management and orchestration you need Automation, services. What's your perspective on these announcements? Have they been investing aggressively? What does it mean? What's your take? And what does it mean? >> Yeah, I would agree that Red Hat has continued to invest very aggressively in Red Hat and in Ansible over the last few years. What's really interesting is if you go back a couple years, we had ASML engine, which included periodic, maybe every quarter or even longer than that distributions that pretty much all Ansible code got shipped on. And then we had tower which provided an API and a way to do some audit and logging and integration with source control. And that was great, but it didn't move fast enough. And we just got done talking about how everything's accelerated and everything's now connected Clouds. And I think a lot of what the Red Hat has done is really, approach the architecture for scale and ecosystem for scale. And so the collections have been really important because they provide a framework to not only validate and curate content but also to help customers navigate it and can quickly find the best content for their use cases. And also for the partners to engage, there's I think it's 50 plus collections now that are focused on partner content. And so it's I think it's really provided an environment where the ecosystem can grow, where customers can get the support that they need. And then with the Automation hub and the ability to support really robust source control and distribution. And again, it's promoting this idea of an Automation environment that can scale not only within a data center, but really across these connected environments. >> Great stuff. I want to get your thoughts cause I want to define and understand what Red Hat and Ansible, when they talk about curated content, which includes support for open shifts, versus pulling content from the community. I hear content I'm like, oh, content is that a video? Is that like, what is content? So can you explain what they mean when they say they're currently building out, aggressively building curated content and this idea of what does content mean? Is it content, is it code? >> Yeah, I think any of these Automation as code environments. You really have a set of building blocks that in the Ansible framework would be be modules and playbooks and roles. And those are relatively small stable pieces of code, much of it is actually written by third parties or folks in the community to do a very specific task. And then what the Ansible platform is really great at is integrating those modules and playbooks and roles to create much more robust Automations and to give folks a starting point, and ability to do, rather than having to code everything from scratch to really kind of pull together things that have been validated have been tested, get security updates when they need it that kind of thing. And so the customers can focus on essentially changing these things together and customizing them for their own environment as opposed to having to write all the code from step one. >> So content means what, in this context, what does content mean for them? >> It's Automation building blocks. It's code, it's small amounts of code that do very specific things (chuckles) and in a collections environment, it's tagged, it's tested, it's supported. >> It's not a research report like of a Cube video, it's like code, it's not content. >> Yeah, I know. But again, this is Automation as code, right? So it it's pieces of code that rather than needing an expert who understands everything about how a particular device or system works, you've got reusable pieces of code that can be integrated together, customized and run on a repeatable, scalable basis. And if they need to be updated cause an API changes or something, there's a chain that goes back to the the vendors who, again are part of the ecosystem and then there's a validation and testing. So that by the time it goes back into the collections, the customers can have some confidence that when they pull it down, it's not going to break their whole environment. Whereas in a pure community supported model, the contents made by the community, may be beautiful, but you don't know, and you could have five submissions that kind of do the same thing. How do you know what's going to work and what's going to be stable? So it's a lot of helping organizations get Automation faster in a more stable environment. >> We can certainly follow up on this train cause one of things I've been digging into is this idea of, open source and contribution, integrations are huge. The collections to me is super important because when we start thinking about integration that's one of Cloud native, supposedly strength is to be horizontally scalable, integrated, building abstraction layers as you had pointed out. So I've got to ask you with respect to open source. I was just talking with a bunch of founders yesterday here in Silicon Valley around as Cloud scales and certainly you seeing snowflake build on top of AWS. I mean, that's an amazing success story. You're starting to see these new innovations where the Cloud scale providers are providing great value propositions and the role open source is trying to keep pace. And so I got to ask you is still open source, let me say I believe it's important, but how does open source maintain its relevance as Cloud scale goes on? Because that's going to force Automation to go faster. Okay, and you got the major Cloud vendors promoting their own Cloud platforms. Yet you got the innovation of startups and companies. Your enterprises are starting to act like startups as container starts to get through this lift and shift phase. You'll see innovation coming from enterprises as well as startups. So you start to see this notion bring real value on top of these Clouds. What's your take on all this? >> Well, I think open source and the communities continue to be very, very important, particularly at the infrastructure layer, because to get all this innovation that you're talking about, you act, if you believe you've got a connected environment where folks are going to have different footprints and, and probably, you know, more than one public Cloud set of resources, it's only going to, the value is only going to be delivered if the workloads are portable, they're stable, they can be integrated, they can be secure. And so I think that the open source communities have become, you know, continue to be an incredibly important as a way to get industry alignment and shared innovation on the, on the platform and infrastructure and operational levels. And I think that that's, you know, going to be, be something that we're going to see for a long time. >> Well Mary, I really appreciate your insights, I got one final question, but I'll just give you a plug for the folks watching, check out Mary's work at IDC, really cutting edge and super important as Cloud management really is at the heart of all the, whether it's multicloud, on-premise hybrid or full Cloud lift and shift or Cloud native, management plays a huge important role right now. That's where the action is. You looking at the container growth as Mary you pointed out is great. So I have to ask you what comes next. What do you think management will do relative to Cloud management, as it evolves in these priority environments around Cloud, around on-premise as the operations start to move along, containers are critical. You talked about the growth is only five, 10%, a lot of headroom there. How is management going to evolve? >> Well, again, I think a lot of it is going to be is everything has to move faster. And that means that Automation actually becomes more and more important, but we're going to have to move from Automation at human speed to Automation at container and Cloud speed. And that means a lot is going to have to be driven by AI and ML analytics that can and observability solutions. So I think that that's going to be the next way is taking these, you know, very diverse sources of, of log and metrics and application traces and performance and end user experience and all these different things that tell us, how is the application actually running and how is the infrastructure behaving? And then putting together an analytics and Automation layer that can be a very autonomous. We have at IDC for doing a lot of research on the future of digital infrastructure. And this is a really fundamental tenant of what we believe is that autonomous operations is the future for a Cloud and IT. >> Final point for our friends out there and your friends out there watching who some are on the cutting edge, riding the big wave of Cloud native, they're at Cube calm, they're digging in, they're at service meshes, Kubernetes containers, you name it. And for the folks who have just been kind of grinding it out, an it operations, holding down the Fort, running the networks, running all the apps. What advice do you give the IT skillset friends out there that are watching. What should they be doing? What's your advice to them, Mary? >> Well, you know, we're going to continue to see the convergence of, of virtualized and container based infrastructure operations. So I think anyone out there that is in those sorts of roles really needs to be getting comfortable with programmatic code driven Automation and, and figuring out how to think about operations from more of a policy and scale scalability, point of view. Increasingly, you know, if you believe what I just said about the role of analytics driving Automation, it's going to have to be based on something, right? There's going to have to be rules. There's going to have to be policies is going to have to be, you know, configuration standards. And so kind of making that shift to not thinking so much about, you know, the one off lovingly handcrafted, handcrafted environment, thinking about how do we scale, how do we program it and starting to get comfort with, with some of these tools, like an Ansible, which is designed to be pretty accessible by folks with a large range of skillsets, it's human readable, it's Python based. You don't have to be a computer science major to be able to get started with it. So I think that that's what many folks have to do is start to think about expanding their skill sets to operate at even greater scale and speed. >> Mary, thanks so much for your time. Mary Johnston Turner, Vice President of Research at Cloud for Cloud management at IDC for the Ansible Fest virtual. I'm John Ferrier with theCUBE for cube coverage, cube virtual coverage of Ansible Fest, 2020 virtual. Thanks for watching.

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

(upbeat music) >> Narrator: From around the globe, it's theCUBE with digital coverage of Ansible Fest 2020 brought to you by Red Hat. >> Welcome back to theCUBE's coverage, Cube virtual's coverage of Ansible Fest 2020 virtual. We're not face to face this year. I'm your host John Furrier with theCube. We're virtual, this theCube virtual and we're doing our part, getting the remote interviews with all the best thought leaders experts and of course the Red Hat experts. We've got Walter Bentley, Senior Manager of Automation practice with Red Hat and Jason Smith, Vice President of North American services, back on theCube. We were in Atlanta last year in person. Guys, thanks for coming on virtually. Good morning to you. Thanks for coming on. >> Good morning John. Good morning, good morning. >> So since Ansible Fest last year a lot's happened where she's living in seems to be an unbelievable 2020. Depending on who you talk to it's been the craziest year of all time. Fires in California, crazy presidential election, COVID whole nine yards, but the scale of Cloud has just unbelievably moved some faster. I was commenting with some of your colleagues around the snowflake IBO it's built on Amazon, right? So value is changed, people are shifting, you starting to clear visibility on what these modern apps are looking like, it's Cloud native, it's legacy integrations, it's beyond lift and shift as we've been seeing in the business. So I'd love to get, Jason we'll start with you, your key points you would like people to know about Ansible Fest 2020 this year because there's a lot going on this year because there's a lot to build on and there's a tailwind for Cloud native and customers have to move fast. What's your thoughts? >> Yeah so, a lot has happened since last year and customers are looking to be a lot more selective around their automation technologies. So they're not just looking for another tool. They're really looking for an automation platform, a platform that they can leverage more of an enterprise strategy and really be able to make sure that they have something that's secure, scalable, and they can use across the enterprise to be able to bring teams together and really drive value and productivity out of their automation platform. >> What's the key points in the customers and our audience around the conversations around the learning, that's the new stuff happening in using Ansible this year? What are the key top things, Jason? Can you comment on what you're seeing the big takeaway for our audience watching? >> Yeah, so a lots change like you said, since last year. We worked with a lot of customers around the world to implement Ansible and automation at scale. So we're using our automation journeys as we talked about last year and really helping customers lay out a more prescriptive approach on how they're going to deliver automation across their enterprise. So customers are really working with us because we're working with the largest customers in the world to implement their strategies. And when we work with new customers we can bring those learnings and that experience to them. So they're not having to learn that for the first time and figure it out on their own, but they're really able to learn and leverage the experience we have through hundreds of customers and at enterprise scale and can take the value that we can bring in and help them through those types of projects much more quickly than they could on their own. >> It's interesting. We were looking at the research numbers and look at the adoption of what Ansible's doing and you guys are with Red Hat it's pretty strong. Could you share on the services side because there's a lot of services going on here? Not just network services and software services, just traditional services. What are the one or two reasons why customer engaged with Red Hat services? What would that be? >> Yeah so, like I said, I mean, we bring that experience. So customers that typically might have to spend weeks troubleshooting and making decisions on how they're going to deliver their implementations, they can work with us and we can bring those best practices in and allow them to make those decisions and implement those best practices within hours instead of weeks, and really be able to accelerate their projects. Another thing is we're a services company as part of a product company. So we're not there just to deliver services. We're really focused on the success of the customer, leveraging our technologies. So we're there to really train and mentor them through the process so that they're really getting up to speed quickly. They're taking advantage of all of the expertise that we have to be able to build their own experience and expertise. So they can really take over once we're gone and be able to support and advance that technology on their own. So they're really looking to us to not only implement those technologies for them, but really with them and be able to train and mentor them. Like I said, and take advantage of those learnings. We also help them. We don't just focus on the technologies but really look at the people in process side of things. So we're bringing in a lot of principles from DevOps and Agile on open practices and helping customers really transform and be able to do things in a new way, to be much more efficient, a lot more agile, be able to drive a lot more value out of our technology. >> Walter, I got to ask you, last year we were chatting about this, but I want to get the update. And I'd like you to just give us a quick refresh definition about the automation adoption journey because this is a real big deal. I mean, we're looking at the trends. Everyone realizes automation is super important at scale, as you think about whether it's software data, anything's about automation it's super important, but it's hard. I mean, the marketplace we were looking at the numbers. I was talking to IDC for you guys at this festival and of Ansible Fest, and they said about five to 10% of enterprises are containerized, which means this huge wave coming of containerization. This is about the automation adoption journey because you start containerizing, (laughs) right? You start looking at the workflows on the pipelinig and how the codes being released and everything. This is important stuff. Give us the update on the automation adoption journey and where it is in the portfolio. >> Well, yeah, just as you called it out, last year on main stage and Ansible fest, almost every customer expressed the need and desire to have to have a strategy as to how they drive their adoption of automation inside their enterprise. And as we've gone over the past few months of splitting this in place with many customers, what we've learned is that many customers have matured into a place where they are now looking at the end to end workflow. Instead of just looking at the tactical thing that they want to automate, they are actually looking at the full ribbon, the full workflow and determining are there changes that need to be made and adjusted to be more efficient when it comes to dealing with automation. And then the other piece as we alluded to already is the contagious nature of that adoption. We're finding that there are organizations that are picking up the automation adoption journey, and because of the momentum it creates inside of that organization we're finding other municipalities that are associated with them are now also looking to be able to take on the journey because of that contagious nature. So we can see that how it's spreading in a positive way. And we're really looking forward to being able to do more of it as the next quarter and the next year comes up. >> Yeah, and that whole sharing thing is a big part of the content theme and the community thing. So great reference on that, good thing is word of mouth and community and collaboration is a good call out there. A quick question for you, you guys recently had a big win with NTT DoCoMo and their engagement with you guys on the automation, adoption journey. Walter, what were some of the key takeaways? Jason you can chime in too I'd like to get some specifics around where it's been successful >> To me, that customer experience was one that really was really exciting, primarily because we learned very early on that they were completely embodying that open source culture and they were very excited to jump right in and even went about creating their own community of practice. We call them communities of practice. You may know them as centers of excellence. They wanted to create that very early in increment, way before we were even ready to introduce it. And that's primarily because they saw how being able to have that community of practice in place created an environment of inclusion across the organization. They had legacy tools in place already, actually, there was a home grown legacy tool in place. And they very quickly realized that it didn't need to remove that tool, they just needed to figure out a way of being able to how to optimize and streamline how they leverage it and also be able to integrate it into the Ansible automation platform. Another thing I wanted to very quickly note is that they very quickly jumped onto the idea of being able to take those large workflows that they had and breaking them up into smaller chunks. And as you already know, from last year when we spoke about it, that's a pivotal part of what the automation adoption journey brings to our organization. So to sum it all up, they were all in, automation first mindset is what that was driving them. And all of those personas, all of those personal and cultural behaviors are what really helped drive that engagement to be very successful. >> Jason, we'll get your thoughts on this because again, Walter brought up last year's reference to breaking things up into modules. We look at this year's key news it's all about collections. You're seeing content is a big focus, content being not like a blog post or a media asset. Like this is content, but code is content. It's sharing. If it's being consumed by other people, there's now community. You're seeing the steam of enabling. I mean, you're looking at successes, like you guys are having with NTT DoCoMo and others. Once people realize there's a better way and success is contagious, as Walter was saying, you are now enabling new ways to do things faster at scale and all that good stuff has been go check out the keynotes. You guys talk about it all day long with the execs. But I want to learn, right? So when you enable success, people want to be a part of it. And I could imagine there's a thirst and demand for training and the playbooks and all the business models, innovations that's going on. What are you seeing for people that want to learn? Is there training? Is there certifications? Because once you get the magic formula as Walter pointed out, and we all know once people see what success looks like, they're going to want to duplicate it. So as this wave comes, it's like having the new surfboard. I want to surf that wave. So what's the update on Ansible's training, the tools, how do I learn, it's a certification of all. Just take a minute to explain what's going on. >> Yeah, so it's been a crazy world as we've talked about over the last six, seven months here, and we've really had to adapt ourselves and our training and consulting offerings to be able to support our remote delivery models. So we very, very quickly back in the March timeframe, we're able to move our consultants to a remote work force and really implement the tools and technologies to be able to still provide the same value to customers remotely as we have in person historically. And so it's actually been really great. We've been able to make a really seamless transition and actually our C-SAT net promoter scores have actually gone up over the last six months or so. So I think we've done a great job being able to still offer the same consulting capabilities remotely as we have onsite. And so that's obviously with a real personal touch working hand in hand with our customers to deliver these solutions. But from a training perspective, we've actually had to do the same thing because customers aren't onsite, they can't do in person training. We've been able to move our training offerings to completely virtual. So we're continuing to train our customers on Ansible and our other technologies through a virtual modality. And we've also been able to take all of our certifications and now offer those remotely. So as, whereas customers historically, would have had to gone into a center and get those certifications in person, they can now do those certifications remotely. So all of our training offerings and consulting offerings are now available remotely as well as they were in person in the past and will be hopefully soon enough, but it's really not-- >> You would adopt to virtual. >> Excuse me. >> You had to adopt to the virtual model quickly for trainings. >> Exactly. >> What about the community role? What's the role of the community? You guys have a very strong community. Walter pointed out the sharing aspect. Well, I pointed out he talked about the contagious people are talking. You guys have a very robust community. What's the role of community in all of this? >> Yeah, so as Walter said, we have our communities a practice that we use internally we work with customers to build communities of practice, which are very much like a centers of excellence, where people can really come together and share ideas and share best practices and be able to then leverage them more broadly. So, whereas in the past knowledge was really kept in silos, we're really helping customers to build those communities and leverage those communities to share ideas and be able to leverage the best practices that are being adopted more broadly. >> That's awesome. Yeah, break down those silos of course. Open up the data, good things will happen, a thousand flowers bloom, as we always say. Walter, I want to get your thoughts on this collection, what that enables back to learning and integrations. So if collections are going to be more pervasive and more common place the ability to integrate, we were covering for VMware world, there's a VMware module collection, I should say. What are customers doing when you integrate in cross technology parties because now obviously customers are going to have a lot of choice and options. If I'm an integration partner, it's all about Cloud native and the kinds of things we're talking about, you're going to have a lot of integration touch points. What's the most effective way for customers integrating other technology partners into Ansible? >> And this is one of the major benefits that came out of the announcement last year with the Ansible automation platform. The Anible automation platform really enables our customers to not just be able to do automation, but also be able to connect the dots or be able to connect other tools, such as other ITM SM tools or be able to connect into other parts of their workflows. And what we're finding in breaking down really quickly is two things. Collections obviously, is a huge aspect. And not just necessarily the collections but the automation service catalog is really where the value is because that's where we're placing all of these certified collections and certified content that's certified by Red Hat now that we create alongside with these vendors and they're unavailable to customers who are consuming the automation platform. And then the other component is the fact that we're now moved into a place where we now have something called the automation hub. which is very similar to galaxy, which is the online version of it. But the automation hub now is a focus area that's dedicated to a customer, where they can store their content and store those collections, not just the ones that they pull down that are certified by Red hat, but the ones that they create themselves. And the availability of this tool, not only just as a SaaS product, but now being able to have a local copy of it, which is brand new out of the press, out of the truck, feature is huge. That's something that customers have been asking for a very long time and I'm very happy that we're finally able to supply it. >> Okay, so backup for a second, rewind, fell off the truck. What does that mean? It's downloadable. You're saying that the automation hub is available locally. Is that what-- >> Yes, Sir. >> So what does that mean for the customer? What's the impact for them? >> So what that means is that previously, customers would have to connect into the internet. And the automation hub was a SaaS product, meaning it was available via the internet. You can go there, you can sync up and pull down content. And some customers prefer to have it in house. They prefer to have it inside of their firewall, within their control, not accessible through the internet. And that's just their preferences obviously for sometimes it's for compliance or business risk reasons. And now, because of that, we were able to meet that ask and be able to make a local version of it. Whereas you can actually have automation hub locally your environment, you can still sync up data that's out on the SaaS version of automation hub, but be able to bring it down locally and have it available with inside of your firewall, as well as be able to add your content and collections that you create internally to it as well. So it creates a centralized place for you to store all of your automation goodness. >> Jason, I know you got a hard stop and I want to get to you on the IBM question. Have you guys started any joint service engages with IBM? >> Yeah, so we've been delivering a lot of engagements jointly through IBM. We have a lot of joint customers and they're really looking for us to bring the best of both Red Hat services, Red Hat products, and IBM all together to deliver joint solutions. We've actually also worked with IBM global technology services to integrate Ansible into their service offerings. So they're now really leveraging the power of Ansible to drive lower cost and more innovation with our customers and our joint customers. >> I think that's going to be a nice lift for you guys. We'll get into the IBM machinery. I mean, you guys got a great offering, you always had great reviews, great community. I mean, IBM's is just going to be moving this pretty quickly through the system, I can imagine. What's some of the the feedback so far? >> Yeah, it's been great. I mean, we have so many, a large joint customers and they're helping us to get to a lot of customers that we were never able to reach before with their scale around the world. So it's been great to be able to leverage the IBM scale with the great products and services that Red Hat offers to really be able to take that more broadly and continue to drive that across customers in an accelerated pace. >> Well, Jason, I know you've got to go. We're going to stay with Walter while you drop off, but I want to ask you one final question. For the folks watching or asynchronously coming in and out of Ansible Fest 2020 this year. What is the big takeaway that you'd like to share? What is the most important thing people should pay attention to? Well, a couple things it don't have to be one thing, do top three things. what should people be paying attention to this year? And what's the most important stories that you should highlight? >> Yeah, I think there's a lot going on, this technology is moving very quickly. So I think there's a lot of great stories. I definitely take advantage of the customer use cases and hearing how other customers are leveraging Ansible for automation. And again really looking to not use it just as a tool, but really in an enterprise strategy that can really change their business and really drive cost down and increase revenues by leveraging the innovation that Ansible and automation provides. >> Jason, thank you for taking the time. Great insight. Really appreciate the commentary and hopefully we'll see you next year in person Walter. (all talking simultaneously) Walter, let's get back to you. I want to get into this use case and some of the customer feedback, love the stories. And we look, we'd love to get the new data, we'd love to hear about the new products, but again, success is contagious, you mentioned that I want to hear the use cases. So a lot of people have their ear to the ground, they look up the virtual environments, they're learning through new ways, they're looking for signals of success. So I got to ask you what are the things that you're hearing over and over again, as you guys are spinning up engagements? What are some of the patterns that are emerging that are becoming a trend in terms of what customers are consistently doing to overcome some of their challenges around automation? >> Okay, absolutely. So what we're finding is that over time that customers are raising the bar on us. And what I mean by that is that their expectations out of being able to take on tools now has completely changed and specifically when we're talking around automation. Our customers are now leading with the questions of trying to find out, well, how do we reduce our operational costs with this automation tool? Are we able to increase revenue? Are we able to really truly drive productivity and efficiency within our organization by leveraging it? And then they dovetail into, "Well, are we able to mitigate business risk, "even associated with leveraging this automation tool?" So as I mentioned, customers are up leveling what their expectations are out of the automation tools. And what I feel very confident about is that with the launch of the Ansible automation platform we're really able to be able to deliver and show our customers how they're able to get a return on their investment, how by taking part and looking at re-working their workflows how we're able to bring productivity, drive that efficiency. And by leveraging it to be able to mitigate risks you do get the benefits that they're looking for. And so that's something that I'm very happy that we were able to rise to the occasion and so far so good. >> Last year I was very motivated and very inspired by the Ansible vision and content product progress. Just the overall vibe was good, community of the product it's always been solid, but one of the things that's happening I want to get your commentary and reaction to this is that, and we've been riffing on this on theCube and inside the community is certainly automation, no brainer, machine learning automation, I mean, you can't go wrong. Who doesn't want automation? That's like saying, "I want to watch more football "and have good food and good wifi. I mean, it's good things, right? Automation is a good thing. So get that. But the business model issues you brought up ROI from the top of the ivory tower and these companies, certainly with COVID, we need to make money and have modern apps. And if you try to make that sound simple, right? X as a service, SaaS everything is a service. That's easy to say, "Hey, Walter, make everything as a service." "Got it, boss." Well, what the hell do you do? I mean, how do you make that happen? You got Amazon, you got Multicloud, you got legacy apps. You're talking about going in and re-architecting the application development process. So you need automation for the business model of everything as a service. What's your reaction to that? Because it's very complicated. It's doable. People are getting there but the Nirvana is, everything is a service. This is a huge conversation. I mean, it's really big, but what's your reaction to that when I bring that up. >> Right. And you're right, it is a huge undertaking. And you would think that with the delivery of COVID into our worlds that many organizations would probably shy away from making changes. Actually, they're doing the opposite. Like you mentioned, they're running towards automation and trying to figure out how do they optimize and be able to scale, based on this new demand that they're having, specifically new virtual demand. I'm happy you mentioned that we actually added something to the automation adoption journey to be able to combat or be able to solve for that change. And being able to take on that large ask of everything as a service, so to speak. And increment zero at the very beginning of the automation adoption journey we added something called navigate. And what navigate is, is it's a framework where we would come in and not just evaluate what they want to automate and bring that into a new workflow, but we evaluate what they already have in place, what automation they have in place, as well as the manual tasks and we go through, and we try to figure out how do you take that very complex, large thing and stream it down into something that can be first off determined as a service and made available for your organization to consume, and as well as be able to drive the business risks or be able to drive your business objectives forward. And so that exercise that we're now stepping our customers through makes a huge difference and puts it all out in front of you so that you can make decisions and decide which way you want to go taking one step at a time. >> And you know it's interesting, great insight, great comment. I think this is really where the dots are going to connect over the next few years. Everything is as a service. You got to lay the foundation. But if you really want to get this done I got to ask you the question around Ansible's ability to integrate and implement with other products. So could you give an examples of how Ansible has integrated and implemented with other Red Hat products or other types of technology vendors products? >> Right. So one example that always pops to the top of my head and I have to give a lot of credit to one of my managing architects who was leading this effort. Was the simple fact that you when you think about a mainframe, right? So now IBM is our new family member. When you think about mainframes, you think about IBM and it just so happens that there's a huge ask and demand and push around being able to automate ZOS mainframe. And IBM had already embarked on the path of determining, well, can this be done with Ansible? And as I mentioned before, my managing architect partnered up with the folks on IBM's side, so the we're bringing in Red Hat consulting, and now we have IBM and we're working together to move that idea forward of saying, "Hey, you can automate things with the mainframe." So think about it. We're in 2020 now in the midst of a new normal. And now we're thinking about and talking about automating mainframes. So that just shows how things have evolved in such a great way. And I think that that story is a very interesting one. >> It's so funny the evolution. I'm old enough to remember. I came out of college in the 80s and I would look at the old mainframe guys who were like "You guys are going to be dinosaurs." They're still around. I mean, some of the banking apps, I mean some of them are not multi threaded and all the good stuff, but they are powering, they are managing a workload, but this is the beautiful thing about Cloud. And some of the Cloud activities is that you can essentially integrate, you don't have to replace the old to bring in the new. This has been a common pattern. This is where containers, microservices, and Cloud has been a dream state because you can essentially re layer and glue it together. This is a big deal. What's your reaction to that? >> No, it's a huge deal. And the reality is, is that we need all of it. We need the legacy behaviors around infrastructure. So we need the mainframe still because they has a distinct purpose. And like you mentioned, a lot of our FSI customers that is the core of where a lot of their data and performance comes out of. And so it's not definitely not a pull out and replace. It's more of how they integrate and how can you streamline them working together to create your end to end workflow. And as you mentioned, making it available to your organizations to consume as a service. So definitely a fan of being able to integrate and add to and everything has a purpose. Is what we're coming to learn. >> Agility, the modern application, horizontal scalability, Cloud is the new data center. Walter great insights, always great to chat with you. You always got some good commentary. I want to ask you one final question. I asked Jason before he dropped off. Jason Smith, who was our guest here and hit a hard stop. What is the most important story that people should pay attention to this year at Ansible Fest? Remember it's virtual, so there's going to be a lot of content around there, people are busy, it's asynchronous consumption. What should they pay attention to from a content standpoint, maybe some community sizes or a discord group? I mean, what should people look at in this year? What should they walk away with as a key message? Take a minute to share your thoughts. >> Absolutely. Absolutely key messages is that, kind of similar to the message that we have when it comes down to the other circumstances going on in the world right now, is that we're all in this together. As an Ansible community, we need to work together, come together to be able to share what we're doing and break down those silos. So that's the overall theme. I believe we're doing that with the new. So definitely pay attention to the new features that are coming out with the Ansible automation platform. I alluded to the on-prem automation hub, that's huge. Definitely pay attention to the new content that is being released in the service catalog. There's tons of new content that focus on the ITSM and a tool. So being able to integrate and leverage those tools then the easier math model, there's a bunch of network automation advances that have been made, so definitely pay attention to that. And the last teaser, and I won't go into too much of it, 'cause I don't want to steal the thunder. But there is some distinct integrations that are going to go on with OpenShift around containers and the SQL automation platform that you definitely are going to want to pay attention to. If anyone is running OCP in their environment they definitely going to want to pay attention to this. Cause it's going to be huge. >> Private cloud is back, OpenStack is back, OCP. You got OpenShift has done really well. I mean, again, Cloud has been just a great enabler and bringing all this together for developers and certainly creating more glue, more abstractions, more automation, infrastructure is code is here. We're excited for it Walter, great insight. Great conversation. Thank you for sharing. >> No, it's my pleasure. And thank you for having me. >> I'm John Furrier with theCube, your host for theCube virtual's, part of Ansible Fest, virtual 2020 coverage. Thanks for watching. (gentle upbeat music)

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