Why Red Hat Acquired Ansible
redhat.com
redhat.com
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.
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.
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! ;)
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!
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 Hat are the anti-Oracle.
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.
(Graph of mentions of popular CM/orchestration tools on HN.)
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).
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.
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.
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.
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. =)
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.
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).
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.
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.
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
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.
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.
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?
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.