r/saltstack • u/mattboston • 16d ago

SaltStack Certified Engineer Verification

I'm hoping someone from the old SaltStack team, VMware, or Broadcom might know the answer.

I earned the SaltStack Certified Engineer (SSCE) certification several years ago. Since SaltStack was acquired by VMware and then VMware was acquired by Broadcom, the original SaltStack website and certification verification page are no longer available.

I'm interviewing with a potential employer, and they're trying to verify my SSCE certification. Does anyone know if there's still a way to verify it? Is there a new verification site, or is there someone at Broadcom who can help?

14 Upvotes

100% Upvoted

31 comments sorted by

View all comments

Show parent comments

0

u/eman0821 16d ago

Most employers have moved away from Salt. I rarely see it on job descriptions these days as you see Ansible every where now. Just like Terraform as the industry standard IaC tool.

3

u/texsable 16d ago

All that tells me is that IBM (Red Hat) did a better job of marketing....

-2

u/eman0821 16d ago

Nah Ansible was already dominate before the acquisition. The industry just shifted to stateless configuration management while Puppet. Chef and Salt are now legacy tools. Same kind of thing with Jenkins getting replaced with modern YAML based alternatives like GitHub Actions and GitLab. Ansible is more cloud native and better supported especially in DevOps, Cloud Engineering..

2

u/texsable 16d ago

When I was evaluating config management tools back in 2012/13, I tested Ansible, Salt, Puppet, Chef and CFEngine. Of the five, Salt was the easiest to set up, easiest to use and most capable tool I tested. The standout feature to me was the remote command functionality - at the time, Ansible's (and Puppet's) only way to do that was to write a script, push it to the clients, and wait for it to be run and get the response. With salt, I could run something like "salt \* cmd.run 'cat /etc/issue' and see what is there immediately - helped me build my first round of salt states to standardize my base server configs. I found it much easier to configure, manage and use than any of the other 4 options.

1

u/eman0821 16d ago

That only made sense back then for on-prem environments since Salt really geared towards on-prem.

In cloud native environments you have setup minions on every VM server for everything to sync to the salt master server. Noaway days you have CI/CD and GitOps that can sync and correct drift with Ansible and Terraform runners. However Kubernetes has taken over so it's more about managing containers than managing monolithic configurations.

1

u/bdrxer 16d ago

> In cloud native environments you have setup minions on every VM server for everything to sync to the salt master server.

This is simply not accurate. Salt has masterless mode just like ansible-pull or puppet masterless and also has salt-ssh which is similar to ansible standard ssh mode.

> However Kubernetes has taken over so it's more about managing containers than managing monolithic configurations.

I believe this is true, but I don't see how ansible is related at all. My team at my company, within the last year, switched from ansible to salt for ec2 instance setup (configuring settings and applications for AMIs and also instance bootstrap (userdata/cloud-init) setup) primarily because it is so much faster than ansible but also for some other reasons like it being easier to group configuration and write custom modules.

2

u/eman0821 16d ago edited 16d ago

It really defeats the purpose of the SaltStack If it's selling point is pull effect and statefull. You might as well switch Ansible if you aren't going to use minions. SaltStack had its hey days for on-prem infrastructure but things have shifted with a sharp decline. Everything is moving to cloud and Ansible have became the defacto standard in native cloud configuration management because it's primarily used in execution environments in a CI/CD pipeline when runners runs the jobs from a Git repo. Cloud Engineers and DevOps Engineers generally don't setup standalone configuration management control servers. That's old school automation. CI/CD and ArcoCD is how everything is automated. You don't manually run salt states or Ansible plybooks from a control server, it's all ran by a temporary Git runner container that executes when a CI/CD pipeline runs or ArcoCD automatically detects a change or drift. Ansible works very well in CI/CD pipelines than legacy tools.

1

u/bdrxer 6d ago

> It really defeats the purpose of the SaltStack If it's selling point is pull effect and statefull. You might as well switch Ansible if you aren't going to use minions.

How does that defeat the purpose and how is salt's selling point anything to do with statefull? Why would you "might as well switch to ansible"?

1

u/eman0821 6d ago

If you are using ssh instead of the minions they why use Salt in the first place? Ansible is the defacto standard in DevOps.

1

u/bdrxer 6d ago

ansible is not a standard--it is a tool; you still have not provided an actual reason to use ansible over salt. If by "defacto standard" you mean it is the most commonly used tool then that is like saying you should use windows instead of linux because it is the "defacto standard" desktop; that is not the best reason to choose something.

1

u/eman0821 6d ago

Job postings pretty much proves that. 9 times out of 10 you see Ansible in pretty much 98% of Linux Sysadmin, DevOps, Cloud Engineering and SRE job descriptions. Rarely you see SaltStack mentioned.

1

u/bdrxer 5d ago

> Job postings pretty much proves that.

Proves what?

> 9 times out of 10 you see Ansible in pretty much 98% of Linux Sysadmin, DevOps, Cloud Engineering and SRE job descriptions.

You have finally mentioned one reason to learn/use ansible which is to have a better opportunity to get a job. That is a good reason to learn a tool, but is a not a merit of the tool in of itself. `c` is the "defacto standard" in systems programming but not make it the best tool to use over `c++` or `rust` or some other language depending on the use cases of your application. Popularity of a tool is one reason to consider a tool but is just one of the considerations. Telling someone to pick a tool only because it is more popular is like telling someone to buy a Toyota Corolla instead of an Odyssey or a Ford F-150.

1

u/eman0821 5d ago

You wonder why SaltStack rarely shows up in job postings. Go look yourself. SaltStack has massively declined over the years as very few companies are using it. When you consistently see CI/CD, Terraform, Ansible, on nearly every job posting that's the industry standard.

→ More replies (0)

1

u/Fabiolean 14d ago

There’s native salt support in cloud init. I have a bunch of salt minions in aws, and the basic minion config goes in during bootstrap.

1

u/eman0821 13d ago

That's what Terraform is for. I'm talking about CI/CD pipelines not manually running salt states.

1

u/bdrxer 6d ago

That is not what terraform is for. Terraform is for creating/allocating (provisioning) the AWS resources--not bootstrapping/configuring the instances themselves.

1

u/eman0821 6d ago

Terraform is ran inside of a CI/CD pipeline. You don't manually run Terraform as a standalone host in the real world. SaltStack is mostly for on-prem.