4 ms·

From my viewpoint, Puppet's portfolio is comprised of mostly half-baked stuff. You have Puppet itself, which is decent, and then an almost Google-level of weird

From my viewpoint, Puppet's portfolio is comprised of mostly half-baked stuff. You have Puppet itself, which is decent, and then an almost Google-level of weird stuff. They keep announcing new products but so far nothing seems to be sticking and they're all ludicrously expensive IMHO. 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.

dharmab 6y ago
Even for those of us still managing VM fleets, containerization means that we can run a single OS image for everything, eliminating most of the need for a dedicated CM tool.
Lightbody 6y ago
Being a Portland techie, I pay a tiny bit of attention to Puppet and I’d say I agree with your comment re: product portfolio, until about a year ago. They have actually killed off a number of things in recognition of this critique and are trying to bring back focus on a sane portfolio strategy.
xorcist 6y ago
Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML. 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.
- TheCraiggers 6y ago
  > Puppet is a great tool for managing containers, and so is Chef. 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.
  - xorcist 6y ago
    Not sure what the argument here is. Different builds for prod, qa and test? 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.
    - TheCraiggers 6y ago
      Well, the container manifest (or whatever you call it) is checked into version control. How you choose to deploy that is up to you, but a ton of CICD tools out there are made for just that purpose. 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.

dharmab 6y ago

Even for those of us still managing VM fleets, containerization means that we can run a single OS image for everything, eliminating most of the need for a dedicated CM tool.

Lightbody 6y ago

Being a Portland techie, I pay a tiny bit of attention to Puppet and I’d say I agree with your comment re: product portfolio, until about a year ago. They have actually killed off a number of things in recognition of this critique and are trying to bring back focus on a sane portfolio strategy.

xorcist 6y ago

Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML. 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.

TheCraiggers 6y ago
> Puppet is a great tool for managing containers, and so is Chef. 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.
- xorcist 6y ago
  Not sure what the argument here is. Different builds for prod, qa and test? 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.
  - TheCraiggers 6y ago
    Well, the container manifest (or whatever you call it) is checked into version control. How you choose to deploy that is up to you, but a ton of CICD tools out there are made for just that purpose. 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.