
Red Hat is buying Ansible - dlapiduz
http://venturebeat.com/2015/10/15/source-red-hat-is-buying-ansible-for-more-than-100m/
======
mattzito
I think the price point here is about a couple of things:

\- Chef and Puppet are too expensive for most companies to acquire, and have
too much operational cost for too little revenue

\- Ansible got a strong following in the SMB space, Red Hat probably thinks
they can move that upmarket some

\- Ansible's agentless configuration management has potentially strong
applicability in a container world (why do I need a chunky agent to configure
resources on my docker image? What if, for some reason, I need to affect
change on running docker images? - I realize this is a bit of an anti-pattern
for docker, but it was something I heard a lot from big enterprises)

$100m still sounds very high, kudos to the ansible folks who have come a long
way in the last few years.

EDIT: one more piece I didn't think of here - the openstack side of things is
an area where Red Hat has made big long-term bets for the future of the
company, and it probably helps to justify the price in terms of backstopping
their openstack support.

~~~
superuser2
I really don't understand why an organization would want to use Docker
(besides buzzword compliance) if they were planning on mutating running
containers. What's the advantage?

~~~
justingood
I think one thing to keep in mind about Ansible is that it's an orchestration
tool that also does configuration management. We've integrated Ansible into
our workflows in such a way that it kicks off everything we need to do, even
if that involves just coordinating some info between APIs. We don't mutate
containers at all - merely get Ansible to make things happen around their
deployment and communication.

~~~
Sphax
How do you use ansible to deploy your containers, if I may ask ? We're looking
into the docker module right now, but I don't know if it's good or what.
Currently we're launching container via systemd and manage the unit files with
ansible.

~~~
justingood
We're running all the containers on Mesos hosts, so really all Ansible needs
to do for us is talk to Marathon. We realized early on down this path that to
accommodate scale we'd need to have some sort of scheduler. Mesos happened to
be the most robust.

We originally tried the docker module in Ansible but found it had a few
problems. There's been a lot of work on it since, and I expect it will be in a
much better state when Ansible 2.0 is released.

------
leg100
This clearly is much more about Tower, consultancy, etc, than their main
product, but their yaml encoded language is an abomination; masquerading as
'declarative' and easy to read, yet piling on loops and conditional statements
and an unintuitive inheritance tree of global and local variables.

~~~
anton_gogolev
Spot on. I'm constantly amazed at how many projects use _serialization
formats_ as a "programming language". LiquiBase, NAnt, MSBuild, Ansible.

~~~
raverbashing
Maven or pretty much anything XML based

~~~
reitanqild
In defense of maven it does provide neither branching nor looping statements
so refering to it as a "programming language" is hard to justify.

~~~
collyw
Neither does HTML and the L stands for language.

~~~
executesorder66
Notice how the M stands for "Markup" and not "Programming"

------
Schiphol
I found this sentence funny "Representatives of Red Hat and Ansible did not
immediately respond to requests for comment". I take it to mean: "we wanted to
run the story as quickly as possible; still it would have been nice to get
superquick comments by RH or Ansible; tough luck, though."

~~~
dspillett
To me "did not _immediately_ respond to requests for comment" smacks of
neediness and self importance on the reporter's part (answer me now, you
fools, don't you know who I am and what power I behold?!) and the people that
would respond to such comments being in the middle of dealing with something
more important at the time (perhaps answering a queue of queries that came in
first, or queries from people who are more important to their world view). If
I were RedHat or Ansible and read that sentence the reporter and/or outlet
would be added to a "never respond to these people for at least 24 hours"
list...

~~~
stonogo
I have always read it as "did not respond to requests for comment, but we
didn't give them much time."

~~~
gnurag
More like "Both companies didn't immediately respond to requests for comment.
Its 8:30PM and no one's taking my calls or responding to my emails, but we're
an online publication and want _our_ content to go viral and get maximum
eyeballs, so we'll run this story anyway."

------
nzoschke
Ansible is best of breed. But didn't Red Hat hear? Immutable infrastructure is
the future!

[http://michaeldehaan.net/post/118717252307/immutable-
infrast...](http://michaeldehaan.net/post/118717252307/immutable-
infrastructure-is-the-future)

~~~
mmahemoff
Yes it is, but the future is not evenly distributed, to paraphrase William
Gibson. For many enterprises, even Ansible's current model is already way out
there in the distant future.

Also, I think Ansible's idempotent model actually works nicely with immutable
infrastructure. Why? For _development_ of your stack. While messing around
with it, you probably don't want to rebuild the whole thing from scratch. Of
course you can play funny games with caching of remote packages and so on, but
that's getting into Ansible territory anyway.

So I think a good model for immutable infrastructure is to use a tool like
Ansible to develop the stack, then in production you would use the same tool
to spin up immutable instances.

