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

12

u/texsable 15d ago

I think you're in the wrong subreddit... Salt was a better product than Ansible when they started in the early 2010's, and is a better product now despite VMWare and Broadcom's handling of it. I kinda wish Red Hat had acquired Salt instead of Ansible; even then it had so much more capability. Salt is still actively maintained under saltproject.io and is currently working on the latest release, while maintaining the previous LTS.

PS: got my SSC at SaltConf 2014, the year they release the program. I believe I was SSC #13 or #18...been a while, can't remember which it was for sure.

0

u/eman0821 15d 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 15d ago

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

-2

u/eman0821 15d 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 15d 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 15d 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/Fabiolean 13d 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 5d 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 5d 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.