- Extensibility and flexibility
- Open source
- Active community
Also, the text-based configuration is very important to discern differences in version control. It also means it is easily configured with templates, and easily edited.
Also, the text-based configuration is very important to discern differences in version control. It also means it is easily configured with templates, and easily edited.
Salt lets you run commands on hundreds of servers at once; and sync up software, tools, and scripts across your infrastructure.
The flexibility can hurt sometimes, as there are so many ways to accomplish the same task. I don’t want to give the wrong impression; the flexibility helps more often than it hurts. However, when there are multiple choices to a complex software problem, one can make mistakes, and with a configuration management system, a mistake can get pushed to an entire infrastructure automatically.
I have used it for one year.
Salt has been remarkably stable, and it is simple to send metrics to an external source like Elasticsearch.
I haven’t had any scaling issues.
I would rate technical support very high. Personally, I have posted issues to GitHub that have been responded to the same day or the next day, and closed within a week.
This was our first foray into the configuration management space. Previously, it was a bunch of PowerShell scripts.
Salt has a very straightforward installation.
Salt is free.
Before choosing this product, we were looking at PowerShell DSC, because we were all PowerShell anyway. It was too unpolished; did not seem to fit properly with what we had in mind.
Have a good plan about how you are going to target your infrastructure; a solid naming convention helps a lot.
Multi-vendor cloud IT infrastructure personalization, resource provisioning and configuration, and it automates application delivery and container management.
It provide us a common console to manage workloads on our private and public cloud infrastructures.
Better integration with Azure cloud and Google Cloud Platform.
Two years.
vRA 7.2 onwards is quite a stable product.
New versions are quite scalable, but when it comes to managing a Telco environment, it has bottleneck.
A nine out of 10.
We have been using the older version (VMware vRealize Automation Center).
It's a quite straightforward setup in comparison with products in the same domain.
It's worth each penny.
No, we have been using VMware suite for a long time and we are pretty much comfortable with it.
Go for it. It's a perfect product of a heterogeneous environment.
The most valuable asset is most probably the ability to target the needed hosts, and running commands via modules or a shell on all of them at the same time. This means that mass parallel administration of large server farms is possible.
I am now able to rollout critical updates within seconds on all affected servers, and it doesn't matter if there are five or 500 of them.
So far, everything worked as expected. This means that so far, I heavn't seen anything which needs improvements. The software works as expected and I stumbled across no issues while using it.
Self-service and automation. They reduce the amount of time to build a virtual machine and reduce the operation costs.
The requesters create their own virtual machines now, instead of a series of tickets to get things built.
We're still running version 6. When we upgrade to version 7, a lot of our issues should be addressed already. Things like some of the flexibility, and some of the ease of automation.
It's very stable.
It's extremely scalable.
Since we moved to Business Critical Support, it's been very good. I always reach the right person.
We needed a self-provisioning front end. So, this was the best option.
Complex. We deployed the original version of vCAC and there wasn't a lot of documentation at the time. There are a lot of disparate parts that have to be deployed on multiple machines that involve a bunch of load bouncers. Issues like that.
We purchased PSO resources.
Licensing's expensive.
VM was the only one we really looked at.
The most important criteria when looking at various vendors are reliability, their position within the industry, and the ability to get references from existing customers.
Do a lot of planning upfront because some of the choices you make, when you initially deploy, you'll have to live with in the end. Sizing is the main one.
I would suggest hiring a PSO.
Our group, we do mostly the virtualization and a creation of systems. Therefore, it's not a cookie cutter build of a template, and that's it, it's more dynamic for our group.
It's increased the efficiency. There's less manual work through vRA. Now, Orchestrator is the one doing most of the work and making everything more automated.
I would like to see this additional features in the next release: The ability to have more dynamic forms. Some of the static forms that vRA provides in the XaaS form, they are good, but they could be a little more efficient. For instance, the calendar selections should have the ability to only go to a certain spot, as opposed to going out to something like 2040, for the requests.
Stability is really good. Once you got everything setup, even in its HA form, it's pretty stable.
Not as good, but there are some components in vRA that you can scale out a lot more quickly than other pieces.
In our group, more of the web solutions and the blog posts helped to grow our ability to use vRA.
Technical Support:They are always reachable by person and knowledgeable.
But because it's such a dynamic solution, at times VMware does have to go gather more resources in order to figure out the solution to things.
We had a previous VMware product called Lab Manager, then we had grown out of that box and decided to go with vRA.
I was involved in the setup. In the original version 5, it was very complex. Version 6 got a little better. Version 7 is much more improved.
In the first deployment, they sent an in-house team.
Microsoft.
Advice for looking at VM solutions:
Definitely research the product and see what's out there.
Look at blog posts of vRA. There's quite a few resources that you can search and find on the web which will basically get you on the ground running for deployment, even simply XaaS forms.
Most important criteria when selecting a vendor:
For a few years, when we needed a server, it took us three months to deliver one. Now, we can bring one up in approximately 15 minutes.
Our delivery is now very fast.
It's very stable.
We're satisfied with the scalability of the solution.
They are very good. We have an account manager. We use the account manager, if necessary, and have with a relationship with them, so they can respond very quickly.
If you are looking to implement the product, do it together with VMware. It was a good experience for us.
We have used this solution for under three years.
With the correct infrastructure design, stability issues probably won’t occur. SaltStack supports several features for high availability and fault tolerance.
In terms of SaltStack code/bug issues, it is a very stable product after four years of development from 12,000 developers.
I did not encounter any issues with scalability.
SaltStack is a very straightforward system with very good documentation. There are different solutions for deployments. Many scenarios and best practices are available publicly on the SaltStack site.
We evaluated Ansible and Puppet. SaltStack provided a much more robust solution.
The most valuable feature of the product is the automation for services; it’s the basis of my work. It is important because nowadays, in this complex world, services have become the base for everything. Having a large base is needed to better build what you need for your pipelines, as opposed to a few years ago, when the application was king.
We created pipelines for all our products.
The base library is missing some key elements such as networking management (mine is lacking on that front) and some more granularity on the apt part.
I have used it for 12 months.
I have not encountered any stability issues so far.
I have not encountered any scalability issues so far.
Technical support is just about right, in the sense that the product is well documented and information is easy to find.
We previously used Puppet, which was not suited for my current workload. We chose SaltStack because Ruby wasn't the language used by my team and we needed a master-client solution as opposed to a master-less one.
Initial setup was very easy.
Pricing and licensing is perfect the way it is.
Before choosing this product, we also evaluated CFEngine.
Read the docs.
Something on the lines of a better management for the "smart" way ubuntu names the interfaces would be nice.
Some more base states for mangling iptables would be good as well