|
|
|
|
|
by cparedes
5049 days ago
|
|
Author here. NT? (edit: you mean non-technical? I'm definitely not non-technical - I work as a systems engineer by trade.) And, yes, you don't need to use Chef or Puppet to solve the software deployment problem. You use it to ensure system state, so you know you can throw software on top of it without any problems. (this can go on into a debate about golden images vs. configuration management, but I think this is a different discussion.) That's probably true as well, though... I've been in shops without Chef or Puppet, and it's really not a big deal for me, either. The thing that stood out was the justification for not choosing Chef or Puppet, not really the fact that they weren't using it. |
|
On a technical note, it's not clear to me how you KNOW that chef or puppet has solved your system state problem. Now if its limited to doing super basic stuff, ok great, but then you really arent adding enough value to justify the huge cost of these systems.
I'd also like to hear what you have to say about "throw software on top of it"... for example, I want all 40 webservers to have the same build revision of our codebase. But I need positive feedback - and a gradual rollout possibly. Eventually run puppet clients really dont tell us this. Oh wait, I mean I want to rollback to the previous deployed version, because it's broken horribly.
These practical software deployment issues I find just are not addressed by the system configuration management tools like chef, puppet.
And that is why they are so passionate about it, because a million people have told them 'just use chef' and yet chef doesnt solve their problem at all, nor does it solve any fraction of their problem either.