OpenShift gets all the attention, but the Ansible configuration automation tool for devops shows how to moving to the future seem boring
Ansible is the Rodney Dangerfield of Red Hat’s software portfolio: It, too, “don’t get no respect.” Despite the Ansible automated configuration management tool helping to sell Red Hat’s hybrid cloud story, delivering six deals worth more than $1 million and one deal worth over $5 million, not a single analyst in the latest financial call bothered to check on Ansible’s progress. Why? They’re fixated on OpenShift, and perhaps rightly so. OpenShift is Red Hat’s most obvious successor to the Red Hat Enterprise Linux (RHEL) throne.
But for anyone who wants to understand Red Hat’s game plan, grokking Ansible is imperative. In part, as Red Hat CEO Jim Whitehurst told me, Ansible attracts “a lot of net new logos that aren’t [Red Hat’s] typical customers.” But in larger part, Ansible is all part of Red Hat’s master plan to make sexy open source boring, and to make boring legacy code hip.
Ansible is easy automation for more than just devops
As significant as OpenShift is, making a fetish of it at Ansible’s expense is a mistake. Fortunately, enterprises don’t seem to be making that mistake, if Stack Overflow interest is any indication. By that metric, Ansible has managed to significantly surpass interest in early entrants to the devops automation market, Puppet and Chef.
Enterprises buy all sorts of infrastructure from Red Hat and then have to manage it all. As enterprises seek out IT automation/configuration management solutions, Ansible rises to the top because of Red Hat’s backing and because it offers an agentless approach that distinguishes it from Puppet and Chef. With all functions handled over SSH (or using
sudo as root, if SSH configurations aren’t possible), it’s super quick to deploy.
Red Hat bought Ansible, Whitehurst recalled, “to manage containers in an agentless way,” but it got a surprise bonus: a tool that customers can also use for the internet of things, networking, and security. These applications weren’t on Red Hat’s radar, he noted, but they’re gifts that keep on giving.
Ansible’s goal: Be really good at being boring
All of that makes Ansible sound sort of sexy. But it’s not. In fact, Red Hat’s whole game plan is predicated on it being dull, stodgy, and dependable. As Redmonk analyst James Governor put it, “Enterprises trust Red Hat precisely because it makes open source boring.”
Indeed, Red Hat is succeeding in part because it’s a trusted partner not only in making shiny new things like Kubernetes predictable and staid, but also because it can move legacy workloads from private datacenters to public clouds.
For Red Hat, legacy isn’t simply the past, but the future. Whitehurst said, “We have a really strong opportunity with the enterprise Java developer.” At this point I fell asleep because, well, duh. But then he rattled me awake: “[Java] may not be the future, but we do a great job of moving old world to new world and can help move these people to the new opportunities.”
Whitehurst wasn’t being dismissive of Java. Far from it. He simply compared Java to the shiny new languages like Google Go and Rust that developers get excited about. As important as these new languages are, Java still carries immense enterprise weight. As exciting as it is to rush to the shiny new thing, most enterprises are mired in lots (and lots) of legacy workloads, much of them written in Java. To get to the cloud, they’ll need a bit of help.
Ansible is part of that help by automating the cruft in an enterprise’s IT functions, moving from on-premises to hybrid (and eventually public cloud).
In short, Ansible is part of Red Hat’s strategy to make the cool stuff boring and the boring stuff cool. It doesn’t get the press that OpenShift has, but Ansible is an integral part of Red Hat’s hybrid cloud strategy—one that seems to be working.