 Live from Atlanta, Georgia, it's theCUBE. Covering Ansible Fest 2019, brought to you by Red Hat. Welcome back everyone, live CUBE coverage here in Atlanta. This is theCUBE's coverage of Ansible Fest. This is Red Hat, Ansible's two days of live coverage. They had a contributor day yesterday before the conference, all being covered by theCUBE. I'm John Furrier, my co-host Stu Miniman. Our next guest is Chris Gardner, principal analyst at Forester. Gardner, welcome to theCUBE. Good to see you. Good to talk to you. Hey, analyzing the players in this space is really challenging. You've got a new wave that came out a few months ago, laying it all out. Certainly the world changed. You go back eight years, Cloud was just hitting the scene, on premises looked good, data center was rocking, you're doing network management, you're doing some configuration management, now you got observability, you got automation, the world's changing. Big time, what's your take? What's the assessment? Yeah, I mean it's interesting because the prior versions of that wave focused entirely on configuration management. And the feedback I got was, the world's a lot bigger than that, right? And we have to talk about platforms. And you heard it this morning during the keynote about Red Hat moving towards an Ansible platform, an automation platform. And my definition of a platform is, things like configuration management, hyper cloud management, all the various types of automation and orchestration need to be there, but you also need compliance, you need governance, you need the ability to hopefully make a call as to what is actually occurring and have some intelligence behind the automation. And obviously you need the integrations. It's not a situation to simply have as many people as possible, although that's nice, as many vendors you work with, but to have real relationships. If you have Microsoft working on automation code with you, if you have Amazon working on automation code with you, that makes a true platform. Well, right, as John said earlier today, a platform needs to be an enabler and we've even said, if you can't build on top of this, which like the collections that Ansible announced here, seems like it might fit under that definition. Yeah, and there's an old joke that everything becomes a platform eventually, right? But I think it bears, there's some merit in this one. The other thing is that I'm seeing a lot of folks want a holistic automation solution. And the only way you're going to do that is to have a platform that you can build things on top of it and connect the pieces and provide the proper governance. So I'm mostly in agreement with the definition that's been described here. And I think you could tackle different ways and all the vendors in the space are certainly doing that. Definitely platform thinking is different. The easy way to look at it and the old big data space too, we used to cover that was a tool versus a platform, tools, the hammer and the nail. Did great things, one thing great or a few things good. Platform is more of a systems thinking. Yes. And you got glue layers, you got data. So it's really more of that systems thinking that separates the winners from the losers, at least in our opinion. Yeah, absolutely. I mean, when you looked at who was the leaders in my wave, it wasn't on the basics of automating or orchestration and configuration management, they all had that. The ones that were winners were, can I do compliance in a different way? Can I actually have people come into the system that aren't IT people and make a call on some of these things? Can I apply AI and machine learning to some of this? Can I make some recommendations and hopefully direct people in the right, you know, the way they should go. And the folks that were able to do that rose to the top, the folks that weren't were averaging below. Chris, bring us inside to some of the competitive dynamics here. We understand there's a lot of open source here and therefore everybody holds hands and sings kumbaya, but there's product tools, there's the public clouds and what they do, and then Ansible fits in a lot of different places. Yeah, yeah, it's a bit ironic because this is one of those waves where it's very rare that everybody was at least preaching kumbaya. They were all saying that they were friendly with one another. And quite frankly, I tend to believe it. We're in a situation right now where you can't get by, especially in a hybrid cloud world, we're going to have resources that live in multiple, you know, AWS and Azure, but also on premises and at the edge, you need to have these integrations. You need to be able to talk to one another. So that said, there's certainly a lot of co-opetition going on where people are saying if I can integrate these tools better, if I can provide a better governance layer, if I can, again, hand things off to the enterprise in a way that has not been handed off before, that I don't even have to go through an INO group and infrastructure and operations group. Those are the ones that truly succeed in this space. Software-defined data centers, software-defined cloud, everything's software-defined. These abstraction layers, data and software. We had a guest on theCUBE a week ago saying, data's the new software. Well, I get, okay, it's nice, nice gimmick. But if you think about it, this abstraction layer, it's like a control plan. Everyone wants to go for these control planes, which is a feature of a platform. As this automation platform becomes, ultimately, the AI platform, how do you see it evolving and expanding? Because you see organic growth, you see certainly key positions, six million stars on GitHub. I mean, it's running the plumbing. I mean, come on. It's not like it's just some corner case. It's for infrastructure. Yeah, I mean, in an idealistic way, I'd like to see us resolve on singular holistic platforms for enterprises. The reality is that's not the way you can do it today. What I do try to help clients do is at least rationalize their portfolio. If they have 12 different automation products they're running, chances are that's not the best idea. I've actually had situations where someone will say to me, I'm running Ansible in one portion of my organization and Chef in another. And I say, well, they do similar things. And the reason for it was because they were stood up organically. Each group kind of figured out things along the way. And I have to at least guide them and say, where are the similarities? Where can you potentially remove some stuff from the equation? It's like the cloud discussion. We always debate upon multi-cloud, soul cloud. Ultimately, the workload needs something underneath. And I think workload definition dictates kind of what might be underneath. So it might be okay to have a couple automation platforms or it could be great to have one. Yeah. I mean, this is really the eye that behold or beauty's in the eye that behold. Yeah. In my view, I've been an analyst for a couple of years before that I was doing the stuff for a living. I have the War Scars. And in my view, it's not even a matter of how many tools you use. It's putting the workload where it belongs that matters. And if you could do that with fewer tools, obviously that from an operational level that makes life a lot easier. But I'm not going to say to somebody, completely dismantle your entire automation and orchestration workflow just because I think this one tool is better. Let's talk about how we can... That's the worst-case scenario because if you have to dictate workloads based upon what tool you have, that's supposed to be the other way around, right? Yes. Setting up a nuclear bomb in the data center or in the cloud has never worked. Note yourself, don't do that. Yes. One of the interesting conversations we've already been having here at the show is that the tool is actually helping to drive some of the cultural change and collaboration. So what are you finding in your research? How is that kind of the sysadmin role to the cloud in applications changing? You know, it's interesting. We continue to beat the drum that these folks are becoming developers, but we've been beating that drum for a decade now. And quite frankly, we ought to continue to beat it. But what I think is even more interesting is we have groups starting to pop up in our research that are separate from IT that focus on automation in a way that no one has done before. Some, we went into it saying, oh, that's a center of excellence, right? And the teams that we talked to said, no, do not call us a center of excellence. Two reasons. One is that term is tainted. But secondly, we're not one team. There's multiple automation teams. So we're actually starting to call these groups strike teams that come in and standardize and say, okay, I have a lead architect, a lead robot architect. Say it's around infrastructure automation. I'm gonna standardize across the board. And when other groups need to come on board, I have the principles already laid out. I have the process already laid out. I come in, I accelerate that. I set it up and then I back off. I don't own the process and I'm not part of IT either. IT's got operations of its own that's got to worry about. I'm in between the two. And when we talk to, especially the Fortune 100, they are setting these groups up. Now, when I ask them, what do you call them? They don't have a name yet. So I think strike teams sound sexy, but ultimately this is not like a section of IT that's been severed off and becomes this role. It's a completely new thing. Strike teams better than committee. It sounds like, you know, waterfall, slow process. Exactly. Gridlock. And it better fits what the role is. The role is to come in, nail the process, get it automated and then get out. It's not to stand there and be a standards body forever. There's certainly some groups that in some types of automation like RPA where you want them to stick around because you may want them to manage the bots. There's a whole role called Botmasters which is specifically for that role. But most of the time you want them to be part of that process and then, you know, hand it back off. Yeah, we see some interesting patterns. I want to get your thoughts on this. It's a little bit of a non-sequit about how to bring it in. But in the security space you're seeing CISOs, Chief Information Security Officers, building their own stacks internally. They're picking one cloud, Amazon or Azure and they're building all in. Maybe some hedge with some people working on some backup cloud but they don't want to fork their talent. They want them all on one cloud and they, because they need to be badass, responsive, strike teams for security pressure. Yeah, yeah, absolutely. Not as critical with the security side with automation, but certainly relevance. Is that same thing going on here with this development drum that's being continued to be as much more around core competency and building internally stacks and building some standards? I think it is. And, you know, what's interesting, too, is that I work with, I'm on the infrastructure and operations team at Forrester. I talk with INO people all day long but I work alongside the security team and I said to them a couple years ago, you guys are going to have to get your hands dirty with the stuff that I cover. You guys have to know infrastructure automation APIs. You need to know how to code these things. And I said, are you comfortable telling your SecOps folks, your clients that? They go, no, by all means. They have to be part of this. No, they're okay with them talking to me. Or connecting. Talking to them and saying that you need to be part of the infrastructure design process and need to be part of this decision-making process, right, which is different than their SecOps role used to be. So my point is, is that these roles are not that dissimilar, as some people might think they are. SecOps or whatever we're going to call it. We keep tacking letters onto this thing. Is a actual discipline and it is a reality in most organizations I've talked to that people should be target. So a system has all these things. It has data across the system. Being a hot, what subsystem you're talking about. I mean, it's a holistic system. Security and data. And we're in a world now, especially around things like edge computing where data gravity matters. So all these pieces, you know, it's, if you go back to the old school kind of computer science folks from the, you know, 50s, 60s and 70s, they're like, this is not new. We've been thinking systems thinking for a while, but I think we're finally at a place where we're actually now breaking down the silos that we've been championing to do so for. So I got to ask you the analyst questions since you're watching the landscape. So I just want to jump in, but I want to get this out. So observability became a category at a network management. I mean, network management was like this boring, kind of plotting along, white space. I mean, super important. People need to do network management. Then it comes to cloud. It becomes a data problem whether it's observability, you've got microservices, you've got security, signal FX, all these companies going public, a lot of M&A activities, basically large segment, a lot of throttiness. Automation feels like it's growing to be big. Is there startup opportunities here if platforms are becoming a combination of things? Is there room for startups? And if so, what would you say those stars would look like? I think there are. I think what we're seeing is, and it speaks to the word you just said. It's a rebellion. I know what it is, but I can't say it. We're seeing the APM vendors move down the stack. We're seeing the infrastructure monitoring vendors move up the stack. And in the middle, we're seeing them both try to automate the same things. You cannot pull off some of the infrastructure as code automation that we need to pull off without observability. But you can't get that observability unless you're able to pull it from the top of the stack. What we're going to see is consolidation. And we're already starting to see it. Where you're going to have different groups come together and say, why do you have two tools to do this? Why not do one? The reason why you do multiple tools today is because no one is truly strong at the entire stack. A lot of the folks that are going down the stack say that they're not quite infrastructure automation players just yet, but watch the space. They will be eventually. So there's change happening. Big time. Absolutely. And startups getting funded. Do you think there's opportunity to take some territory down? If there's any opportunity, and I'm pushing for this, it's in the AI ops space when it comes to these things is actually going beyond where we stand today. So I want to be clear that AI ops is a great concept. The reality of is that we're still a ways away from it being practical. I'd like to see not just recommendations from these tools that the startups are providing, but actually trust in them to make the changes necessary. So Chris, it sounds like the Antible Automation platform announcement today fits with what you've been saying for the last couple of years. So the question is what's next? Where does Antible need to mature and expand? And what are users asking for that Antible's not doing today? Yeah, you know, so a couple of things. They did okay, but not fantastic at infrastructure modeling, Antible. They did okay, but not amazing at what we call comprehension, which is making a call as to, you know, using AI machine learning to make a call on what the infrastructure layers should look like. To be frank, no one did really well on that one. So not too bad on that. And the other thing is they need to improve slightly is their integration story. They actually have a really good one. You see all the folks that are here. It's just a hair away from being the best. They're not quite there yet. So, and when again, when I mean integrations, I don't mean having a laundry list of vendors you work with. I mean actually working with them to build code. And you saw that this morning where- Who's the best? Right now, surprisingly, is VMware. But VMware has built that relationship up for a long time. They work right alongside Microsoft and Google and all these folks to build the code together. Who's the dark horse in the industry? I think the darkest horse of all is probably, and it remains to be seen if they can actually do something is Hashicorp. Terraform is an interesting player in this entire space. I actually included them in our wave on infrastructure automation platforms. And you can argue, is it even an automation platform? Quite frankly, I think Hashicorp itself is trying to figure out exactly what it is. But the bottom line is it's got tremendous mind share and it works well. So I think that if you watch, if you see the strategy going forward and look at what they're putting their investments into, they could become a really serious damaging player in the space. Chris Gardner, thanks for coming on theCUBE. Sharing your insights and your research at Forrester. Forrester Wave, check it out. Just came out a couple months ago. Infrastructure automation platforms Q3 2019. Chris Gardner, the author here in theCUBE, breaking it down. I'm John Furrier, with Stu Miniman. We'll be back with more after this short break. Thank you.