What is our primary use case?
It's for deployment and configuration automation.
How has it helped my organization?
It streamlined our deployments and system configurations across the board rather than have us use multiple configurations or tools, basically a one stop shop.
You set it and forget it. You don't have to worry about the reliability or the deviations from any of the other configurations.
What is most valuable?
Its versatility is the most valuable feature. It's not necessarily the end all or be all solution for configuration management, deployment, etc. However, for what we use it for, it fits right in and it doesn't bloat our infrastructure (or any of our instances) that we deployed to.
What needs improvement?
The compatibility with the different platforms that we are using needs improvement. We are mainly a Linux shop, but for a lot of ancillary Windows services that we were bringing in from vendors of third-party customers and things that we are using for the supply chain that we were running, Chef did not necessarily fit across the board for what we are doing there. In-house, the product has been pretty functional for us.
I would like them to add database specific items, configuration items, and migration tools. Not necessarily on the builder side or the actual setup of the system, but more of a migration package for your different database sets, such as MongoDB, your extenders, etc. I want to see how that would function with a transition out to AWS for Aurora services and any of the RDBMS packages. If there was something that was automated rather than through the package of the database system itself, this might aid us for a lot of DR stuff, resiliency, multi-region, etc. Especially when consolidating from a lot of on-premise stuff to cloud services, this functionality might improve our rate of deployment.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
We had high uptime for it. We didn't have too many issues with the releases and the versioning that they have beeen putting out. Mostly, everything went smoothly even with major foundational changes. Overall, anytime you're doing a foundational change, there will be some growing pains, and you expect that with any tool set.
What do I think about the scalability of the solution?
Scalability is decent. Our environment has over 3200 nodes for production and lower environments. We haven't had too many problems with load or scale. When we did have issues, there were always additional resources we could deploy to scale wide or horizontally. We could also up the instant size depending on what the machines were doing.
How are customer service and support?
We did use technical support, but not on a regular basis. We use our contact there, our account manager, who is always readily available, if not over the phone, by email. We either open up a ticket with them or contact them directly, and they go ahead and research the issue, then get back to us with their findings.
How was the initial setup?
The integration and configuration of the product in our AWS environment was functional at the time. I didn't get to do the migration after the production environment. However, everything up until then, we had handled in our lower environments. It seemed to work as described and within the confines of what we were dealing with, and it was functional for us. I just never got to work with it in the production realm.
What was our ROI?
I have seen the ROI, but it was brief. It cut down on our workload. We supported 36 to 38 development teams with a team of six DevOps engineers. We had embedded DevOps personnel within their teams. It could have gotten to the point where we needed individual DevOps personnel for every team, but Chef allowed us, as a group of five, depending on the time we were there, to reach out to them individually, and help them on a one-to-one basis. At the same time, we provide a center of excellence for best practices. This easily could've scaled to each team needing their own direct support person, but with the ability to manage these configurations through Chef, it allowed us to hand them their best practices straight across the board. Therefore, we didn't have to go ahead and drop in on each team and help them through their migration practice.
Which other solutions did I evaluate?
We also looked at Puppet, Ansible, and Jenkins. Chef rolled things into one for us with the way that they were running their deployments.
It was more of a one stop convenience going with Chef. A lot of the features, plugins, and compatibility items that we were looking for were already bundled into the package. Rather than piecemeal things together with the other services, we directly went with Chef to make sure it was a smooth, functional package for us. We went with Chef and its suite of tools to manage things more centrally.
What other advice do I have?
Make sure when you are tooling that what you are trying to create is functional within the product. Don't try and make it do something that it's not technically, nor architecturally, designed to do. While there are corner cases for things like that, if you're going to start to wander down that road, maybe you better take another look at a wider set of tools rather than just the one that you've got your eye on or the one your executives have their eyes on.
The product is functional. The ease of setup for almost everything that we did tooling-wise was straightforward. We didn't have too many issues which were out of the ordinary, corner case scenarios when using the product. That's always a bonus. Especially in ease of the installation and configuration, it is always a good thing when you're dealing with a product like this.
It integrates with softer packages, modern packages, alerting packages, etc. Aside from the base infrastructure, there are a lot of Chef tooling and plugins which make it a rather straightforward addition to the tool set. Almost everything was off-the-shelf or out-of-the-box. We did not have to configure or rewrite it ourselves, which was a big bonus. Most of these products are usually commercialized and available with ready support and tooling.
There was a migration that we were moving to the AWS sphere, but I was only doing that in the migration phase, never into the full operational phase. Comparability-wise, you do have a more control over your on-premise stuff because you can customize it to your needs. There is plenty of functionality that you can get in when you have on-premise. Though, you have to follow the standards when you're dealing with a vendor provided service.
*Disclosure: My company does not have a business relationship with this vendor other than being a customer.
