Why I chose SaltStack over Puppet
In the world of Development Operations (or DevOps as it's coming to be known today), there are many tools coming into focus that are allowing us to do more and expand to newer heights than before.
In this post, I want to talk about Puppet and SaltStack.
Both are really great tools, don't get me wrong. I admire the power and benefits of both, but there were solid reasons we chose to go with one over the other, and reasons why I still chose one over the other today. This is going to be a compare and contrast post between the two technologies.
Puppet is a great tool for what it was designed to do. It was also first on the market with its first beta version back in 2005. It's first 2.6 release in 2010, and I came to know about it around version 3.x in 2013. It's good for what it was originally created to perform: Systems automation. However the catalog creation process is often a bottleneck in performance and has been a constant complaint in the industry. The special DSL (Domain Specific Language) they use to describe how a server is built in an automated fashion causes an increased amount of on-boarding knowledge transfer and research to understand how it works.
You can further go down this path by writing custom Ruby modules, since Puppet is written in the Ruby Programming Language. If you're not careful, you can have a lot of intricacies that cause some major headaches later down the road (like with any framework that gets larger than a particular threshold).
Also called "Salt" for short. This appears to have been a complete rewrite over Puppet. It's like they took out all the good things from Puppet, and left all the bad behind. In this automation framework, it can still do just about anything you need a server to do automatically, and gives you enough freedom to do more if necessary. From automating firewalls to managed files, to installing software to keeping services online and ensure they start on next boot, SaltStack does it all. It also has a bus/reactor system for handling asynchronous events, and hooks where you can create your own custom grains, pillar objects, modules, returners, and more.
https://github.com/saltstack/salt/releases?after=v2014.7.0rc3
As far as onboarding is concerned: I like how Salt uses existing technologies like YAML and Jinja to render the templates that describe what a server should look like and behave. There's no custom parser required and no additional technologies to understand to get started as long as you can understand the YAML data structures.
SaltStack was also written in Python. You can implement custom modules using and leveraging Python and the vast libraries of code available as long as the PIP extension is installed local to the machine hosting the salt-minion. This allows for very advanced features, but also drives to the earlier point about making things so complex, others cannot pickup and go without first understanding what the underlying code is doing. Be careful with this one!
I still have yet to explore all of the functionality available and find a place where it makes sense to apply it, but SaltStack definitely has a lot to offer in terms of automation, homogeneous server environments, remote execution, handling of events and more.
In this post, I want to talk about Puppet and SaltStack.
Both are really great tools, don't get me wrong. I admire the power and benefits of both, but there were solid reasons we chose to go with one over the other, and reasons why I still chose one over the other today. This is going to be a compare and contrast post between the two technologies.
Puppet
Let's talk about Puppet: https://puppet.com/.Puppet is a great tool for what it was designed to do. It was also first on the market with its first beta version back in 2005. It's first 2.6 release in 2010, and I came to know about it around version 3.x in 2013. It's good for what it was originally created to perform: Systems automation. However the catalog creation process is often a bottleneck in performance and has been a constant complaint in the industry. The special DSL (Domain Specific Language) they use to describe how a server is built in an automated fashion causes an increased amount of on-boarding knowledge transfer and research to understand how it works.
You can further go down this path by writing custom Ruby modules, since Puppet is written in the Ruby Programming Language. If you're not careful, you can have a lot of intricacies that cause some major headaches later down the road (like with any framework that gets larger than a particular threshold).
SaltStack
Let's talk about SaltStack: https://saltstack.com/.Also called "Salt" for short. This appears to have been a complete rewrite over Puppet. It's like they took out all the good things from Puppet, and left all the bad behind. In this automation framework, it can still do just about anything you need a server to do automatically, and gives you enough freedom to do more if necessary. From automating firewalls to managed files, to installing software to keeping services online and ensure they start on next boot, SaltStack does it all. It also has a bus/reactor system for handling asynchronous events, and hooks where you can create your own custom grains, pillar objects, modules, returners, and more.
https://github.com/saltstack/salt/releases?after=v2014.7.0rc3
As far as onboarding is concerned: I like how Salt uses existing technologies like YAML and Jinja to render the templates that describe what a server should look like and behave. There's no custom parser required and no additional technologies to understand to get started as long as you can understand the YAML data structures.
SaltStack was also written in Python. You can implement custom modules using and leveraging Python and the vast libraries of code available as long as the PIP extension is installed local to the machine hosting the salt-minion. This allows for very advanced features, but also drives to the earlier point about making things so complex, others cannot pickup and go without first understanding what the underlying code is doing. Be careful with this one!
I still have yet to explore all of the functionality available and find a place where it makes sense to apply it, but SaltStack definitely has a lot to offer in terms of automation, homogeneous server environments, remote execution, handling of events and more.
Comments
Post a Comment