Chosing salt over chef

[Erik Parienty]

My company what to implement chef.

i am new in this job with more then 2 years experience in salt

what should i tell them to chose salt :-)

[Florian Ermisch]

Hi Erik,

a few ones based on what they're built on:
* Is the company using more Python or more
Ruby? There are many OS tools (like yum)
written in Python, I don't know of Ruby ones.
* Do you have to deal with python-based
projects like OpenStack?
* Do you have to configure networking gear?
From what I hear on packetpushers.net the
network folks are all in on python. And we
got NAPALM nowadays.

Regards, Florian

[Erik Parienty]

Thanks

1.  The company not using python or ruby

2.  No, all on AWS

3.  No physical infrastructure

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/ZwcQ67hXK1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/BD97CAF9-D9AF-426E-94C3-74603113D6C8%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.

[Rémy Dernat]

Hi,

I do not know Chef, but the best approach would be to code a recipe (something difficult which implies many different things) with salt and doing the same with Chef to be able to compare both solutions.

Secondly, Chef is ruby, Salt is Python, so you should also look at present skills in your new company...

Then, I think - and maybe I am wrong -, SaltStack has very powerful features, like reactor/orchestrator, external pillars, gitfs, multi-master mode, etc... Generally, those features are not entirely covered by others management system. Indeed, I know that Ansible is not as flexible as SaltStack; eg if you need to get collect datas from minions, you need to use some sort of grains (facts) while you can do it with mine, reactors, grains on Salt.

Another point to look at : performances. SaltStack is known for scaling well.

Finally, google it : 

https://www.upguard.com/articles/salt-vs-chef

http://www.intigua.com/blog/puppet-vs.-chef-vs.-ansible-vs.-saltstack

http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/

Perhaps someone who tested both can provide a better answer.

Best regards,

Rémy

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/47edda2f-a716-4ddc-9c77-357d8f532cb0%40googlegroups.com.

[mike r]

I wrote up a comparison between diff config mgmt tools, although doesnt include Chef since I never worked with it, but it does include Puppet which is ruby-centric like Chef,

https://mrxpalmeiras.wordpress.com/2016/10/06/my-big-ass-verbose-and-overly-complicated-puppet-saltstack-ansible-review/

[Dimitri Maziuk]

When they run into problems with chef you can tell them "I told you so".

When they run into problems with salt they'll tell you "you're fired".

HTH
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu

[Ryan Lane]

You and another person should each do a proof of concept (one salt, one chef). At the end, show why you think your solution is better, have everyone take a look over the code, and compare things that matter to your team. Is one considerably faster? Is one more readable? Is one buggier than the other?

If you do this, you need to be willing to own salt for the next 6 months from the perspective of answering questions, training people, implementing good patterns, etc.

--

[Florian Ermisch]

Am 13. Juni 2017 19:16:48 MESZ schrieb Dimitri Maziuk <dma...@bmrb.wisc.edu>:
> On 06/13/2017 04:06 AM, Erik Parienty wrote:
> > My company what to implement chef.
> > i am new in this job with more then 2 years experience in salt
> > what should i tell them to chose salt :-)
>
> When they run into problems with
> chef you can tell them "I told you
> so".
>
> When they run into problems with
> salt they'll tell you "you're fired".
>
> HTH

Wow, sounds like someone got fired
for putting the wrong wallpaper on
their boss's new laptop…

Even if he had to reimplement everything
with chef in the end he still knows their
company and its infrastructure already
and has general experience with config
management.

Regards, Florian

[Dmitri Maziuk]

On 2017-06-14 02:50, Florian Ermisch wrote:

> Wow, sounds like someone got fired
> for putting the wrong wallpaper on
> their boss's new laptop…

Just old and cynical.

Seriously, it's a kindergarden question: what you tell them is "I have 2
year experience with salt and no experience with puppet. I can get you
up and running faster on salt". If they reply with "no we want you to
learn puppet" you say "yes sir".

Dima

[Mike Freitas]

I had the opposite situation. We were using puppet in a limited manner and we needed to put some structure and organization into the solution. I had started looking into Salt prior to this so i used that as an opportunity to investigate whether changing is worth it since we probably needed to re-implement puppet, including migrating to 4.x. Here are the main points that won the argument and ended up with a Salt solution:

