If you were talking to someone whose organization is considering Chef, what would you say?
How would you rate it and why? Any other tips or advice?
Chef is a great tool to use. Try to automate your whole department process with Chef, if possible. Also, try to use the same tool across different platforms, so it will be easier to manage.
Compare it to the other services that you use. Everything can always be improved. If you have a specific need in configuration management and integration, Chef is a great product, especially with AWS.
It works well. I would highly recommend it. It is a well thought out product which integrates well with what developers and customers are looking for. The product works well with VMware environments. I have used the on-premise and AWS versions. It integrates well if you are in AWS environments. However, if you are on-premise, it may not be the best solution.
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.
Find use cases and do your research. We only use the AWS version. We tried the other versions, but we found that they were lacking in functionality.
I would recommend Chef. It is very user-friendly. There are a lot of community resources which make it easy to onboard. It also plays nicely with existing automation tools and other things which you are probably already using. Chef works with Adobe Experience Manager, Terraform, and AWS CLI tools. We have been pleased with the integration. We have only used the AWS offering.
I would rate this solution a nine because it's simple, easy to use, more versatile, and most importantly, it can handle the hundred thousand servers at the same time very easily and almost in no time. It depends on the enterprise need, but I would advise someone considering this solution that if you want to have very heavy or big clusters this is a product you can trust for deployment and it's smooth. You can create your own custom recipe which in other products, I would say is only partially there and depends on the different types of applications. Not all applications have the same deployment and orchestration patterns and most of the SAP deployment credits are covered.
I have used the on-premise and AWS versions. I prefer the AWS for troubleshooting. It integrates with many products in ILT, data management, and the server areas with each of them providing cloud computing, like EC2 and API Gateway.
If someone would like to go for a heavy cluster, this is a product they can trust for deployment, since it is smooth. Even though customization is needed, they can create their own custom recipe, which in other products, I would say is partially there and also depends on the different type of applications. We had the solution on on-premise for a year, but now it is completely on AWS Cloud. AWS Cloud is easier to use. We can change the solution by refitting the architecture solution now because it is easy.
At the top level, it is integrated with Terraform, which is delivering whole entities and groups of nodes. Then, those nodes are individually being provisioned with Chef. The integration is seamless. I've run my own Chef server before. We've done completely headless with Chef Zero, where we're distributing the code directly to box during provisioning. We've used Chef pretty much every way that it can be used. The AWS software is good. There is definitely value for somebody who is trying to understand it and be able to have a deployment of it for observation. Coming into it, there's a lot to understand, as with any technology. If I'm thinking about coming into it now or trying to bring somebody up to speed, it would be good to have an already functioning setup of the server where you can interact with the NoSQL database and play with some of the tools available to understanding how they work in an AWS instance. It will be very similar to the way Chef Automate works, in general. Therefore, I do see value in it.
I would definitely recommend using Chef. Chef integrates and configures well with AWS and other products. We use Chef and Puppet together. We are also using Splunk for log traces. We just started using Chef with AWS for easy to use containers. AWS is great for storage, CloudFormation, and CloudFrond CDN. We are moving towards the cloud environment with all AWS resources.
If you're looking for an environment where there is an ROI business case, or looking into or orchestrating multiple environments, it makes sense to go with Chef. But if it's a minor orchestration you're looking into, the best tool would always be native solutions. In other words, if I you are looking at a platform where there will be two or three moving parts, you should look at the platform's built-in, native solution. If you have a wider range of moving parts and automation to be done, configuration-wise, you can bring in an orchestrator like Chef.
Chef is an extremely amazing tool and has been extensively developed in the last couple of years. There are tons of plugins and integrations available for it, my favorite being the Chef-docker plugin. I started with Chef as a QA engineer and wrote some beginner level recipes for some easy setups on AWS. I then worked on a bank project where I used the knife-vcloud plugin for Chef to automate provisioning for VMware vCloud. I did some initial evaluation, comparing Chef and Ansible for SAP to automate deployment on bare metal. In some recent projects, I wrote Chef recipes for deployment automation. I integrated it with Fabric/Python. I would definitely rate Chef an eight out of 10. Although Chef is easy to code, it still has a little learning curve, since you need to know Ruby.
We're considering to offer developers free creation of automation pipelines.
The idea is to get workflow requirements from a customer and build the workflow according to these requirements so what is left for them is to integrate them into their own resources and to execute.
Do you see a high demand for anything like that? Please let us know your use cases.