It's confirmed then. Absolutely nobody wants to buy Puppet. Anyone know why that fell through?
Meanwhile, their core technology is kind of a dead end. More and more people are looking to manage containers and other serverless type things, rather than managing fleets of VMs. They're not in the same boat as companies like VmWare, but they're in the same flotilla. If somebody does buy them, it'll probably be an act of dinosaurs mating and not much else.
There is less buzz around those tools now however, and people tend to gravitate to other tools which are easier to get started with.
They may end up "silent heroes" (much like Ruby itself, I would say) or they may end up replaced by other tools. The concept of state as text in version control is a timeless concept and continue to exist in one form or another.
One of the problems with configurations management systems is that they are conceptually easy, everyone has opinions of them, and they really need to control your whole world in order to shine. There was never really room for one clear standard to emerge.
Puppet Inc.'s problem was that they kept chasing shiny stuff (agentless you say? we have that too!) in order to woo enterprise customers. Their customers should have been developers and sysadmins, not their bosses. There is only room for so many VMware in the world.
I am not sure what complex config state management solution brings to the table for immutable containers. The state is immutable, so there's nothing to manage after deployment. It's like using an atom bomb to take out a zit.
Puppet/Chef in their glory days, pre-cloud pre-container, excelled at managing desired state across numerous mutable static systems. With immutable solutions, Puppet/Chef are both cumbersome and expensive.
The deployment side also carries configuration, including things like desired amount of instances, request routing and filtering, log destinations, log retention, persistent volume sizes and location, backup rules, metrics and monitoring rules etc.
If anything, application deployments today carry more configuration, not less. Fifteen years ago, half of the above didn't even exist. Perhaps you pointed you application to a syslog server and that was it.
All of this configuration exists in disparate tools (JSON files, YAML files, firewalls, metrics dashboards, cloud providers proprietary APIs) and will over time slowly turn into a sprawling mess. Bringing control over this into a central repository is a good thing.
Not sure about expensive, as the aim is maintainability and reduced complexity, but these tools do tend to get cumbersome. After all, they want to do everything. It's a fundamental problem. It's not surprising that has led to a surge in less capable tools.
But Kubernetes solves most of this problem in an easier way with Pods, ConfigMaps, Secrets, Services and Endpoints.
Your whole infrastructure contains much more than that, and managing all that as a coherent whole is what these tools do.
Testing Puppet manifests locally is (was) THE WORST. Hiera and r10k really shouldn’t exist in 2020. IIRC you essentially need long-lived Git branches for managing different envs for different playbooks.
Ansible is just SSH and a binary. pip install and I’m done. This is great for building VMs, base Docker images, app deployments, whatever you need. Puppet has their own wire protocol and is very dependent on a client-server relationship. You need to edit config files and fake a puppet master. That’s work.
What kind of branching strategy is most suitable is given from how your testing is organized, not which particular tools are chosen.
Ansible is completely equivalent to Puppet or Chef in this regard. They are all the same family of tools. Many find Ansible easier to get started with due to its agentless defaults, but there are some (perhaps Spotify was most well known at the time) who run Puppet agentless too.
Having a server, something like Tower, is necessary as soon as you want to manage distributed configuration for clusters, and if you manage monitoring and backup systems.
Eh. While I won't say that it can't be used, I will argue that it's not the best tool for the job. I wouldn't call it a "great tool" for that purpose, although I suppose that depends on your workflow. I prefer to take the approach that containers are immutable once built. If you want to change the container, fine- make your changes, build a new instance, hotswap the connections over, and bring down the old one. There's no need for any sort of config management in my eyes, at least not in the traditional sense.
Now, Puppet could be useful for things like managing the VMs that the containers are running on, but I would prefer those stay immutable too, and with containers, they easily can. I'm (sadly) very aware that not all enterprise software can fit in this model though. Enterprise always lags behind, but it will get there. Hell, even SAP is heavily exploring containers. It's only a matter of time.
Even if that was workable, which is a question in itself, there is still configuration outside the packaged application. AWS keys, metrics and logs, dashboards, that sort of things.
Likewise, how you separate config data and deploy to production is an age old problem with many solutions as well. Sure, Puppet can even be a solution here, but you're just kicking the can down the road. How do you separate your Puppet code from data? Put it in Hiera? OK, how do you promote Hiera? It's the same issue.
Both of these issues were solved long ago before Puppet came along, and what we all learned from back then still applies: separate your data, config, and code. Version control as much as possible. There are many simple solutions that don't require Puppet. Hell, set up a bind mount to an external config store. Or something fancier like your CICD tool bundling the config data and signing it with a cert that only a certain environment can use so you never get dev code running in prod.
The argument is that when your infrastructure is immutable (which is the direction most of us are going) you don't need a tool to manage the configuration of said infrastructure. Because it can't change. When you do want it to change, you just follow the typical code SDLC and use the powers of version control and CICD.
Should you at some time replace all this with a common data format, then congratulations you have invented a configuration management system very similar to Chef.
The use of a version control system or a CI/CD system does not somehow negate the need to keep configuration, neither does a configuration management system do the job of the former. Nobody builds their software using Puppet, they use something like Jenkins. In fact, I would consider having VCS and CI/CD in place a prerequisite to any type of configuration management.
In total over 12 years, Chef raised around 105M and puppet raised around 189M in funding.
They're both doing pretty bad in the end and are on a (steep?) downward trend. They'll never be a billion dollar business. They probably won't recoup their valuation. Chef sold out. Puppet tries to survive.
From my perspective Chef users were actively fleeing so I guess it was sold for scrap, puppet might be downward but maybe not as steep so maybe puppet is trying to continue to operate as a small medium company. Also Puppet might be a fairly harder sell because it has both a higher valuation and debt, doesn't look like a great buying opportunity.
https://github.com/skx/puppet-summary/
Simple to deploy, configure, and use. Although I always felt I should perhaps have based my work against the puppetdb to get a more dynamic "dashboard" it certainly replaced the old dashboard, and being only a single binary it is simple to install & manage.
(Though I don't know if it supported puppet at that time.)
On Puppet, I think they are a different beast to Chef at this point. They seem hyper focused on the larger enterprises rather than SMB or startup land. I came across them at both of the banks I recently contracted for, for example. Whilst I wasn’t hands on myself, there was a big project to roll out Puppet’s impact analysis and CD product at the last place.
I also ‘think’ Puppet are about double the size of Chef and saw their BlackRock debt round announced. You don’t get money from someone like that unless your at scale and you don’t get debt (especially at a time like this) unless you can afford the payments+interest. So, they must be at least growing if not profitable as well.
Again, only casual observer, so my impression may be overly negative.