~~~
Florin_Andrei
Exactly. You still need something that holds a template of the stack
somewhere. Ansible can play that role very well.

------
ptio
Ansible creator, founder and CTO Michael DeHaan previously worked at Red Hat
where he helped build Cobbler.

~~~
srvg
Also, Michael DeHaan stepped down and left the company early 2015.

~~~
AhtiK
So this could explain why his very active github activities suddenly stopped
early 2015, I just presumed it was due to consciously allocating more time for
management and leadership.

His github contributions rate and depth for ansible while still the CEO in
y2014 has been a great inspiration for me.

------
KarlPlatt
My experience with Ansible has not been so pleasant. Especially performance is
a jobstopper. In my environment it takes 20 min for 12 Servers to be setup
with some Redis, Elasticsearch stuff. Quite some become_user directives, but
20 min for this kind of stuff is just not acceptable. After all, application
settings needs to be tuned and iterated over, too.

My idea was to develop the infrastructure with Ansible, e.g. no ssh to change
some httpd settings at all. Everything via Ansible. It worked very well as
long as the playbooks and number of servers was very small.

~~~
bovermyer
This has been my experience as well. Even using a small subset of a playbook
via tags can take a long time, especially if you're doing a run in serial. One
of our deployments that only affects six servers takes fifteen minutes.

This can be mitigated somewhat by putting Ansible on the target machine,
downloading all the necessary files to that machine, and then running Ansible
locally... but that seems awfully fragile to me.

I am much more interested in Salt's ZeroMQ path these days. It seems to scale
better, at least on paper and in my few small tests.

~~~
jimi_c
I'd be interested in hearing how this stacks up against simply running the
tasks via shell scripts, because the time to install packages/do other tasks
is orders of magnitude higher than the connection overhead. Things will always
be slow when doing `serial: 1`, so I'd definitely recommend a canary setup
where you run a play with a small serial batch followed by a play with no
serial limitation - that'll speed things up considerably.

Finally, when using ControlPersist with pipelining mode in Ansible, it's as
fast if not faster than zeromq or our own accelerated mode (which we will be
deprecating at some future point when older SSH installs are not as common).

~~~
bovermyer
I'll admit to not knowing what ControlPersist is. I have some reading to do,
it would seem.

------
xorcist
Interesting! Ansible is great technology. Not as mature as Puppet or Chef, but
it's getting there. However Red Hat is currently heavily pushing (what I
understand to be) their own fork of Puppet inside Satellite 6. So quite a few
RHEL customers in the process of rolling out the latest Satellite is probably
going to want to hedge their investment in it. Perhaps there is some Red
Hatter here who could comment?

~~~
atsaloli
Speaking of mature, CFEngine has been around since 1993 and is now in its
third generation. I just wish they would do a little marketing.

~~~
INTPenis
I think what makes a product like ansible catch on is its use of a simple
scripting language like python. This makes project participation more
accessible.

Ordinary sysadmins can write their own ansible modules with ease. It's
possible that cfengine has that now but ask sendmail about repairing an old
reputation.

~~~
dsmithatx
Actually I think it's more the YAML config files than the fact it's written in
Python. I learned 80% of Ansible in probably 10 days of writing playbooks and
going through the infrastructure at my new job.

Also I used to work with Puppet in an 8000 server environment and Ansible and
Salt both are so much more fun and easy to use than Puppet. I hear the same
thing over Chef too.

Last Ansible is the only one that doesn't require any agents installed and
does everything via SSH. At first I didn't think I'd like that coming from
Puppet but, I can do everything I need to without another daemon to worry
about.

~~~
Florin_Andrei
My thoughts exactly on all points except the last one.

It's definitely good to not be _forced_ to use agents everywhere + a dedicated
"mothership" instance, but sometimes I do wish I had Ansible agents on my
instances, just so I could "git push" the whole thing and forget about it.

Looking forward to Red Hat following on their good old habits and open-
sourcing Tower.

~~~
dsmithatx
Well to be fair I use Codeship with Tower to do auto-deployments so, if I "git
push" to dev I'm done.

------
thejerz
Ansible is a fantastic tool. I put it up there with Rails, Backbone, and
jQuery. The shadow of Puppet and Chef is large, but many are starting to see
the light.

I hope that Redhat will accelerate the growth of this very well engineered
platform.

Congrats to the Ansible team!

------
carlsborg
Congrats mpdehaan2. Good to see good engineering getting rewarded. Testament
to a great project you conceived and started.

------
geerlingguy
Supposedly a > $100mm deal. Both companies are already headquartered in N.C.,
and Ansible has a ton of momentum in the RHEL and OpenStack arenas, so it
would make sense to pull the project into the fold.

One thing I wonder is how much the project's priorities would shift away from
(if at all) anything non-RHEL-centric.

