>> Announcer: Live from Atlanta, Georgia,
it's theCUBE, covering AnsibleFest 2019,
brought to you by Red Hat.
>> Welcome back, everyone.
Live CUBE coverage here in Atlanta.
This is theCUBE's coverage of AnsibleFest.
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, Stu Miniman.
Our next guest is Chris Gardner,
Principle Analyst at Forrester.
Gardner, welcome to theCUBE.
>> Thank you. >> Good to see you.
>> Good to talk to you.
>> Hey, analyzing the players in this space
is really challenging.
You got a new Wave that came out a few months ago,
laying it all out.
Certainly, the world's changed.
You go back eight years, cloud was just hitting the scene,
on-premises looked good, data center was rockin'.
You're doing network management.
You're doing some configuration management.
Now you got observability.
You got automation. >> Yeah, yeah, absolutely.
>> The world's changing, big time.
What's your take, what's the assessment?
>> Yeah, I mean, it's interesting because the prior versions
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 us a true platform.
>> Well, right, 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.
>> Correct. >> 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 bares.
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 it different ways,
and all the vendors in this space are certainly doing that.
>> Definitely, platform thinking is different.
The easy way to look at it
in the old big data space, we used to cover that,
was a tool versus a platform.
Tools, a hammer,
and look, a nail, did great things, one thing great
or a few things good.
Platform is more of a systems-thinking.
>> Chris: Yes, yeah.
>> 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,
and I'm sure you agree. >> Yeah, absolutely.
I mean, when you looked at who was leaders in my Wave,
it wasn't on the basics of automating,
orchestration, and configuration management.
They all have 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,
where they should go?
And the folks that were able to do that, rose to the top.
The folks that weren't, were average and below.
>> Yeah, Chris, bring us inside
to some of the competitive dynamics here.
We understand that 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 looks a bit ironic because this is one
of those Waves where it's very rare that everyone
was at least preaching "Kumbaya". (laughs)
They're 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 hyper cloud world, where you're going to have
resources that live in multiple 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 coopetition going on,
where people are saying,
"If I can integrate these tools better,
"if I could 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, an infrastructure
"and operations group," those are going to be 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."
And I get it, okay, it's a nice gimmick.
But if you think about it,
this abstraction layer, it's,
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, a key position,
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 core 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
were they stood up organically.
Each group kind of figured out to put 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, sole 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.
>> I mean, this is really the eye of the beholder,
beauty's in the eye of the beholder, right?
>> Yeah, in my view, I've been an analyst
for a couple of years.
Before that, I was doing this 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,
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's better.
Let's just talk about how we can
kind of combine this. >> That's the worst case
scenario because-- >> Exactly.
>> If you have to dictate workloads
based on what tool you have,
that's supposed to be the other way around, right?
>> Yeah, setting up a nuclear bomb in the data center
or in the cloud has never worked. (laughs)
>> Note to self, don't do that.
>> Yes. >> Chris,
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.
>> Oh yeah. >> And collaboration.
So, what are you finding in your research?
How is that kind of of the CIS admin role
and the cloud and applications changing?
>> Its 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.
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 setter of excellence."
Two reasons, one is that term is tainted.
But secondly, we're not one team.
There's multiple automation teams.
So were 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 going to standardize across the board
and when other groups need to come onboard,
I have the principles already laid out,
I have the processes 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 it's own that its got to worry about.
I'm in between the two.
And when we talked to, especially the Fortune 100,
they're setting these groups up.
Now, when I asked them, "What do you call them?"
They don't have a name yet,
so I think strike team sounds 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 team's better than committee.
Committee sounds like waterfall,
slow process, gridlock. >> Exactly, exactly.
>> 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 stander's 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 bot masters,
which is specifically for that role.
But most of the time,
you want them to be part of that process,
and then, hand it back off.
>> Yeah, we seen some interesting patterns.
I want to get your thoughts on this.
This is a little bit of a non sequitur.
I want to bring it in, but in the security stage,
you're seeing CISOs, chief information security officers,
building their own stacks internally.
>> Absolutely. >> They're picking one cloud,
Amazon or Azure, and they're building all in.
Maybe some Hedge with some people working on some
back up cloud, but they don't want to fork their talent.
>> Right. >> They want 'em
all on one cloud 'cause they need to be badass, responsive
strike teams for security pressure.
>> Chris: 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 beat,
is much more around core competency
and building internally, stacks,
and building some standards?
>> I think it is.
And what's interesting, too, is that
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 this 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."
>> John: So they're okay with them talking,
you mean, 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 that these roles are not that dissimilar,
as some people might think they are.
Sec dev ops or whatever we're going to call it,
we keep tacking letters onto this thing,
is a actual discipline
and it is a reality at most organizations
I talk to, that people should be targeting.
>> So a system has all these things,
has data across the system,
depending on what subsystem you're talking about, I mean.
It's this holistic system; security and data.
>> Yeah, and we're in a world now,
especially around things like Edge computing,
where data gravity matters.
So all these pieces, if you go back to the old school
kind of computer science folks from the '50s, '60s,
and '70s, they're like, "This is not new.
"We've been thinking the systems thinking for awhile."
But I think were finally at a place
where we're actually now breaking down
the silos that we've been championing to do so
for years. >> So I got to ask you
the analyst question since you're watching the landscape.
I know Stu wants to jump in,
but I want to get this out,
so observability became a category
out of network management.
I mean, network management was like this boring,
kind of plodding along white space.
I mean, super important.
People needed to do network management.
Then, in comes the cloud.
It becomes a data problem, whether it was observability.
You had microservices.
You got security.
SignalFX, all these companies going public,
a lot of MNA activities, basically large segment,
a lot of frothiness.
Automation feels like it's growing to be big.
>> Chris: Yes.
>> Is there start up opportunities here
if platforms are kind of being a combination of things?
Is there room for startups
and if so, what would you say those start ups
would look like?
>> I think there are.
I think what were seeing is,
and it speaks to, the word you just said.
>> John: Observability.
>> Yeah. (all laughing)
I know what it is, but I can't say it.
Were seeing the APM vendors move down the stack,
we're seeing the infrastructure
monitoring vendors move up the stack,
and in the middle, were seeing them
both try to automate the same things.
You cannot pull off some of the infrastructures'
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 were 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 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 this space.
They will be eventually.
>> So there's change happening,
big time. >> Absolutely, absolutely.
>> And startups getting funded.
You think there's opportunity to take some
territory down? >> I think there is.
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 it 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 Ansible automation platform
announcement today fits with what
you've been saying for the last couple of years,
so I guess the question is, what's next?
Where does Ansible need to mature and expand
and what are users asking for
that Ansible's not doing today?
>> Yeah, so a couple things.
They did okay, but not fantastic
at infrastructure modeling, Ansible.
They did okay, but not amazing at
what we call comprehension, which is making a call
as to using AI
and machine learning to make a call
on what the infrastructure layer should look like.
To be frank, no one did really well in 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 really good one.
You see all the folks that are here.
It's a hair away from being the best.
They're not quite there yet.
And 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--
>> John: Who's the best?
>> right now, surprisingly, is VMware.
But VMware's built that relationship up for a long time.
They worked right alongside Microsoft and Google
and all these folks to build the code together.
>> John: Who's the dark horse in the industry?
(John laughing)
>> 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 could argue, is it even an automation platform?
But quite frankly, I think HashiCorp itself
is trying to figure out exactly what it is. (laughing)
>> John: They are. (laughs)
>> 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 their strategy going forward
and look at what they're putting their investments into,
they could become a really serious,
damaging player in this space.
>> Chris Gardner, thanks for coming on theCUBE.
>> Yeah, thank you. >> 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.
>> Chris: Thank you.
(upbeat music)