Chef extends open-source licensing to all its software

Is pricing going to remain similar? We'd rather be running automate now; cost has been the primary reason we aren't.

What about a fellow hner's comment above:

"""

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... """

> 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.

> so we can help with customer success.

Lol. Your privacy policy says you do much more with user info than 'customer success'.

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.

> Having full power of ruby at one’s disposal

That's when your config becomes unmaintainably large and complicated with personal taste.

>That's why Chef Inc. has been building Habitat;

Isn't that just, Docker?

> no need to learn Ruby

Instead we'll just learn yet another ad-hoc language clumsily built atop YAML, and put up with Norway always being false when abbreviated. :)

agentless is not a feature. System changes/breaks occur. agent-based approaches are a kind of "continuous validation" of your infrastructure.

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?

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.

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).

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.

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).

Containers, orchestration of containers. Lots of ad hoc tasks can be done with ansible.