Hacker News new | comments | show | ask | jobs | submit login
Why Red Hat Acquired Ansible (redhat.com)
194 points by anacleto 788 days ago | hide | past | web | favorite | 51 comments



I hope that mpdehaan2 is getting a good chunk from that sale, he really deserved it. He not only made it and built a community but he was very active in the discussions on HN, blog & Gist comments etc.

Even though I'm looking forward to using NixOps/GuixOps, I'm a very happy Ansible user both in personal projects and in the company I'm working for.


Yep, he definitely deserves it. The second biggest reason I chose Ansible over Puppet was that he answered my questions directly. There's nothing quite like having the founder of a project help you directly that really inspires confidence in the product.


I really would like to hear his opinion about this. Is this how he imagined Ansible when he started this project?


Hi! Thanks for the nice words, folks!

Wasn't thinking of saying much but I'll chime in just once.

Was it what I expected when I started? nah, I remember when I thought having a IRC channel with 30 people was crazy-insanely huge, it took off at completely unexpected rates. Just to get some early looks at it from Seth Vidal and Jeremy Katz (and a commit or two!) was awesome enough for me at the time. It wasn't engineered with the idea that it would be a business at that point at all.

BTW, extremly huge thanks for this really should also go to all the contributors out there and people that helped spread ansible around, that was completely unpredictable and a lot of fun watching it take off, especially stuff like seeing so many AM tweets in Japanese and then trying to translate them, or seeing someone automate random vending machines or electronics projects. This got built trying to help people like you, so a huge thanks for all of the input and help!

Anyway, those words mean a lot, and I greatly appreciate them.


Congratulations, and thanks for making a simple automation tool that I have come to love!

You guys definitely were very active in the community. Enough for the likes of me to also become an active tweet-er. I was pretty excited when @tybstar (Tim Gerla), Ansible's co-founder, chimed in once. I hope you guys share some chunk of the sale with him too! ;)


Thanks and congrats! I have been using Ansible since version 0.2 when there were like 5 modules. Since then I have introduced and promoted it to every company I have been working for. Well done!


Congratulations!

Also thanks for the way you managed the project. Ansible was the first big, well known Open Source project that I contributed to, and it was in great part due to the effort you put in welcoming everybody in the IRC channel and mailing list.

Well done!


Congrats man! Your IRC Q&A sessions (even on weekends!) were always a huge help and very appreciated. Thanks for such a great product and good luck in the future.


Here's one more big thank-you to you and everyone else who made Ansible what it is: excellent. Congratulations!


Great job and congratulations!


The biggest question is: is Red Hat going to release Tower as open-source ?

Red Hat is an open-source company and I would expect them to do so but they didn't even mention Tower.

EDIT: From their FAQ[0] it's not clear either. It seems to be pointing towards no.

> Red Hat plans to continue to develop, sell and support Ansible and Ansible Tower.

[0]: https://www.redhat.com/en/about/blog/faq-red-hat-acquires-an...


Red Hatter here. We have open sourced all acquisitions, I don't know what exactly leads you to think it won't be open sourced, the FAQ just states there'll be a timeline, as it was the case previously for ManageIQ (manageiq.org)


They've aquired and freed (that I know of): RHEV (originally Qumranet, upstream is oVirt), ManageIQ (aquisition, upstream is ManageIQ, commercial is CloudForms), and are in the process of open sourcing the Ceph commercial management tools.

Red Hat are the anti-Oracle.


Read further down the FAQ:

Q. Will Red Hat open source all of Ansible's technology? Most of Ansible is already open source today. Red Hat has long shown its commitment to open-sourcing the technology it acquires, and we have no reason to expect a change in this approach. Our specific plans and timeline will be determined over the coming months.


It's actually not as great as they make it sound. It would awesome if they open source it so more features can be added. As it stands today it is grossly overpriced for what it does (and how it does it)


You mean, it's not to take the lead in the fight against the Formics?


[flagged]


It sounds like you're the intolerant one.


I can play that game too.

I may be a CIS hetero male but the REAL reason he downvoted me is because I'm black, making him a racist.


Also see the FAQ, which answers (more or less) many of the questions that have popped up in these threads: http://www.redhat.com/en/about/blog/faq-red-hat-acquires-ans...


I feel somewhat pleased that they mention the "Hacker News" community :)


Specifically: http://dberkholz-media.redmonk.com/dberkholz/files/2015/04/h...

(Graph of mentions of popular CM/orchestration tools on HN.)


Last week at Amazon re:Invent, the HN community was also mentioned in one of the keynote speeches.


The project name is also excellent, Ender's Game is among my favorite books.


