7 ms·
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
by mattzito 11y ago
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.
- walrus 11y agoSMB = small business?
- mugsie 11y agoYeah, 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.
- kashyapc 11y agoA 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 https://www.rdoproject.org/Frequently_Asked_Questions
- nailer 11y agoAnsible'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.
- rjsamson 11y agoI 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.
- mbreese 11y agoIn 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.
- antod 11y ago> 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.
- mrits 11y agoSince most people don't know Ruby I don't know how you can say this.
- superuser2 11y agoI 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?
- TallGuyShort 11y agoIt's lighter-weight than virtualization but provides many of the benefits, even if you mutate running containers.
- caw 11y agoConfig file changes rather than code changes. Version of the software stays the same, so you just have to restart it.
- cpitman 11y agoBut 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.
- mattzito 11y agoWell, 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.
- techdragon 11y agoManaging the container hosts.
- samstave 11y agoRedhat 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...
- samuel1604 11y agoI 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,