- “Chef will move all of our product software development to an open source model with 100% of our product code available and licensed under Apache 2.0”
- “Chef will produce a new distribution (release), Chef Enterprise Automation Stack, built for commercial users with new terms and conditions of use.”
Q: What do I have to differently today than I had to do yesterday?
For our existing commercial customers there is no action required.
For existing customers using Chef for non-commercial purposes, experimentation, or individual use there is no change.
For contributors to Chef OSS projects, non-profits, and other special groups we are still working on how we will partner with those communities around licensing Chef products. Stay tuned for more info.
Everyone else can continue using our current releases in perpetuity – although they will be end-of-support in 12 months and no further bug fixes or security updates will be available for those versions without a commercial arrangement. Customers who choose to use our new software versions will be subject to the new license terms and will have an opportunity to create a commercial relationship with Chef, with all of the accompanying benefits that provides.
Q: How will this impact existing customers?
For existing customers this change will not impact their usage or contracts. Companies that already pay us for Chef Infra (formerly Chef), Chef Inspec, Chef Habitat and/or Chef Automate will continue to do so and we will continue to increase the value of their relationship with Chef.
Users who do not pay Chef today (use our free open source binaries), and net new users, will have three options going forward:
License our commercial software distribution.
Take our open source code and create a software development org to build and manage their own distro (create their own downstream fork) or leverage a public free distribution (which may or may not exist).
Stay on an older free distribution in perpetuity. For example, they could use Chef 14.7.17 forever but they would not receive security updates , bug fixes or support from Chef starting 1 year after Chef 15 is released.
We will make licensing accommodations for individuals and significant community contributors to continue to use Chef Infra, Chef Inspec and Chef Habitat in the same way that they have been. In addition, we want to make it equally easy to experiment and self-learn with our various products.
Finally, we will have a low cost “Essentials” suite of our commercial distributions that should satisfy the needs of smaller businesses.
So on one hand all the software will be open source and on the other hand there will be no free as in beer distribution anymore. Sounds similar to the RedHat model. I wonder if the community is active enough to produce a CentOS like alternative distribution for Chef.
The Essentials distribution is interesting, I wonder what is in it. I assume it will not have things like Role Based Access Control (RBAC).
> Beginning on April 2, we will be making all of our products open source under the Apache 2 license and we will begin to attach commercial license terms to our software distribution (binaries) with the next major release. This is very similar to the “open source product” model most effectively run by Red Hat®, where they develop software in the open while attaching enterprise license terms to the distribution of RHEL (Red Hat® Enterprise Linux®).
Original author of Chef here (although no longer with the company day-to-day). I would not assume that - 100% of the software Chef produces is open source, so no reason to ever differentiate on features in licensing. So I doubt they would remove anything.
Correct - Essentials is just a low cost suite of Chef products. We offer two suites,. Effortless Infrastructure, focused on core config mgmt and security/compliance use cases and Enterprise Automation Stack which includes all of that plus a wide range of app automation capabilities including dependency mgmt, lifecycle mgmt, etc.
Today we have two easy methods for getting Chef's bits.
1) www.chef.io/get-chef/ - which is intended for newer users where we collect contact information so we can help with customer success.
2) downloads.chef.io which provides all of our downloads, ungated, for advanced users.
I really want to like Chef, but their ecosystem around their Infra-suite is just such a mess of different offerings, all with different limitations and features, I hope maybe this will consolidate things.
Chef-solo, Chef-zero, Chef-server, little-chef and tooling like knife and knife-solo.
It sounds like all Chef code will be open source (I'm curious what isn't open source today), but there is no release engineering work in public, and so if you want a supported / stable release, you need to either pay them, make a release internally yourself, or hope that someone like a Linux distro builds a release for you. It's intentionally patterned on the Red Hat model, and very much unlike the MongoDB / Redis Labs / Elastic approaches.
I'm of the opinion that depending on someone else's release of OSS is an antipattern anyway because if you're not going through your own release process, you're not confident that a one-line bug-fix is actually only changing that one line. (The exception is when you know their release is through some decently hermetic build environment like distro packaging or Travis or Docker, such that you expect to be able to replicate that build environment for yourself when the time comes.) But I think a lot of companies use vendor binaries even when the vendor source is open source, so this seems likely to make Chef pick up a few support contracts.
If you already have a complete config management setup, you're already getting 85% of the benefit.
If you're choosing one, Chef and Puppet work by having an agent on each client contact a server and pull down whatever's designated for that client. Then they try to make the local client conform to that state. Ansible is a push system where your server goes out to each client and tells it what to do over SSH.
In the event of a server issue, a chef-controlled system will continue trying to be in the last state it downloaded. That is, if you make a manual changeto something that chef controls, expect it to be reverted shortly. An ansible-controlled system will diverge with every manual change, up until contact with the server is regained.
The major difference between Chef and Puppet is that Chef recipes are Ruby programs with supplementary libraries, while Puppet uses a DSL written in Ruby. If you already have some Ruby experience or coworkers who write in Ruby, Chef is probably a better choice for that alone.
If you don't know any Ruby at all, ansible configuration may be faster for you to pick up.
I'll add that while using Ruby makes certain things easier in Chef, overall Ansible is simpler and that's I've ended up preferring it despite my familiarity with Ruby.
FWIW, we've had a lot of success with a super simple pull version of ansible. You can configure ansible to run against a local host instead of via ssh push, so we have a cron on all servers that pulls the latest configs from S3, runs ansible, and reports any failures to cloudwatch metrics. This is a good fit in particular for configuring stable host OSes that don't change all that often, for something like deploying application code where you want to be able to run it right away instead of in ~30 minutes the next time the cron runs. If we really needed to push out a critical patch or something, we could also parallel ssh to the necessary servers and trigger a run immediately.
I believe Ansible Tower is their enterprise tool to do a similar pull-based model. I haven't used it but I've used a Puppetmaster setup in the past, and I'm really not a fan of how much of walled garden, standalone solution these things all are. They introduce coordination that you might not really need and have their own protocols for dealing with it, they have their own patterns for bootstrapping new servers, authentication to servers, encrypting secrets, tracking which servers are up or down, etc. and a lot of that is redundant with other tools you might be using (e.g., secret management or monitoring) and other primitives that the cloud provider likely has built in (like IAM profiles to solve the bootstrapping problem).
What you've described is essentially Puppet in masterless mode.
One of the reasons why I prefer Puppet to Ansible is the speed: Ansible in push mode is incredibly slow, even after applying all of the recommended tuning options and configuring Mitogen. I haven't yet used Ansible in pull mode on a large scale infrastructure, but I'd love to know if it's faster.
I've played with Puppet, Ansible and SaltStack (never with Chef however).
The fact Ansible is agentless is somewhat of a downside IMHO.
We have a fairly large deployment, and our Ansible code is basically a glorified setup shell script. I would be afraid to rerun it on a running instance.
After the initial setup we basically maintain the servers by hand, with some additional one-off Ansible tasks in case of a fleet wide change (meaning duplication of effort: one for the one-off task, one to update the "setup script" for new instances).
The result is a somewhat unwieldy infrastructure that feels like we are managing pets, not cattle (the infrastructure has several thousands nodes), and the pets looking a lot like cats.
I know it's because we are using Ansible wrong, but at the same time, I feel that Ansible, without a master, kind of encourages this behavior, and it's likely very common to fall in this trap.
I may sound weird, but I prefer the Puppet DSL. I do acknowledge it has a bit stepper learning curve compared to Ansible (on top of a more complex setup with a slave, a master and some keys). But the DSL itself is not that hard to learn (IMHO, it's a bit easier to learn than a programming language). Also, it's far easier to structure a Puppet code base compared to an Ansible code base:
* You have general purpose module, often provided by the community, (like one managing apache, or postgres, or nginx).
* You can then create your own modules combining these community modules (for example, to have a module "my app server" which is a combination of the apache and tomcat module + a few resources to configure your in-house app)
* You can then compose these into full server roles
* You also have things like hiera which provides ways to factorize and structure configuration parameters across the infrastructure (to handle for example a dev, a stage, and a prod environment).
It's not trivial to structure your code properly, but all the bricks are there to do it.
With Ansible by comparison, you have to invent things yourself, and because it's far less directive, what easily ends-up happening is hard coded roles, with duplicated code as it's the path of least resistance.
Maybe I'm feeling a bit nostalgic because when I used Puppet for the first time (circa 2011/2012) it was kind of a revelation. I set it up to have our dev environment plugged on our SVN repository using trunk directly, and for the stage and prod, I just flipped a symlink on the master to point to the proper tag, I had also deployed the Puppet dashboard to have an overall view of the changes. It enabled us to very quickly iterate (compared to previous ways such as manually sshing and viming config files, or running a shell script) with an high degree of confidence regarding the consistency of the configuration, and everything was tracked properly has you had to commit to push a change. Fun memories, and one of the nicer projects I had the chance to work on.
Puppet agent setups have been painful fro us so we switched to Ansible. Our Unix Ops team are separate from our App Support team and both wanted to use puppet, but we had problems with conflicting puppet agents and conflicting agent versions. There are probably workarounds, but the App team decided to go with Ansible while Unix Ops stuck with Puppet.
Reading this makes me worry that they will no longer be providing easily installable downloads that are free for commercial use.
I suppose that is a good tradeoff, like Red Hat providing RHEL source but not installation media. But it will make harder to get started with Chef, and I don't know if there is enough community motivation to create a CentOS equivalent for Chef. I hope AWS's Open Distro project takes on more software projects (https://opendistro.github.io/for-elasticsearch/).
@antoncohen - We will provide easily installable downloads for non-commercial, experimentation, and individual use which should make getting started with Chef just as easy today as it was yesterday.
What prevents companies from using those downloads for commercial use? Is it "just" a copyright violation (i.e., the same thing that prevents them from paying for one copy of Windows and running a thousand), or is there something in the code (limits on scaling, time bombs, etc.) to make them unsuitable for production use?
Historically the answer is nothing, or very little. The commercial products have a licensing mechanism that nags you, or at least it did. I don't know what their plan is on that - but I know they'll do it in public now. :)
Since everything Chef makes is used for production infrastructure, they have historically avoided doing anything that would break functionality for license compliance.
"All Chef’s software is mission critical and runs in a variety of different use cases and environments. As a result, we have not implemented hard enforcement and we don’t have any plans to change that. What we do have are commercial terms that we expect users of the software to honor. Users will have to accept the terms of the Chef End User License when they first run our software. Once the license acceptance has been acknowledged, acceptance can be automated to avoid the need for user input for further deployments. "
So you stop distributing free software/open source binaries while claiming to turn all of chef into open source?
I really don't understand the motivations for that.
> But it will make harder to get started with Chef
IMHO this is already very hard to do. I tried recently and chef.io is an impenetrable labyrinth of different products, white sheets, data sheets, customer stories, and "Contact Sales" buttons.
> This morning, Chef Software announced that it will be releasing 100% of its software as Open Source, under the Apache License. Going forward, all of its product development will be done in the open, with the community, and released as Open Source Software. Chef is done with being Open Core, and is now a Free Software Product company. Good riddance to bad rubbish.
I'm not involved in the day to day of the business anymore, so I don't know. I suspect now is a good time to talk to a sales rep and see what they can do.
I'd agree with this.
If they'd done this in 2012 when they were the up and coming, they might be in the lead today.
I think ultimately this wasn't 'experimenting', this was Chef thinking they'd be in the lead _without_ open sourcing. When they realized otherwise, they open sourced as a defensive measure.
Every person can decide for themselves what story they want to tell. Chef has been declared dead/dumb/irrelevant from the beginning. It’s doing great as a business, and as software. You play your game - y’all can think it’s irrelevant, and it’ll just keep on focusing on solving people’s problems. Turns out it works.
> Chef Software announced that it will be releasing 100% of its software as Open Source, under the Apache License
If I understand the change right, it's more accurate to say y'all are releasing 99.999% of your software as Open Source. That 0.001% being the the compiled/packaged binaries that your enterprise customers will actually run in production. Which runs into the same problem as doing the open core/enterprise split, but worse. If y'all make it easy to do that compilation/packaging then there's no reason for enterprises to pay a license fee.
I started using Rails for some side projects 4-5 years ago and recently started it using it again for a side project. I remembered chef as the tool to use for server configuration from when I first got into Rails and tried to use it for my side project. My experience was not very good and I gave up after trying to find documentation on how to write a simple script. The best I got to was either giving my info to download a 400 mb Chef workstation or being sent to an external site to install the Habitat CLI tool, which I'm not clear on what that actually does. Adding to that having to find a compiled chef from some third party is not good.
Long story short, I gave up after about an hour and decided to use Docker, Digital Ocean's Docker server image, and Gitlab CI/CD to manage my deployment. I've rambled a bit and I don't know if I actually have a point here. I guess if I had to end on one, it's that there isn't an immediately obvious and easy path into the Chef ecosystem which I think once existed. Ultimately, I don't know if you should or should not care that I didn't end up using Chef. My tiny bit of developer mindshare went away, but realistically it was unlikely that I ever would send any significant money your way. But, of course, there is that small chance that my project blows up or I end up somewhere as a decision maker and that potential revenue would go to the Docker ecosystem now.
"we are more open and free" - There is nothing dishonest about that. What we are seeing is companies trying out different business models and seeing what works. I can respect that.
As an end user, if you care about free software- this is good news. Instead of having different "Enterprise" and artificially handicapped "open-source" edition, we get to see everything out in the open. The secret sauce is now limited to the release process. They say openly that if you need to, fork them and create your own releases - yeah go for the "knockoffs" if you can trust them - or else try the branded (Chef) product.
MongoDB got a lot of flak for misappropriating the name "open source". What Chef is doing is IMHO more clear and honest. They need to make money too.
We use manage chef server in multiple production environments and long standing customer and install the binaries automatically when building new servers and AMI's etc. Can someone explain how this will change in the future and impact us licensing wise? As up to now we pay for number of nodes managed by chef cloud servers (manage.chef.io) which makes it very clear what we paying for.. With these news it now not clear at all what we need to have liencing for :(
Also what happens to chef-zero etc? I looked at the pricing page https://www.chef.io/pricing/ which has been updated. Is this per month, year or perpetuity? and what counts as a chef infra target and inspec targets actually mean? as we use these for test-kitchen local development and testing as well we use chef-zero for Packer Images (AMI's) and AutoScaling vms.
I read the FAQ section (https://www.chef.io/bmc-faq/) and none of it is very clear as Chef does not need to be used with just a central server but can work standalone. So can someone explain how the pricing will work for these non connected workflows in the future? Chef-Zero for AutoScaling VMs, Packer Builds, and InSpec Profiles for Local Testing etc..
As looking at these changes it will be huge nightmare to keep track of every chef-client and inspec target installed everywhere when we got autoscaling and build systems running Chef as we prefer to use the official binaries but with this change that seems we may have to fork the Open Source Repos, even if we paying for some of infrastructure to be central managed by chef directly so we are 100% confident we not breaching any terms of service.
Will the build release process be also made open source so we can have confidence we will be creating compatible builds? As we much prefer to use vendor releases but under this new licensing terms that does not seems possible :(
For the $$ questions I strongly advise you talk to your sales rep. We will make it simple for you and your scenario. It's great to see real world concepts and we are working to align how you work with how we price. I'm confident we can work something out - no need to try to solve it on your own.
As for the build release process, no - we are not releasing the release engineering pipeline work. But since I'm confident we can get to constructive, affordable commercial relationship with you this shouldn't matter.
They're certainly not mutually exclusive. You probably mean fully managed container orchestrators; and they certainly don't serve nowhere near the majority of businesses.
But chef is a completely different beast. For those who can digest ruby (as I do), chef is still a fantastic choice. I have fond memories of chef. Written countless cookbooks, recipes and bootstrapped thousands of machines with it. Having full power of ruby at one’s disposal can’t be underestimated. But one has to appreciate ruby first ;)
Chef (and configuration management in general) is an anti-pattern for a cloud native approach.
The soup of the Chef ecosystem has always seemed hard to understand (and teach new team members): Chef, Chef-solo/zero, rubocup, test kitchen, food critic, berkshelf automate, delivery druck, inspec, infa, etc...
With containers and immutable infrastructure there just isn't the need anymore. They obviously realized this and created Habitat as a response, but after trying it a few times, I don't see why I'd use it over plain old Docker + K8s.
If you still need configuration management, Ansible is more flexible, is easier to learn/teach (no need to learn Ruby), agentless, no need to run a sever and can also do some orchestration.
You will get a lot more customers if you drop the enterprise-style website and the contact form requirements for downloads. Switch to a Stripe-like landing page.
61 comments
[ 3.4 ms ] story [ 109 ms ] thread- “Chef will move all of our product software development to an open source model with 100% of our product code available and licensed under Apache 2.0”
- “Chef will produce a new distribution (release), Chef Enterprise Automation Stack, built for commercial users with new terms and conditions of use.”
Q: What do I have to differently today than I had to do yesterday?
For our existing commercial customers there is no action required.
For existing customers using Chef for non-commercial purposes, experimentation, or individual use there is no change.
For contributors to Chef OSS projects, non-profits, and other special groups we are still working on how we will partner with those communities around licensing Chef products. Stay tuned for more info.
Everyone else can continue using our current releases in perpetuity – although they will be end-of-support in 12 months and no further bug fixes or security updates will be available for those versions without a commercial arrangement. Customers who choose to use our new software versions will be subject to the new license terms and will have an opportunity to create a commercial relationship with Chef, with all of the accompanying benefits that provides.
Q: How will this impact existing customers?
For existing customers this change will not impact their usage or contracts. Companies that already pay us for Chef Infra (formerly Chef), Chef Inspec, Chef Habitat and/or Chef Automate will continue to do so and we will continue to increase the value of their relationship with Chef.
Users who do not pay Chef today (use our free open source binaries), and net new users, will have three options going forward:
We will make licensing accommodations for individuals and significant community contributors to continue to use Chef Infra, Chef Inspec and Chef Habitat in the same way that they have been. In addition, we want to make it equally easy to experiment and self-learn with our various products.Finally, we will have a low cost “Essentials” suite of our commercial distributions that should satisfy the needs of smaller businesses.
The Essentials distribution is interesting, I wonder what is in it. I assume it will not have things like Role Based Access Control (RBAC).
> Beginning on April 2, we will be making all of our products open source under the Apache 2 license and we will begin to attach commercial license terms to our software distribution (binaries) with the next major release. This is very similar to the “open source product” model most effectively run by Red Hat®, where they develop software in the open while attaching enterprise license terms to the distribution of RHEL (Red Hat® Enterprise Linux®).
see pricing for the suites at https://www.chef.io/pricing/
hope this helps clarify.
Best, Brian Goldfarb CMO, Chef
Lol. Your privacy policy says you do much more with user info than 'customer success'.
Chef-solo, Chef-zero, Chef-server, little-chef and tooling like knife and knife-solo.
I'm of the opinion that depending on someone else's release of OSS is an antipattern anyway because if you're not going through your own release process, you're not confident that a one-line bug-fix is actually only changing that one line. (The exception is when you know their release is through some decently hermetic build environment like distro packaging or Travis or Docker, such that you expect to be able to replicate that build environment for yourself when the time comes.) But I think a lot of companies use vendor binaries even when the vendor source is open source, so this seems likely to make Chef pick up a few support contracts.
If you're choosing one, Chef and Puppet work by having an agent on each client contact a server and pull down whatever's designated for that client. Then they try to make the local client conform to that state. Ansible is a push system where your server goes out to each client and tells it what to do over SSH.
In the event of a server issue, a chef-controlled system will continue trying to be in the last state it downloaded. That is, if you make a manual changeto something that chef controls, expect it to be reverted shortly. An ansible-controlled system will diverge with every manual change, up until contact with the server is regained.
The major difference between Chef and Puppet is that Chef recipes are Ruby programs with supplementary libraries, while Puppet uses a DSL written in Ruby. If you already have some Ruby experience or coworkers who write in Ruby, Chef is probably a better choice for that alone.
If you don't know any Ruby at all, ansible configuration may be faster for you to pick up.
I believe Ansible Tower is their enterprise tool to do a similar pull-based model. I haven't used it but I've used a Puppetmaster setup in the past, and I'm really not a fan of how much of walled garden, standalone solution these things all are. They introduce coordination that you might not really need and have their own protocols for dealing with it, they have their own patterns for bootstrapping new servers, authentication to servers, encrypting secrets, tracking which servers are up or down, etc. and a lot of that is redundant with other tools you might be using (e.g., secret management or monitoring) and other primitives that the cloud provider likely has built in (like IAM profiles to solve the bootstrapping problem).
One of the reasons why I prefer Puppet to Ansible is the speed: Ansible in push mode is incredibly slow, even after applying all of the recommended tuning options and configuring Mitogen. I haven't yet used Ansible in pull mode on a large scale infrastructure, but I'd love to know if it's faster.
The fact Ansible is agentless is somewhat of a downside IMHO.
We have a fairly large deployment, and our Ansible code is basically a glorified setup shell script. I would be afraid to rerun it on a running instance.
After the initial setup we basically maintain the servers by hand, with some additional one-off Ansible tasks in case of a fleet wide change (meaning duplication of effort: one for the one-off task, one to update the "setup script" for new instances).
The result is a somewhat unwieldy infrastructure that feels like we are managing pets, not cattle (the infrastructure has several thousands nodes), and the pets looking a lot like cats.
I know it's because we are using Ansible wrong, but at the same time, I feel that Ansible, without a master, kind of encourages this behavior, and it's likely very common to fall in this trap.
I may sound weird, but I prefer the Puppet DSL. I do acknowledge it has a bit stepper learning curve compared to Ansible (on top of a more complex setup with a slave, a master and some keys). But the DSL itself is not that hard to learn (IMHO, it's a bit easier to learn than a programming language). Also, it's far easier to structure a Puppet code base compared to an Ansible code base:
* You have general purpose module, often provided by the community, (like one managing apache, or postgres, or nginx).
* You can then create your own modules combining these community modules (for example, to have a module "my app server" which is a combination of the apache and tomcat module + a few resources to configure your in-house app)
* You can then compose these into full server roles
* You also have things like hiera which provides ways to factorize and structure configuration parameters across the infrastructure (to handle for example a dev, a stage, and a prod environment).
It's not trivial to structure your code properly, but all the bricks are there to do it.
With Ansible by comparison, you have to invent things yourself, and because it's far less directive, what easily ends-up happening is hard coded roles, with duplicated code as it's the path of least resistance.
Maybe I'm feeling a bit nostalgic because when I used Puppet for the first time (circa 2011/2012) it was kind of a revelation. I set it up to have our dev environment plugged on our SVN repository using trunk directly, and for the stage and prod, I just flipped a symlink on the master to point to the proper tag, I had also deployed the Puppet dashboard to have an overall view of the changes. It enabled us to very quickly iterate (compared to previous ways such as manually sshing and viming config files, or running a shell script) with an high degree of confidence regarding the consistency of the configuration, and everything was tracked properly has you had to commit to push a change. Fun memories, and one of the nicer projects I had the chance to work on.
I suppose that is a good tradeoff, like Red Hat providing RHEL source but not installation media. But it will make harder to get started with Chef, and I don't know if there is enough community motivation to create a CentOS equivalent for Chef. I hope AWS's Open Distro project takes on more software projects (https://opendistro.github.io/for-elasticsearch/).
Since everything Chef makes is used for production infrastructure, they have historically avoided doing anything that would break functionality for license compliance.
"All Chef’s software is mission critical and runs in a variety of different use cases and environments. As a result, we have not implemented hard enforcement and we don’t have any plans to change that. What we do have are commercial terms that we expect users of the software to honor. Users will have to accept the terms of the Chef End User License when they first run our software. Once the license acceptance has been acknowledged, acceptance can be automated to avoid the need for user input for further deployments. "
IMHO this is already very hard to do. I tried recently and chef.io is an impenetrable labyrinth of different products, white sheets, data sheets, customer stories, and "Contact Sales" buttons.
> This morning, Chef Software announced that it will be releasing 100% of its software as Open Source, under the Apache License. Going forward, all of its product development will be done in the open, with the community, and released as Open Source Software. Chef is done with being Open Core, and is now a Free Software Product company. Good riddance to bad rubbish.
"""
jandeboevrie 23 minutes ago [-]
Too little, too late. Surpassed by Ansible (and AWX) a long time ago. Chef was nice in 2014 to get rid of puppet... """
I think ultimately this wasn't 'experimenting', this was Chef thinking they'd be in the lead _without_ open sourcing. When they realized otherwise, they open sourced as a defensive measure.
If I understand the change right, it's more accurate to say y'all are releasing 99.999% of your software as Open Source. That 0.001% being the the compiled/packaged binaries that your enterprise customers will actually run in production. Which runs into the same problem as doing the open core/enterprise split, but worse. If y'all make it easy to do that compilation/packaging then there's no reason for enterprises to pay a license fee.
I started using Rails for some side projects 4-5 years ago and recently started it using it again for a side project. I remembered chef as the tool to use for server configuration from when I first got into Rails and tried to use it for my side project. My experience was not very good and I gave up after trying to find documentation on how to write a simple script. The best I got to was either giving my info to download a 400 mb Chef workstation or being sent to an external site to install the Habitat CLI tool, which I'm not clear on what that actually does. Adding to that having to find a compiled chef from some third party is not good.
Long story short, I gave up after about an hour and decided to use Docker, Digital Ocean's Docker server image, and Gitlab CI/CD to manage my deployment. I've rambled a bit and I don't know if I actually have a point here. I guess if I had to end on one, it's that there isn't an immediately obvious and easy path into the Chef ecosystem which I think once existed. Ultimately, I don't know if you should or should not care that I didn't end up using Chef. My tiny bit of developer mindshare went away, but realistically it was unlikely that I ever would send any significant money your way. But, of course, there is that small chance that my project blows up or I end up somewhere as a decision maker and that potential revenue would go to the Docker ecosystem now.
As an end user, if you care about free software- this is good news. Instead of having different "Enterprise" and artificially handicapped "open-source" edition, we get to see everything out in the open. The secret sauce is now limited to the release process. They say openly that if you need to, fork them and create your own releases - yeah go for the "knockoffs" if you can trust them - or else try the branded (Chef) product.
MongoDB got a lot of flak for misappropriating the name "open source". What Chef is doing is IMHO more clear and honest. They need to make money too.
We use manage chef server in multiple production environments and long standing customer and install the binaries automatically when building new servers and AMI's etc. Can someone explain how this will change in the future and impact us licensing wise? As up to now we pay for number of nodes managed by chef cloud servers (manage.chef.io) which makes it very clear what we paying for.. With these news it now not clear at all what we need to have liencing for :(
Also what happens to chef-zero etc? I looked at the pricing page https://www.chef.io/pricing/ which has been updated. Is this per month, year or perpetuity? and what counts as a chef infra target and inspec targets actually mean? as we use these for test-kitchen local development and testing as well we use chef-zero for Packer Images (AMI's) and AutoScaling vms.
I read the FAQ section (https://www.chef.io/bmc-faq/) and none of it is very clear as Chef does not need to be used with just a central server but can work standalone. So can someone explain how the pricing will work for these non connected workflows in the future? Chef-Zero for AutoScaling VMs, Packer Builds, and InSpec Profiles for Local Testing etc..
As looking at these changes it will be huge nightmare to keep track of every chef-client and inspec target installed everywhere when we got autoscaling and build systems running Chef as we prefer to use the official binaries but with this change that seems we may have to fork the Open Source Repos, even if we paying for some of infrastructure to be central managed by chef directly so we are 100% confident we not breaching any terms of service.
Will the build release process be also made open source so we can have confidence we will be creating compatible builds? As we much prefer to use vendor releases but under this new licensing terms that does not seems possible :(
For the $$ questions I strongly advise you talk to your sales rep. We will make it simple for you and your scenario. It's great to see real world concepts and we are working to align how you work with how we price. I'm confident we can work something out - no need to try to solve it on your own.
As for the build release process, no - we are not releasing the release engineering pipeline work. But since I'm confident we can get to constructive, affordable commercial relationship with you this shouldn't matter.
But chef is a completely different beast. For those who can digest ruby (as I do), chef is still a fantastic choice. I have fond memories of chef. Written countless cookbooks, recipes and bootstrapped thousands of machines with it. Having full power of ruby at one’s disposal can’t be underestimated. But one has to appreciate ruby first ;)
That's when your config becomes unmaintainably large and complicated with personal taste.
Isn't that just, Docker?
It's an entire CI/CD environment with containers, including orchestration of updates, the ability to do an immutable infrastructure, and so much more.
The soup of the Chef ecosystem has always seemed hard to understand (and teach new team members): Chef, Chef-solo/zero, rubocup, test kitchen, food critic, berkshelf automate, delivery druck, inspec, infa, etc...
With containers and immutable infrastructure there just isn't the need anymore. They obviously realized this and created Habitat as a response, but after trying it a few times, I don't see why I'd use it over plain old Docker + K8s.
If you still need configuration management, Ansible is more flexible, is easier to learn/teach (no need to learn Ruby), agentless, no need to run a sever and can also do some orchestration.
Instead we'll just learn yet another ad-hoc language clumsily built atop YAML, and put up with Norway always being false when abbreviated. :)