~~~
rodgerd
As a Red Hat customer I'll be interesting to see how it affects the complete
fucking shambles that has been the Satellite 6 rollout, which was supposed to
be full Foreman/Puppet integration for provisioning and config management.

Apart from the fact that it's been a shambles, Red Hat have been solidly
pushing customers down the puppet route. I expect there will be some grumpy
meetings in the next few weeks.

~~~
tamasnet
Reminds me of their switch from Xen to KVM from RHEL 5 to 6, so I wouldn't put
it past them to change course.

------
tomaac
It is official now [https://www.redhat.com/en/about/press-releases/red-hat-
acqui...](https://www.redhat.com/en/about/press-releases/red-hat-acquire-it-
automation-and-devops-leader-ansible)

------
pdeva1
Wonder what caused such a high valuation. They definitely didnt seem to have
enough revenues to justify it.

~~~
devnonymous
I would imagine it is not so much about Ansible's general valuation in the
industry but about its value for Red Hat (a.k.a -- Red Hat is not buying
Ansible for its revenues but for its technology).

~~~
marcoamorales
What are you buying when the technology is open source?

~~~
devnonymous
The direction in which the technology evolves. That's also the reason why Red
Hat hires a lot of upstream developers[1]. It is easier to tailor your
services and offer better support (ie: the revenue stream for Red Hat) for OSS
when the developers who write it are on your payroll.

    
    
      https://fedoraproject.org/wiki/Red_Hat_contributions
      http://www.redhat.com/en/about/blog/red-hat-leads-open-source-contributions-to-kernel

------
srvg
Wondering if RH will let Tower become Open Source.

~~~
chr15p
Red Hat has a history of buying closed source software and releasing it as
Open Source (KVM, Gluster, Cloudforms etc) so I would expect Tower to be open
sourced. Assuming Ansible have the rights to all the code of course and dont
license it from someone else of course.

~~~
gnurag
Gluster has always been an OpenSource project IIRC.

~~~
notacoward
Correct. There was a time, pre-acquisition, when some separate management-
console bits were not open source, but nobody cared about those bits anyway
and now they're long gone. The "GlusterFS" file system part, which is the part
everyone except one misguided CEO (now at Docker) cared about, has always been
completely open source.

------
poooogles
This does make me wonder how it'll impact their eventual move to Python3.
They've been hesitant to move due to a lot of their customer base being on
RHEL5/CentOS5, I can't imagine that this move will help matters.

------
qznc
I always wonder why cf-engine is so unpopular on HN. It has some nice
advantages like no dependency on ssh or a scripting language. It is not as
simple to get started, though.

~~~
ybx
Is SSH really a dependency you have to worry about though? Basically every
server out there runs SSH.

~~~
bovermyer
SSH's major problem here is performance. When you need to orchestrate dozens
of servers with many separate tasks, then the slowdown is very noticeable.

------
JanusBifrons
Hi all. I am a GM at Red Hat, and I have been deeply involved in the
acquisition of Ansible. It's great to see so much interest and so many good
questions. I hope that my blog post can help answering some of them:
[http://www.redhat-cloudstrategy.com/why-did-red-hat-
acquire-...](http://www.redhat-cloudstrategy.com/why-did-red-hat-acquire-
ansible/)

Alessandro

------
devit
Every time I use some "configuration management" tool I wonder whether it's
really better than just using shell.

Basically you lose a lot of time searching the web for how to do things that
you already know how to do in shell, but the benefits are not so clear.

~~~
pilif
I thought so too for a long time. Until that time when I upgraded the RAID10
on our database servers from a 4 drive to a 8 drive configuration (which
requires rebuilding the whole array if you want the performance benefits).
Getting the intricate configuration of the two machines (postgres streaming
replication works, but has a lot of moving parts to keep in mind) back without
having to remember any details was absolutely priceless.

Completely wiping and reinstalling the main database servers (one after
another of course) during the day while the system was in active use and
completing the process with zero user intervention, that felt amazing.

Since then, whenever I had to reinstall a machine for one reason or another, I
always appreciated the immense speed-up I gained by not having to ever
manually re-do the configuration.

Better yet: All the years of growing the configuration, all the small insights
learned over time, all the small fixes to the configuration: All are preserved
and readily available. Even better: By using git, I can even go back in time
and learn why I did what and when.

"Why am I using TCP for NFS? Oh right - that was back in december of 2012 when
we were using UDP and we ran into that kernel deadlock" \- that's next to
impossible to do when you're configuring servers manually.

~~~
qznc
I don't think devit challenges the "automate" part, only the "separate tool"
part. In Ansible you specify a sequence of commands just like you do in a
shell script.

~~~
jjnoakes
Take the time to learn a tool like Ansible. It is not about replaying a simple
sequence of commands (imperative). It is more about declaring what you want
your system to look like, and letting the tool decide which pieces need to run
based on the current state of the system.