Orson Scott Card borrowed the name from Ursula K, LeGuin. You should check out The Dispossesed (about the inventor of the ansible). It's a great book.


I have a feeling the reasons listed in that posting hardly even come close to the primary real reasons why the acquisition happened.

What the real reasons are I'm not sure entirely but I'm fairly certain its some what Red Hat getting some talented people back and Red Hat giving money back to its friends and family (much of Ansible's talent formerly worked at Red Hat).


I like and use Ansible, but unfortunately I have always found the quality of the 3rd party software playbook (both on Galaxy and elsewhere) is not nearly as professional or comprehensive as equivalent Puppet or Chef ones. Hopefully people invest more time into this side of things now Red Hat is involved.


Congrats to the unmitigated badasses on the Ansible team! You know who you be!


I went to the Ansible conference in London last year. We were looking into whether or not to use Ansible, thinking that going to the conference would shed some light.

To be honest, we were put off by the (I use this word advisedly) fanboyism. There was a huge amount of "Ansible is amazing!" and (in my opinion) not much actual substance. It felt like there was lots of back-slapping.

Toward the end of the day there was a presentation which presented features (possibly new ones) demonstrating how they were contorting (presumably declarative) YAML into a new programming language with control structures (and templating, my memory is hazy). It felt like "our deployment scripts were over-complicated so we took out the complexity and put it in a declarative non-executable format. Then we had to put the features back because we needed them after all, except now it's in new less powerful language".

Anyway, the conference was informative, but probably not in the way intended.

That said, if you can give some substantial reasons why to use Ansible, it would be great to hear them.


This is pretty much where I'm at. By the time you bolt back in everything that Ansible removes "for simplicity" because you realize that, hey, you stepped on that rake and would like to not step on it again, you've more or less reinvented Chef with YAML (I forget who around here called YAML the new S-expressions, but it's uncomfortably true) instead of a usable programming language as your DSL. The overwhelming volume of the community (edit: I called them "fanboys" before, and that's not fair; I think they're unreasonable but I'm not in their heads) makes me wonder at times whether or not it's trying to ignore picking the slower horse by being really enthusiastic about it.

My current client paid me to drop Ansible and rewrite the experimental Ansible service in Chef, and it's under half the lines of committed code in our repo and they don't have to deal with the bogus state of Ansible dependency management.


>That said, if you can give some substantial reasons why to use Ansible, it would be great to hear them.

I'm using Ansible, but with a handful of powerful plugins that I developed and haven't contributed back (sorry, but I don't have the time to do support for that ugly-ish code).

I use it because:

- Having an agentless setup is ideal (anyone that tells you that Chef/Puppet agents have never cost him/her time is either a new user or trying to sell you something)

- The YAML, then Jinja2 parse can be annoying, but it's ultimately not that painful once you're used to it

- N-number of SSH Bastion/Ansible-runners fed from a git branch scales better than Chef Server

- I'm a Python developer and I've found it reasonably easy to "monkey-patch" in behaviors that I prefer/need

- Ansible doesn't force a workflow on you, so you can just focus on "getting shit done"

- I plan on taking the YAML that my team generates and feeding it into a different system and the fact that it's in a popular format makes that easier than the alternatives

I had the same experience as you after attending an AnsibleFest and dialed-back on my time spent supporting users in IRC and contributing to the project after. I expected a collection of hackers and instead came away disheartened by the number of sales or marketing bros/chicks and how corporate-smarmy it all felt.


> - Having an agentless setup is ideal (anyone that tells you that Chef/Puppet agents have never cost him/her time is either a new user or trying to sell you something)

An agentless setup is ideal iff you have an effective method of service discovery and strongly consistent data storage. Most of my clients don't, and chef-server is the closest thing. My own systems use chef-zero, which is agentless; since they're generally immutable servers, this just gets dropped into AWS userdata, much as I do when I use Ansible, for a one-shot configuration and I'm off to the races.

> - The YAML, then Jinja2 parse can be annoying, but it's ultimately not that painful once you're used to it

It's significantly worse than "if (var) { block }", though, yeah? I mean, yes, it works, but I think that having a programming language with conventionally understood data structures and functions, to say nothing of a parsed configuration spec that you can do transforms over, is a decent bit more useful in the general case. Faster to write, easier to read, and, over the long term, I tend to think it's easier to maintain.

I mean--I'm a programmer. Programming things is easier for me than maintaining YAML files. =)

> - I'm a Python developer and I've found it reasonably easy to "monkey-patch" in behaviors that I prefer/need

This is really the big plus to Ansible that I can see; if you're a Python person and not a Ruby person, I can see some value here. (I am a Ruby person.)

> - Ansible doesn't force a workflow on you, so you can just focus on "getting shit done"

Chef Zero here too (though Berks tends to be helpful anyway). Running chef-zero over `ssh` is a pretty fair approximation of what most folks use Ansible for.

All that said, I'm not saying you shouldn't use Ansible, and I dig that you have some perspective about it. Just offering a different point of view. =)


>An agentless setup is ideal iff you have an effective method of service discovery and strongly consistent data storage.

Sure, or use tag and/or have AWS (aws can be used as a node classifier).

>It's significantly worse than "if (var) { block }", though, yeah? I mean, yes, it works, but I think that having a programming language with conventionally understood data structures and functions

I'm not sure what you mean -- it's YAML + Jinja2. It's just powerful enough that you can hand it off to an Ops team and they can get stuff done.

>I mean--I'm a programmer. Programming things is easier for me than maintaining YAML files. =)

Agreed. I actually hit a point that I said "fuck this" and almost just wrote chunks of python to stitch together with jinja includes, then base64, send and run. I didn't because with Ansible, I can just point others at a doc that I don't maintain (not to say the docs aren't garbage).

>(though Berks tends to be helpful anyway)

Ha -- petty, but I hate the amount of memes like "berkshelf" in the Ruby/Chef toolchain. "berks" is enough to make me involuntarily scoff.

>All that said, I'm not saying you shouldn't use Ansible, and I dig that you have some perspective about it. Just offering a different point of view. =)

Didn't take it that way :) I spent over a year with Chef+agent/Chef-zero/Chef-solo, about a year with Puppet, before using Ansible. I find that Ansible "just goes away" with less effort and doesn't just grow until it eats your entire ops team.


There are a lot of reasons to use ansible, but in my opinion the one thing that sets it apart from other orchestration frameworks (saltstack, puppet, chef) is that it's agentless. You don't need anything installed on the node servers except for ssh and python 2.4+ (which means pretty much any major distro but coreos). There is no master node to keep up, and no specialized daemons running on the managed nodes.

Because of this difference it's really easy to incorporate into an existing infrastructure with no current frameworks. Pretty much every job i've had started off with a bunch of existing servers they set up ad-hoc, which we then wanted to add automated orchestration to.

It's also really easy to use your defined playbooks against different contexts (just use the hosts file switch to run against staging, or a cluster of test vms, or a bunch of lxc containers).


Chef needs to be installed, but it can be (easily!) run in an agentless mode via chef-solo or chef-zero. It can be installed from Rubygems and requires no master node.


I think using sshkit and chef-solo you could easily achive the agentless model ansible provides with a more mature toolset and community. I never really understood peoples aversion towards agents though. You literally can create a golden image with chef-client and your done. There is very little cpu or memory overhead from the chef-client and it only runs when requested unless you run it in daemon mode. I think Ansible capitalized on people's wariness/lack of experience using chef rather than there experience causing them to look for an alternative.


Sure, even salt supports an agentless mode, but these are designed as afterthoughts. When you look at all the agentless mode versions of these tools you find that it doesn't fully support everything the framework is capable of (i.e., see the main page of chef-solo). Thus, the adoption is low and you'll likely find breakage as the tool matures (new features being developed without consideration of the audience using it in an agentless mode) and you're likely to find little help when you ask for it. Contrast this with ansible, where this is the basis of the framework, so everything built around it works in agentless mode.

So no, nobody is saying you can't run chef/salt in agentless mode, but in practice nobody wants to because it's a lot of work. And it's not like ansible doesn't also run in a managed-by-master-node mode, that's the entire basis of ansible tower.

And to be clear, it's not that I like ansible because it's agentless. It's because the benefits of the tool being designed-from-the-ground-up as agentless leads itself to beneficial properties.

> You literally can create a golden image with chef-client and your done

This is a lot more work than you let on. That client needs to be configured to point to a particular master node. So yes, you can create a golden image, and it'll talk to one master node, and run on one platform. Good luck getting your golden AMI to run locally in VMWare, or virtualbox, or in a LXC container. Good luck adding in the functionality to make your client dynamically select a different master. It's not impossible, it's just not dead easy. The fact that this is an annoying thing to do is proven by the existence of salt-bootstrap (it's a tool that SSH'es into a node and sets it up as a salt client, hrm, now where else have we seen a tool that manages a node only using ssh?)

> I think Ansible capitalized on people's wariness/lack of experience using chef

I think this is a rather unfair generalization to make. I've personally had many years of production experience with chef/puppet/fabric and the only reason I have no actual production experience with salt is because ansible came out soon after (I still follow their development with interest). In my experience, the people I know who use ansible are neckbeard admin types with battle scars from other orchestration frameworks.


I use SaltStack masterless extensively. It works very well. It's not an after thought and numerous salt contributors use salt in a masterless setup.


I can only compare Ansible to Puppet, but I've had great success with rewriting a ton of hacky bash stuff directly in Ansible and having it feel much more 'maintainable.'

Perhaps if you're already using puppet/chef/salt it's not completely worth it to just suddenly switch to it, but it does feel "simple" to use; in my opinion it's worth use over Puppet solely due to the fact that you can really crank up the errors and get good messages.


Yeah. Same here. I used puppet but it's documentation is horrible (at least for newbies),the errors are not informative, the simple stuff is complicated and the puppet did not run things in order IIRC. In the end, I had a very fragile puppet based system and some bash scripts which I could not rewrite in puppet.

I moved everything to ansible and couldn't be happier. The documentation is excellent and since ansible executes in the order you specify, the flow is much easier to follow


I had the same problem with puppet (which I ran agentless). One downside to Puppet that Ansible solved for me was no dependency graph. When Puppet breaks, it's error messages are sometimes completely uninformative as to why or even where. When Ansible breaks, you know exactly where it broke and usually why.

The second downside of Puppet was that it freaks the hell out and refuse to work if it sees the same command in two different places. If I have two roles and in those roles I'm installing a single package in the same manner, Puppet throws a wobbly and won't run, even if the conf for them is identical. The official answer is "write a module for anything used twice", but sometimes it's just so trivial.

In any case, I think Ansible is certainly much better suited to small deployments than (agentless) Puppet.


I went to Ansible Fest 2014 in SF. IMO, the conference was pretty worthless outside talking to DeHaan and a few of the core developers. It was very sales focused and lacked much technical depth (what tech conference actually goes into any depth these days?).

This being said don't let that deter you. Ansible itself is an excellent project. I won't rehash what's already been said but both our dev and ops teams were able to transition off Chef and onto Ansible within a week. The time to onboard is miniscule compared to Chef, Puppet or CFEngine. There's been very little friction building customizing modules or contributing to an otherwise fantastic community.

As someone who moved from CFengine to Puppet to Chef and now Ansible I've been extremely happy.

FWIW, I'd argue that it's easier to fix a Python/YAML/Jinja error in your Ansible play/role/template than it is to try to track down attribute precedence and override issues or Ruby behaviors which aren't very Ruby like in Chef.


Sort of agreed. I'm not convinced the alternatives are actually that much better, and I really like the agent-less design, but it has tripped me up in unexpected ways often enough to be quite wary. ("Why doesn't this variable substitution work?", core modules clobbering config files because they are not allowed to contain specific magic strings, ...) And a lot of it seems like stuff that a better encoding than YAML could probably fix. Right now it feels like an awkward mix of a programming language and a not powerful enough encoding that's great for simpler stuff.


How does it work when an open source project is acquired? What's the benefit for RH compared to just forking the project?

I guess the choice of license can get really important in this situation? Are there any old decisions by the founder that now turn out to be especially important?


Congrats to all. I love ansible.


kheyli ali bod


very nice


I wonder how much F5 paid for that mention in the "why Ansible" section. Maybe I shouldn't, maybe it was a genuinely spontaneous example, but product positioning has become so ubiquitous that I can't help it.


It (and the Cisco and Microsoft mentions) might be a case of Red Hat showing that Ansible can configure what their customers use. As web developers, we have haproxy and nginx for load balancers, but at financial firms 'F5' is synonymous with the term. Disclosure: used to work at Red Hat.


A lot of larger companies use commercial load balancing appliances (A10 / F5) to provide a stable / secure implementation pipeline for SSL sites across multiple datacenters.

Nginx/HAproxy are great if you're a developer (and in fact, many developers at these companies will use one of those behind an appliance) but they kind of suck if you're trying to manage SSL certificates across a few thousand domains load balanced in 2-3 datacenters with round-robin IPs.

Also, the throughput on commercial load balancer appliances is crazy high, and there are plugins for injecting various headers, doing geographic load balancing, etc. Once you get into the high-traffic side of load balancing, your load balancer platform is also running your DNS -- so it can dole out the right IP address (with a short TTL, naturally) based on your proximity to specific exit nodes. It's nice to be able to manage all that from one platform if you're supporting several dozen sites / applications.


Not only financial firms, but many places with a little more of the CYA mentality—think medical providers, other large enterprises, etc. Nobody gets fired for recommending a vendor-backed hardware balancer/firewall solution.


They also mention the Citrix NetScaler further below that is a competing product to the F-5, so I guess they where not paid anything.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: