Chef PAYG

My main use case for Chef  is configuration and deployments. We receive blank servers and use Chef  to build predefined application or appliance servers.

A quick specific example of how I use Chef to build a predefined application or appliance server is that we use Chef to build Postgres database servers in containers. We receive a blank Red Hat VM and then deploy Docker  CE, Docker  Compose, and the Red Hat environment.

Additionally, we deploy Postgres images and the Prometheus Postgres exporter and configure it with all of the client's requirements, including their pre-shared secrets and pre-agreed IP addresses. We use encrypted data bags for pre-shared secrets.

Chef has impacted my organization positively by ensuring that consistent deployments across production and test environments help more effective testing and faster deployments mean that more work can be done in one release cycle. There is less time spent building the infrastructure and more time spent building new functionality, testing new functionality and updates, which means we can get more into one release.

As for specific outcomes or metrics, there are impacts that could be measured in some of the systems that I have moved to Chef or systems that I have been involved in writing cookbooks for so that they are always deployed on the client site in Chef, but we have not measured them. I can tell you that deployment is more consistent and faster and there are fewer errors, but I do not know how many because we have not been tracking it effectively. GitOps and Chef make tracking it effectively very possible.

The best features Chef offers for my workflow include that Chef is very useful for infrastructure as code as part of the solution. Obviously, you might need Terraform  or Ansible  to build on bare metal, but then you use Chef to configure from the OS upward in the stack. It allows you to build all of that from a Git  repo in a predictable way instead of a person doing it slightly differently every time manually, which is both faster and more reliable, therefore useful.

Out of those features, the one that stands out the most for me is the infrastructure as code aspect. The predictability and the speed are the key benefits. When you have infrastructure as code and you already have everything apart from the environment-specific config, which you can specify in variables, then it is not only more repeatable and reliable, it is faster. The two together is the benefit that you are after.

I would add that Ruby is a domain-specific language in the Chef dialect, which is a learning curve, but so is Terraform  and so is Ansible . The only feedback would be if they could come up with an interface in a language such as Java or Python that is even more ubiquitous than Chef or Ansible are themselves, then I think someone with a good configuration system would be on to something.

To improve Chef, making an interface with another language such as Python or Java that is well understood, as capable as Ruby, and even more widely adopted would demystify it a bit. Other things would be the need to use Cinc if you want to use the open-source version because Progress Software's policy on copyright is confusing for new users and it puts a barrier in the way to adoption because many small, medium enterprises, startups, and non-profits who might want to use Chef would find the whole Cinc versus Chef situation confusing and the fact that there is not an easy path to install Chef and then go to a paid version without having to change from Cinc to Chef or Chef to Cinc.

Other than making the need for Cinc go away by finding a compromise policy and making an interface, whether optional or as the default, in a language that is even more ubiquitous than Ruby, the only things I could see would be a curated open-source approach.

I have been working in IT for 17 years. I have been using Chef on and off for a couple of years total in the previous 12 to 13 years before my current role, and then continuously for all of the last three years in my current role.

Chef is stable. Both the pre-copyright policy version or trademark policy version of Chef and the Cinc server that we have have been stable.

Chef's scalability is evident as the public sector organization I work at serves a population of 5 million, and we have had no problems with scaling.

My experience with customer support is that we use Cinc, so there is no customer support available.

Previously, I used a different solution where things were manually configured or servers were cloned. We did not have as capable a solution in the past.

Before choosing Chef, the organization I am part of had already implemented Chef when I joined. However, I have heard about the process, and Chef was built as GitLab  was already in place and Chef was used as a proof of concept to show how it could work, and it became production because it was working.

I have seen a return on investment. With the same number of employees or a very slight increase, we are doing more work than we were before Chef and Cinc were introduced. Even though we are using Cinc rather than paying for Chef, there is an investment required in time to configure it correctly on the on-premises version, time for people to learn, and generally staff resourcing. However, the return has been far more hours saved than spent.

My experience with pricing, setup cost, and licensing is that we sidestepped it by using Cinc because none of the functionality that is exclusive to the paid version was actually in use in the organization.

My advice for others looking into using Chef is that if Cinc covers your use case, even if in production you require the type of support that means you would have to buy Chef, it is possible to deploy for free still. Many people are not aware of that because of the trademark policy and the change of name. I would recommend that if Cinc covers your use case, then build your proof of concept using that because there are no license implications. As for the actual licensing, we are not using any of the features that require licensing, and we are a primarily on-premises organization, so we have been using on-premises Cinc.

My company does not have a business relationship with this vendor other than being a customer. Accenture may or may not be, but the contract I am on is with a public sector organization who are using the open-source version deliberately.

I have additional thoughts about Chef regarding the opaque relationship between the open-source distributions such as Cinc and the mainline Chef itself. I would rate this review an 8 out of 10.

I use Chef  day-to-day to manage infrastructure, create version control, and automate deployment for applications that are ready for deployment and that my team and other teams work on. I work to manage this capability and deploy as fast as possible in a scalable and automated manner, working with people across the organization to achieve a common infrastructure, scalability, and security upgrades for that infrastructure.

The specific task that I worked with for Chef  involves managing up to 70 servers across the organization to deploy applications that my team or other teams develop. This has given me experience deploying applications, understanding the infrastructure as it works, automating processes thoroughly, and monitoring as the application scales up and down. Chef has given us an easy time doing all that automation, security, and monitoring by automating the processes across all those servers so that we don't do manual work, going one place at a time to install updates. If a server goes down across availability zones, we don't have to go and do it manually or troubleshoot along. We automate most of the tasks that we need to do using Chef.

In terms of time, the reduction in manual work is significant. A whole day of 12 hours is now reduced to less than 30 minutes, depending on what we are doing. Once you have the code, you can always copy and reuse it somewhere as long as you know what you are doing. In terms of security configurations, we monitor all servers in various availability zones. We look at how we can automate this in our infrastructure such that once we detect something is coming up, we can patch all servers at once. This reduces our concentration on repetitive tasks and allows us to focus more on delivering availability to the customers and company resources.

This has brought employee happiness, with developers saying that the work environment with available servers and infrastructures has improved by approximately 90 percent. We used to work with people on the sites who continually monitored servers and deployed servers. Now we deploy servers and then we wait while we automate using Chef and monitor those which are about to fail. We monitor them and create scripts to change how they operate, take some down, bring some up, and do load balancing when we need to start a load balancer, without physically having somebody do that every single day unless it is necessary.

This has given the organization an ability to focus more on new challenges that come in, not doing the mundane tasks of every day of infrastructure development. We save more on money in terms of time and also in terms of security applications, deployment, and bringing our infrastructure up. The reduction in employees needed means we don't have to recruit more. We look at those who are there, allowing them to save time to focus on themselves, improve, and learn more about how to make their infrastructure better every day.

Chef offers various features including a unified dashboard, compliance reporting, continuous delivery, and role-based access. The key features that stand out for me are agent scanning, auditing, and portability. With portability, you can easily pick what you have automated instead of trying again to work within another set of nodes. You have that ability to manage all your principles in the cookbook without moving everything from one place to another. You can use the concept of agentless deployment where you just install the Chef agent and then you can use the client. It can monitor what is going on on the servers and then it can report back for you to monitor. Even if you have various availability zones, you can monitor as one in a unified dashboard.

Security is a key aspect that Chef can automate, monitor new features that are available, and even do patches without you getting involved. The features that stand out for me are security as a key one and the work of a unified dashboard that is cross-platform. Chef allows you to write a declarative language using Ruby. These features exemplify the industrial standards that are there and have made my daily work as easy as possible.

One thing that Chef needs to improve on is making it available in as many languages as possible. There should be a focus on how to make it understandable, not just to infrastructure people, but also to those working in monitoring. How can we ensure that it is part of their daily input? That is something that still has a small missing link. We are almost there, but it can help us achieve outcomes in the future in terms of objectives, not just workflows and visibility. How can we make real-time interactive dashboards more available? Look at what kind of tools can be integrated with them, not just working with the ones like Chef Kitchen and Habitat, but trying to make it even more flexible than what we have right now.

On support, I think there should be more focus on how we can achieve AI automations in answering questions for beginners and addressing deep concerns without general manual management.

I have used Chef for four years for infrastructure management, managing approximately up to 70 servers. This has helped in scaling applications that we develop and bring them to working through DevOps principles. This has given me quite a good experience in the company I work for and also allows me to leverage everything to scale, automate, and version control as expected.

Chef is very reliable in terms of how we work, achieving durability of scalability and monitoring of our servers. It is a good tool to work with, offering a strong developer experience and community support.

We use both public and private cloud for Chef. We use AWS  and Azure , but we also have on-premises that we depend on. We leverage both to achieve the best option possible for scaling.

We use both AWS  and Azure  depending on scenarios and areas of concern. We also work with Huawei and Oracle, as our dependencies vary based on what we want to achieve with the cloud platform.

We usually work with the Chef teams and community support, who are always willing to assist. We often reach out through Slack or the main Chef support pages. The usual emails provide a lot of support, which contributes to our success and consulting efforts.

We mostly used to rely on manual processes, but we transformed to working with VMs, either single servers or similar setups. However, we realized we needed to automate how we bring our infrastructure up. Now, we look at Ansible  as well. Ansible  differentiates with its low barrier to entry and is more of a push model, as does Puppet . We don't just work with one, but we use a combination of Puppet , Ansible, and Chef to achieve what we need.

We evaluated working with manual setups, just Ansible, and working with Puppet alone, but then we realized each of them has limitations. We combine all three based on scenarios to achieve the best results for us.

The setup cost and licensing are reasonable compared to what we deliver. Licensing looks reasonable compared to the manual work of managing whole data centers with even 10,000 servers. Chef will be better for monitoring as it brings cost in a unified way so that you don't just look at it as spending but also look at the savings at the end of the day for your licenses. This license is not quite high, depending on what we achieve, because it does a lot for us in infrastructure management.

Chef is something that solves challenges related to the cloud. Now that we are looking at scalability of data centers with thousands of servers, I will look at Chef to see how we can have everything and have other languages working on it, not just Ruby.

The advice I would give is to learn Chef and look at what you want to achieve, what you want to save, and consider time. Evaluate in terms of what you want to accomplish, and once you do, you can work with Chef very well. Chef is a good tool, and to those venturing into infrastructure management, Chef is the way to go. This review is rated 9 out of 10.

I used the solution to transform my infrastructure into code.

The solution is easy to use and learn, and it easily automates all the code and infrastructure. The solution quickly automates development in a cloud environment and provides flexibility for selecting multiple clouds in infrastructure. The solution is easy to use.

I never faced issues with the solution’s stability.

Chef is a scalable solution.

I've worked with the solution during my three months of internship and in my self-made project. I would recommend the solution to other users.

Overall, I rate the solution an eight out of ten.