It's like make vs a shell script. If you use scripts to build your programs,
you either have to write your own checks to test whether every step is
necessary or not (cumbersome, error prone, and quite complex) or you just
script it to build from scratch every time (inefficient).

But for systems management, rebuilding from scratch can be worse than just
inefficient. Imagine if your script reinstalled MySQL from scratch every time
you ran it...

~~~
devit
Most shell commands are actually "declarative" in a sense.

If you run "apt-get -y install foo" that means that you want "foo" to be
installed. If it's already installed, it just does nothing.

In Ansible, you'd use "apt: name=foo state=present" which does exactly the
same thing as the apt-get command, but requires a web search to figure out how
to write (assuming you know normal Linux system usage but haven't memorized
Ansible).

The only differences seem to be that Ansible tells you whether the command
made a change or not, and that you can parse the Ansible configuration with an
external tool (assuming there are no loops/variable/etc.), but both of these
things don't really seem that useful in practice.

~~~
pilif
> "apt-get -y install foo" that means that you want "foo" to be installed. If
> it's already installed, it just does nothing.

not really. If you do that it means that you want to update foo to the latest
version the system knows about.

And other commands fail if the thing they are supposed to to is already done.
Like `adducer`. So you could still run it and assume a failure to mean "the
user already exists" \- but it could of course also mean: "the user didn't
exist, but creating it failed".

Then you start to have a look at the exit code which may be different between
the two cases.

But every command behaves differently, so you need to learn all of this.

With Ansible (or puppet), the syntax is always the same and the actually
needed operations are abstracted away.

~~~
jjnoakes
Again, my advice is to take some time and learn the tools before discussing
their strengths and weaknesses.

You missed more Ansible strengths, like detecting changes and restarting only
affected services for example. Show me the idempotent shell script which does
apt-get to install some dependency, updates some configuration file, and then
starts or restarts a service depending on both the current state of the
service (was it already running?) and whether the apt-get or config file
change actuallly modified things.

Then scale that up. A lot.

There is even more. If you care to learn it before dismissing it.

~~~
jjnoakes
Oops, this was meant to reply to the parent of whom I replied to.

------
maweki
I think that this will fit nicely with the Cockpit project which should
"revolutionize" remote administration (it isn't bad). So now Red Hat wants to
add something for wholesome orchestration, which was really needed in that
space.

------
homulilly
I like what I've seen of ansible but a lot of their modules are a complete
mess. I've run into problems with both their AWS and Docker modules and ended
up resorting to a series of tasks running shell commands because it was more
reliable and didn't require me to install a specific version of some python
library on every single machine.

------
lvandeyar
I hope they don't kill the free version of Ansible!

~~~
MrOwen
Has Red Hat ever done this with anything? I think a lot of their products
exist as open-source versions. Satellite -> Katello, OpenShift is open-source,
CloudForms -> ManageIQ, Red Hat Identity Management -> FreeIPA, RHEL ->
CentOS. I suspect the list goes on and I have a hunch they will open-source
Tower in the near future.

------
WestCoastJustin
If you're new to Ansible. I've created about two hours of free screencasts on
it. It's a very simple to use and understand configuration management tool.

[https://sysadmincasts.com/episodes/43-19-minutes-with-
ansibl...](https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-
part-1-4)

[https://sysadmincasts.com/episodes/45-learning-ansible-
with-...](https://sysadmincasts.com/episodes/45-learning-ansible-with-vagrant-
part-2-4)

[https://sysadmincasts.com/episodes/46-configuration-
manageme...](https://sysadmincasts.com/episodes/46-configuration-management-
with-ansible-part-3-4)

[https://sysadmincasts.com/episodes/47-zero-downtime-
deployme...](https://sysadmincasts.com/episodes/47-zero-downtime-deployments-
with-ansible-part-4-4)

~~~
sbierwagen
Wow, what's with all the spammy replies to this comment?

~~~
bigdubs
Either it's a strange coincidence or someone spent a lot of time and care
creating astroturfing accounts. All are old, have comments and submissions,
seem like real people.

~~~
binaryautomata
They all appear to have suspiciously low karma and durations of consistent
activity. I think someone _cough_ went to a lot of trouble..

~~~
WestCoastJustin
Are you for real? Look at my account history. You really think I'd spam HN.
Been on flights all day or I would have addressed these comments earlier.
Suspect these are just happy people. More than willing to address this with HN
admins if they have any questions.

------
mianos
If ansible is worth 100 what is saltstack worth?

~~~
kzhahou
Are you implying it's worth more or less?

Or not implying anything but hoping someone here has an answer or analysis?

~~~
mianos
saltstack is a bit harder to get started but it is, IMHO, a much larger
product. I am implying saltstack should be worth more. That said, ansible may
prove to become more popular and grow to be bigger than saltstack.

