Opinions: Ansible vs. SaltStack
-
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
-
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
-
@Romo said in Opinions: Ansible vs. SaltStack:
Tactical RMM - Targetted as an RMM for Windows, includes Mesh Central, saltstack, a custom python agent, Django backend, Vue frontend.
That's the one that I was thinking of.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
Ha! Just saw it this AM. Does this give you any concern with the future of the open source version of Salt?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
Ha! Just saw it this AM. Does this give you any concern with the future of the open source version of Salt?
No, VMware has little interest in upsetting the balance of things. This kind of tool is already universally open source. Closed source only makes sense when you can dominate the field until some open source option takes over. Open source already owns this field.
Close sourcing an existing product is very hard to do, because you risk that someone else will fork it and keep it open and make your version irrelevant leaving you with literally nothing for the money that you spent.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
Ha! Just saw it this AM. Does this give you any concern with the future of the open source version of Salt?
No, VMware has little interest in upsetting the balance of things. This kind of tool is already universally open source. Closed source only makes sense when you can dominate the field until some open source option takes over. Open source already owns this field.
Close sourcing an existing product is very hard to do, because you risk that someone else will fork it and keep it open and make your version irrelevant leaving you with literally nothing for the money that you spent.
Makes sense. From yesterday: With Salt, on your salt master, do you rely on the keys for authentication, or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
Makes sense. From yesterday: With Salt, on your salt master, do you rely on the keys for authentication,
Yes, that's standard.
-
@AdamF said in Opinions: Ansible vs. SaltStack:
or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
No, this would make the agents pointless. Because they'd be unable to obtain a new address and keep working. This wouldn't just make mobile points not work, it would make any site without static IPs a problem, which is almost all of them today.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
No, this would make the agents pointless. Because they'd be unable to obtain a new address and keep working. This wouldn't just make mobile points not work, it would make any site without static IPs a problem, which is almost all of them today.
So the only reason I brought this up, is because of a big vulnerability with SS a few months back. (https://www.helpnetsecurity.com/2020/05/04/saltstack-salt-vulnerabilities/) Specifically the section in the article that states:
“Adding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider Internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks,” the researchers added.Now of course, an up to date master avoided this altogether, but still.
-
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
No, this would make the agents pointless. Because they'd be unable to obtain a new address and keep working. This wouldn't just make mobile points not work, it would make any site without static IPs a problem, which is almost all of them today.
So the only reason I brought this up, is because of a big vulnerability with SS a few months back. (https://www.helpnetsecurity.com/2020/05/04/saltstack-salt-vulnerabilities/) Specifically the section in the article that states:
“Adding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider Internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks,” the researchers added.Now of course, an up to date master avoided this altogether, but still.
Yup, it's a risk for sure. As long as you connect servers to clients, somewhere there has to be a point of exposure, and that's a risk.
-
What would be the sense of purchasing a solid open source project like SaltStack?
Being OS, VMware can add their own developers to the project and still integrate it with their products without the cost of purchasing the company. -
@pmoncho said in Opinions: Ansible vs. SaltStack:
What would be the sense of purchasing a solid open source project like SaltStack?
Being OS, VMware can add their own developers to the project and still integrate it with their products without the cost of purchasing the company.Control of commits is the primary one. Marketing is the second. And often, but it depends on the project, ability to have a closed source copy used somewhere.
As a software company, it's super common that you maintain a closed source secondary license so that you, as the owners, are not bound to the open source limitations or requirements that other people are. No idea if VMware is going to do this, or if they can (there are licensing factors in the past that determine this), but it's a possible reason.
A fourth reason is general guidance of the project. You want to ensure quality, determine how it progresses, make sure your own platforms are always a priority, owning it is the best way.
Fifth, keeping it from falling into someone else's control. Remember IBM did this with Ansible, too. So there is a trend.
And sixth... revenue. SS brings in money, and you can make way more money as the actual project than as someone who just supports a project. If the later worked just as well, I'd make as much money as IBM does supporting Linux, but owning Red Hat gives them a slight edge
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
Fifth, keeping it from falling into someone else's control.
Java, MySQL
-
@JaredBusch said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
Fifth, keeping it from falling into someone else's control.
Java, MySQL
Good examples.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@pmoncho said in Opinions: Ansible vs. SaltStack:
What would be the sense of purchasing a solid open source project like SaltStack?
Being OS, VMware can add their own developers to the project and still integrate it with their products without the cost of purchasing the company.Control of commits is the primary one. Marketing is the second. And often, but it depends on the project, ability to have a closed source copy used somewhere.
As a software company, it's super common that you maintain a closed source secondary license so that you, as the owners, are not bound to the open source limitations or requirements that other people are. No idea if VMware is going to do this, or if they can (there are licensing factors in the past that determine this), but it's a possible reason.
This was my original thought of why but then I figured, if they want to close source it, someone could just fork the latest version and then most will then migrate to the open source version.
Fifth, keeping it from falling into someone else's control. Remember IBM did this with Ansible, too. So there is a trend.
Makes sense. I guess the last thing one would want is for a competitor to buy a product deeply ingrained in your own software.
And sixth... revenue. SS brings in money, and you can make way more money as the actual project than as someone who just supports a project. If the later worked just as well, I'd make as much money as IBM does supporting Linux, but owning Red Hat gives them a slight edge
I didn't think there would be much SS revenue from a product like SaltStack or similar apps. Apparently I don't see all the power of SaltStack itself.
-
@JaredBusch said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
Fifth, keeping it from falling into someone else's control.
Java, MySQL
I never really understood the Java purchase as, it seemed, more people complained about it than liked it. MySQL, OTOH, made much more sense because it is at the heart of data, thus giving the software much more importance and the need for immediate support services.
-
@pmoncho said in Opinions: Ansible vs. SaltStack:
I never really understood the Java purchase as, it seemed, more people complained about it than liked it.
Well, Java itself wasn't purchased. Oracle bought Sun and Java was part of Sun. Oracle also got Solaris, Sparc and tons of other products. Java was a big piece of that, but it wasn't a "Java deal" in any way, Java was not and is not a significant monetary component of the Sun ecosystem.
That people didn't like a great company like Sun being purchased by a crappy company like Oracle was really just about Oracle - they are total garbage and no one wants them to purchase anything good. But if Oracle did what people wanted, they'd just go out of business and vanish.
-
@pmoncho said in Opinions: Ansible vs. SaltStack:
MySQL, OTOH, made much more sense because it is at the heart of data, thus giving the software much more importance and the need for immediate support services.
Was there ever any lack of immediate support? We always had support access prior to Oracle buying them, and still do with MariaDB. Oracle support isn't that great (not bad, just nothing amazing), so I'm not sure that there was any benefit there.
-
MySQL is a good example of how open source can protect against purchase from a bad company (and why VMware would be scared to burn their bridges with SaltStack.) Oracle took MySQL closed (partially) and MariaDB forked from them. Now, MariaDB is the leader and MySQL is a forgotten vestige for the most part. The term MySQL is used to almost always refer to MariaDB, to the point that most people don't even know what they have.
MariaDB is faster and more advanced, has the core original developers, better licensing, and more industry support. MySQL support is almost completely limited to Oracle, who doesn't have the core dev team working with them and has no quality products of their own. MariaDB has support directly from the devs, as well as from actually good software companies like IBM and Canonical. So better tech (features AND speed), better pricing, better licensing, better support. MariaDB has wiped the floor with MySQL.
I wonder if Oracle makes enough from MySQL sales to cover the cost of having purchased it.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@pmoncho said in Opinions: Ansible vs. SaltStack:
MySQL, OTOH, made much more sense because it is at the heart of data, thus giving the software much more importance and the need for immediate support services.
Was there ever any lack of immediate support? We always had support access prior to Oracle buying them, and still do with MariaDB. Oracle support isn't that great (not bad, just nothing amazing), so I'm not sure that there was any benefit there.
There may not have been a lack of support, but more of a sense of stability for the future. Maybe some developers who were on the fence about using the product went full in knowing a large company can continue to supply support for the product well into the future.
