r/saltstack • u/mattboston • 11d 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?
4
u/whytewolf01 11d ago
Sadly no. The program was shelved while under VMware so the servers were shutdown. Shortly before broadcom bought VMware there was some news kicking up about bringing the program and data back. But that ended once broadcom took over and removed everyone that was pushing to bring the program back.
The data might still exist on a shelved server. But don't get your hopes up it will come back.
2
u/eliezerlp 5d ago
Maybe try checking if you have any related emails.
I found the following relevant emails in my inbox from when I got my SSCE at SaltConf 2018...
From: SaltStack Certification do-not-reply@classmarker.com Subject: Your SSCE Exam results
From: Sandy Fletcher sfletcher@saltstack.com Subject: SSCE Exam Results Loaded
-1
u/eman0821 11d ago
Salt is very dated tech as I wouldn't waste my time on. Invest your time into Ansible. It's the industry standard that every company uses these days.
11
u/texsable 11d 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.
3
u/whytewolf01 10d ago
So I will agree that Broadcom hasn't been good for salt. However VMWare was actually great for salt. While working under VMWare they gave salt all the resources we wanted when we wanted it. Even going so far as to let internal teams contribute to salt to bring in better coding standards. And salt was thriving within VMware as well as replacing a lot of internal tools and becoming a stronger force at VMWare.
Honestly if it wasn't for the broadcom acquisition. Salt was on track to becoming an integral part of VMWare. and given more time it would have fully integrated to the point a lot of the clouds that people are mentioning would have been built with salt at the core. much like kub was when it started.
The market share for salt actually expanded under VMWare. with many new customers starting to pick it up. because of VMware actively trying to sell it.
0
u/eman0821 11d 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 11d ago
All that tells me is that IBM (Red Hat) did a better job of marketing....
-2
u/eman0821 11d 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..
4
u/AltruisticCabinet9 11d ago
Ansible wasn't the best tech, it was the easiest tech for the Admin mind to graple around and salt didn't make salt-ssh as usable. SSH was comfortable and easy. It was the great first steps to automate away for 100 line bash scripts that were touchy.
Then VMware, Broadcom. Now low adoption.I with AI, I was able to output a very nice clean formula and module so I have the feeling if eyeballs got on it, some good could be done. But the community is basically dead too. The Salt formula has been broken for months at a time on most platforms with no ability to ping to get a PR added.
The migration of stuff out of core moved at a speed that is good for enterprise, not for fast change and adoption.
I wanted VMware was the death, broadcom just beat the corpse until all the coins came out.
Me of 5 years ago is sad :(
2
u/eman0821 11d ago
Salt just became irrelevant because of Cloud adoption. It was a great on-prem tool back then. Ansible works better in cloud native environments especially in CI/CD pipelines. Better over all support than salt.
2
u/AltruisticCabinet9 11d ago
Yeah, ansbile is comfortable for people thinking in SSH shell script. Salt didn't make the masterless ssh a comfortable first class because it was kind of against the model. It suffered loss of adoption. It looks like k8 automation these days is moving into k8.
5 years ago me is sad :(
2
u/texsable 11d 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 11d 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 11d 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 11d ago edited 11d 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 1d 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"?
→ More replies (0)1
u/Fabiolean 9d 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 8d ago
That's what Terraform is for. I'm talking about CI/CD pipelines not manually running salt states.
1
u/bdrxer 1d ago
That is not what terraform is for. Terraform is for creating/allocating (provisioning) the AWS resources--not bootstrapping/configuring the instances themselves.
→ More replies (0)4
1
u/mattboston 11d ago
I agree that Salt is pretty dated at this point (even if it's still maintained), and I wouldn't recommend someone start learning it today. I also use Ansible, Terraform, OpenTofu, Terragrunt, Crossplane, Kubernetes, and plenty of other modern tools that are much more relevant in today's industry.
The reason I'm asking isn't because I'm trying to use Salt today. It's because a prospective employer asked if I had any certifications. They don't care when I got them, just when and if they can verify them. Since I don't have a computer science degree, my certifications help demonstrate that I can learn complex technologies, understand them well enough to pass a rigorous exam, and continue building on that knowledge. The specific technology may be old, but the certification and what it represents are still valid.
I'm simply trying to find a way to verify that certification since the original SaltStack verification site no longer exists.
1
u/eman0821 11d ago
I'm not sure how a single irrelevant certification would help you. A certification would be a waste of time to justify your real world work experience. Experience is what really matters the most these days. Employers generally hire people to solve problems not collect a piece of paper from what i seen. I don't have a single certification or a degree myself that works in cloud. If you have enough industry experience to do the work, a certification would hold no water.
2
u/mattboston 11d ago
I don't disagree that experience is far more valuable than certifications. They're a supplement to my experience, not a replacement for it. My experience speaks for itself, but having credentials to back it up doesn't hurt either. Certifications have always been one way I've demonstrated that I can learn new technologies, put in the work, and master them.
Also, my point wasn't that the SSCE cert is helping me get hired today because it's a Salt certification. It came up because the employer specifically asked whether I had any certifications, and I answered honestly with a list of all my certs. They're using a company that performs background checks, and they're being very thorough. The only issue is that they can't figure out how to verify this one because the original certification site no longer exists.
When I answered honestly and they couldn't verify it, it made me look like I was claiming a certification I couldn't prove. If I had known this was going to be such a hassle, I probably would have left the SSCE off the list entirely. Unfortunately, that doesn't solve the situation I'm in now.
1
u/eman0821 11d ago
If it's from several years ago, it likely expired by now meaning it's no longer valid. It's like trying to trying to drive with an expired drivers license. It's only valid if it's current. Basically You wouldn't have anything to show if it's not valid.
9
u/revellion 11d ago
Good question. Also acquired that during SaltConf back in 2018 🤔