• Only a few people knew puppet, and none were experts
• I have python experience
• Some people had Ansible experience so the syntax is at least "Familiar"
• Salt open has a much better feature set included for free
• Orchestration
• Event System
• REST API
• Scalability
• Better Community

As others mentioned, a small POC is very helpful. If there is something already implemented in Chef, redo it with Salt and compare. Hope this helps.

Mike

On Tuesday, June 13, 2017 at 5:06:03 AM UTC-4, Erik Parienty wrote:

[C. R. Oldham]

Full disclosure--I do work for SaltStack.

That being said, we have MANY internal anecdotal stories from our sales engineers that talk about Puppet installs taking months and months to get right.  Implementing the same functionality with Salt, however, was done in just a few weeks.

(</shamelessplug>)

--cro

C. R. Oldham

Senior Platform Engineer, SaltStack

c...@saltstack.com / 801-564-4673

--

You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/f6e3b972-2f29-4065-96bd-1ca1219e219e%40googlegroups.com.

[Joel Whitehouse]

On 06/14/2017 11:32 AM, C. R. Oldham wrote:
> Full disclosure--I do work for SaltStack.
>
> That being said, we have MANY internal anecdotal stories from our sales
> engineers that talk about Puppet installs taking months and months to
> get right. Implementing the same functionality with Salt, however, was
> done in just a few weeks.
>
> (</shamelessplug>)
>

> */--cro/*

> C. R. Oldham
> Senior Platform Engineer, SaltStack

> c...@saltstack.com <mailto:c...@saltstack.com> / 801-564-4673
>


TL;DR:

I was sold on using Chef and began learning it so I could demo it. Part
way through, I discovered salt and gave it a quick spin. Salt was so
simple to use that I had it integrated into my production process before
I had even finished learning Chef.




In 2013, the simple bash scripts that I'd been using to configure
servers and appliances for production had become unwieldy. I saw a
mention of "puppet" as a "configuration management" tool so I started
investigating!

After an hour of reading, puppet seemed obtuse and somewhat crufty.
Design issues such as non-deterministic order of operations seemed to
cause trouble. I knew I could work around that particular issue, but I
wanted to explore some alternatives.

The CFEngine website was more concerned with talking about "Promise
Theory" than helping me get a hello world working, so I moved on.

Then I found Chef. Opscode had persuasive marketing -- chef improves
upon some of the design issues with puppet, and after hours of reading
and watching Conference presentations about "Using Chef in Production",
"Chef at Facebook", on youtube etc, I was sold!

I started planning my own Chef deployment. The omnibus installed helped
me get the chef server setup in a VM. I just need to learn resources,
recipes, cookbooks. Simple enough. Conference talks recommended
planning a cookbook versioning scheme, using berkshelf for cookbook
management, perhaps vagrant for testing. Then I needed to run the
omnibus installer on a couple target VMs. Next, I needed to learn some
"knife" commands.


Somehow, in the middle of evaluating Chef, I came across a youtube video
of Thomas Hatch presenting his creation, "salt". As he explained the
problem domain, his initial requirements (speed, security, parallelism)
and the architecture of his solution, I changed my mind about chef.

After two weeks with chef and I had put together a reasonable hello
world. But I'd grown tired of the half-baked (sorry) skeuomorphic
naming convention. I had learned so many primitives and after all that
time, still hadn't quite grokked how to be creative with all of them.

By contrast, the primitives in salt were so simple. Within an hour, I'd
learned how to use modules and states. With a single VM and masterless
mode, file.managed, cmd.run, and pkg.installed, I converted a few bash
scripts into salt states within an afternoon. At first, I didn't even
need grains, pillar -- or a master.

Within another week, I was using salt to configure real deliverables.
It was so much easier to maintain than using bash, and so much easier to
understand than chef had been. Also and is engineered well -- there
have been no "non-deterministic order of operations" flaws like had
plagued puppet historically.


If you want salt to win against chef, I would choose a part of your
infrastructure to tame and compare them with a quick demo. Documenting
the process will provide a lot of information to draw on while making
your case to management.

-Joel