Wednesday, October 9, 2013

Why Saltstack is Better

Saltstacks is a powerful and robust remote execution tool

Saltstack started its life as an execution tool. It gives you the ability to execute commands across thousands of servers with scalpel precision.

Saltstack employs a job id system. Jids can be referenced and tracked after they are executed. They are even stored in history and can be referenced later.

Saltstack employes zeromq to send out messages. This means that it is infinitely scalable since the saltmaster is not opening up thousands of SSH sockets with minions. This is an important distinction to other tools such as capistrano, which are bound to fail during large deployments or when network connectivity is spotty. Plus, because of the jid system, you can keep track of what's running, what's failed, what's succeeded, and what's finished.


Saltstacks using simple RSA keypairs for authentication.


No juggling SSL certificates. Each host has a private and public key. Using these keys both the master and the minion can verify the identity of the other.


Saltstacks configs are stored in a readable yaml format


Unlike both Chef and Puppet -- which store configurations in a Rubyesque way -- configurations in Saltstack are yaml and very easy to read. You can also use simple yaml parsing programs to check the syntax of your configuration file.

Saltstack provides top-down execution order in configurations


This is something that drives a lot of people insane when using Puppet. Puppet manifests are executed in an declarative way that seems to just jump all around the manifest, so you end up writing dependencies for all sorts of executions. This leads to significant bloat of config files as well as some serious heartache when attempting to troubleshoot manifests. 

Salt configs on the other hand are wholly imperative and will execute from the top down in an SLS file. This helps greatly when porting over bash scripts. It also means you don't need to write requirements for any declaration.

Saltstack has a lively and active development community


Saltstack is the new kid on the block and is generating a lot of buzz. Unlike both Chef and Puppet, the salt community is lively and active. Mailing lists are busy and users on the irc channel are quick to offer help. This makes a huge difference when getting help.

Saltstack will not try and sell you hosting


This was something that always bugged me about Chef. There is no paid hosting with Saltstack. Everyone gets the same thing. The developers are not just trying to make a buck but are instead trying to create a great tool.

3 comments:

  1. Hey Stephen,

    Full disclosure upfront, I'm an Opscode Developer, and we make Chef (you likely already knew this, but you didn't mention Opscode directly in your post, just Chef).

    First, it's awesome you've discovered Saltstack and are loving it. Keep on doing awesome things with it. I certainly think Chef is awesome, but from what I've seen of Saltstack it looks awesome too and the team behind it seems awesome. There is more than enough room in this world for multiple configuration management tools to exist.

    You are right to point out that Chef and Puppet do have some community problems. I think Chef and Puppet do have actively and lively communities, but our problem (at least's Chef's anyway, I can't speak directly for Puppet) is that our community has gotten so large we as a company can't respond to every question, although we do try. If someone from the community doesn't fill in where we miss then people have questions unanswered or go unhelped and that's not a great experience. We recognize this and are trying to do better, but it sounds like Saltstack is doing great at this.

    I was hoping you could clarify your final comment, that you find Chef's hosting annoying. I've always thought of it as Opscode providing people another way to use Chef. I means that as a user you don't have to run a Chef sever yourself if you don't want to, but you get all the benefits of having a Chef server. Of course you always have the option of running the free open source version of Chef if you so choose. I've never heard anyone express this sentiment, so I'm just trying to understand it better.

    Thanks for clarifying that for me and keep on doing awesome things with Saltstack.

    - Mark Mzyk

    ReplyDelete
    Replies
    1. Hey Mark,

      I'm really happy and honored to hear from you! First of all, I don't think my little blog post deserved as much attention as it got. My background is in Bash and Puppet for my bootstrapping and deployments. After two weeks getting my hands dirty with Saltstack I got really excited and published this piece.

      That aside, I actually don't have much in terms of complaints with Chef. Documentation-wise there is a lot out there for Chef (and Puppet), which is unfortunately part of the problem. It's become difficult to sift through the volume of information to find clear examples. I acknowledge that this is a personal anecdote and I believe this has more to do with the age of a project than any other factor.

      As for enterprise hosting, this is certainly just an area of personal opinion. I wanted the additional services provided in enterprise hosting but it would have been prohibitively expensive for us at our scale if it's $600 per 100 nodes. I'm sure there are discounts and other things we could have worked out, but the pricing told me this was probably not the project for us. This coupled with the fact that there were features we may never get made it so Chef was relegated to the back of the line, maybe unfairly.

      Now all that being said, I have the least experience with Chef and I'm still very curious about it. We're still in the decision making process over at Moz and we're just a few blocks down from Opscode! I'd like to invite you to come over to the Mozplex and let us treat you to lunch. Maybe we can trade office tours. We're on 2nd and Pine. Please email me at stephen@moz.com!

      If you would like to add any sort of rebuttal to my post I'd be happy to edit and include it. Thanks again for stopping by.

      Delete
    2. No need to downplay the traffic this post has gotten. You voiced your opinion and people wanted to hear it. That's awesome.

      Totally understandable on pricing, by the way. If it's expensive for you it's expensive for you. I don't know your use case, but it sounds like open source is the way to go. As far as feature sets, open source Chef is the same technology as every other version of Chef. What you would be running is the same thing our large customer's run. That being said, we do have a few add ons that currently aren't in open source, so I get the trepidation. Anything we don't open source we consider add ons. If it is something needed to make Chef work, it goes into the open source and we believe in contributing as much to open source as possible.

      Still, there are features like reporting that are going into the enterprise option first while we figure out what it looks like to open source something like that. I get that can be a turn off for some people and I also know that Saltstack has officially opted not to go this model.

      Mostly I'm just trying to clarify Opscode's position on this so it's clear. We currently in active development on these features, so even we don't exactly know what things are going to look like when we release them. That said, would we ever go the Oracle route and release a performance upgrade that doesn't go into the open source product? Absolutely not.

      Maybe that helps, maybe that doesn't. Still, evaluate for yourself and decide what is best for you.

      No need for a rebuttal. This is your blog and it should be your opinion, not mine.

      As far as lunch, that sounds awesome. I'll let you know the next time I'm in Seattle, since I actually live in Raleigh. :)

      Delete