Comment by mattzito | Hacker News Reader

Comment by mattzito | Hacker News Reader

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.

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?

It's lighter-weight than virtualization but provides many of the benefits, even if you mutate running containers.

Config file changes rather than code changes. Version of the software stays the same, so you just have to restart it.

But one of the central points of Continuous Delivery is that there is no difference between "configuration" and "code", and that changes for either of them will result in a new release candidate. Every release candidate goes through the same automated quality checks before going to production.

Well, there's a couple of scenarios:

- Long-running processes where they don't want to destroy and redeploy every single time a fix or change gets deployed

- One is where they try to reduce the configuration sprawl by making configuration changes at runtime using something like ansible

- One is straight-up bigco stupidity (we must have a way to change the running configuration of a system because the audit team says so)

- separation of responsibilities - we have one team that builds "approved" docker images, and then dev teams can make changes based on that - it might be easier to deploy changes at launch time

Again, I'm not saying all of these make sense, but back when I was workign on docker strategy and interviewing really big companies, these are the types of concerns they had about implementing docker at scale.

Managing the container hosts.

Containers are useful as an alternative to full VMs. I use LXC on Ubuntu, and I edit software and packages on my containers as I would a normal VM.

Maybe that's not standard with Docker specifically.

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.

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.

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.

Ansible's Python as well, so will integrate well with the rest of RHEL, whereas Puppet was nearly the only Ruby tool in the Unix sysadmin community.

Not saying that one is better than the other, just than there's more Python out there in sysadminland.

I don't think that's necessarily true - both Puppet and Chef are Ruby, and you'll often hear Ruby referred to as the "lingua franca" of DevOps.

In certain shops that may be true, but definitely not all. Python has had a large role in Red Hat's tools for a very long time so I bet you'll find more Python than Ruby in sysadmin-land overall.

If you aren't using Rails for your web-stack, I suspect you might not be using any Ruby at all on a server. It isn't even part of the CentOS minimal install. Python is. I'm not sure about how Ruby is used in Ubuntu, maybe it's more common there.

However, language choice alone makes Ansible more "compatible" with the rest of the RHEL stack.

> If you aren't using Rails for your web-stack, I suspect you might not be using any Ruby at all on a server. It isn't even part of the CentOS minimal install. Python is. I'm not sure about how Ruby is used in Ubuntu, maybe it's more common there.

There is no Ruby installed by default in Ubuntu - or Debian last time I looked. Also (like Redhat) a significant chunk of the userspace distro code is written in Python.

Currently Vagrant is the only Ruby tool I use in sysadmin/devops land, and it's a workstation only installation rather than a server one.

Not having to deploy a whole new language runtime for your devops tooling is why I preferred Ansible and Salt over Chef and Puppet.

Since most people don't know Ruby I don't know how you can say this.

I do most DevOps from a Java perspective. Languages aren't even mentioned here:

https://en.wikipedia.org/wiki/DevOps

>* Ruby referred to as the "lingua franca" of DevOps*

I've been in IT since 1997, ops for a great portion of that and now "devops" since before that was a thing...

Never heard anyone say Ruby is anything... unless you were building or working for a Heroku based service or company I guess...

Tcl/Tk would like to have a word with you.

sidenote: puppet is migrating to clojure.

http://www.infoworld.com/article/2687553/devops/puppet-serve...

For server-side frameworks. Agent-side development is moving to C++. Plugins for Puppet are still written in Ruby.

Yeah, OpenStack support will be a big thing for them I think.

Ansible is growing its OpenStack support, and they might see an opportunity for the RDO product.

A minor nit-pick: RDO is community project :-)

If anyone is wondering what the 'RDO' acronym stands for, from the FAQ[1]:

"RDO has no expansion or longer name, officially. It is not an acronym or abbreviation for anything.

However, RDO does focus on building a distribution of OpenStack specific to Red Hat operating systems (and clones of Red Hat operating systems). So, in some sense you can think of RDO as being a project started by Red Hat to build a distribution of OpenStack.

The 3 letter meaningless acronym sort of comes from that line of thinking."

[1] https://www.rdoproject.org/Frequently_Asked_Questions

SMB = small business?

Small and Medium Business

Small and Medium Business

Redhat and Mirantis are now direct competitors in the Openstack world. Redhat buying ansible, among the the great points you made, will further solidify their position in the Openstack world against Mirantis going forward...

I think it's hard to compare RedHat to Mirantis even tho they are taking a bit of market to them they are not playing in the same league, it's like to say Docker is a great competitor to Vmware inc,

Reply on news.ycombinator.com