Chef to be acquired by Progress • Hacker News Board

Re: Chef to be acquired by Progress

#141

Post by sngz » Wed, Sep 09, 2020, 8:06 PM UTC

I used to work on govt project that uses a Windows stack and advocated for implementing chef. I feel like Chef totally dropped the ball in terms of marketing / building features out for windows. The documentation, community and reusable recipes was ahead of it's other competitors but needed a lot more. I went to 2 chefcon's and almost all keynotes and workshops were linux focused and every time I brought up a question that is remotely government or windows focused I feel like I'm being treated like a 2nd class user. Government is notoriously slow to adapt to new changes / software, that could've been a space where they could grow with the popularization of containers. There are a few projects I consult on where they still can't / won't use containers.

With that said I'm glad I moved onto a *nix based project and got to learn Ansible and docker

Re: Chef to be acquired by Progress

#142

Post by xorcist » Wed, Sep 09, 2020, 8:07 PM UTC

dharmab wrote: post #134

xorcist wrote: post #99

Earlier quoted context omitted.

An application running as a container bascially carries the same configuration as one running without the container bits would. That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration. The deployment side also carries configuration, including things like desired amount of i…

> That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration. But Kubernetes solves most of this problem in an easier way with Pods, ConfigMaps, Secrets, Services and Endpoints.

That is your configuration, which you (may) want to manage.

Your whole infrastructure contains much more than that, and managing all that as a coherent whole is what these tools do.

Re: Chef to be acquired by Progress

#143

Post by xorcist » Wed, Sep 09, 2020, 8:19 PM UTC

nunez wrote: post #128

xorcist wrote: post #68

Earlier quoted context omitted.

Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML. There is less buzz around those tools now however, and people tend to gravitate to other tools which are easier to get started with. They may end up "silent heroes" (much like Ruby itself, I would say) or they may end up replaced by other tools. The concept of state as text in version control is a timeless con…

Puppet isn’t fit for purpose in 2020. Testing Puppet manifests locally is (was) THE WORST. Hiera and r10k really shouldn’t exist in 2020. IIRC you essentially need long-lived Git branches for managing different envs for different playbooks. Ansible is just SSH and a binary. pip install and I’m done. This is great for building VMs, base Docker images, app deployments, whatever you need. Puppet has their own wire proto…

The each their own, these tools are conceptually simple but as you found out, there is a lot to learn.

What kind of branching strategy is most suitable is given from how your testing is organized, not which particular tools are chosen.

Ansible is completely equivalent to Puppet or Chef in this regard. They are all the same family of tools. Many find Ansible easier to get started with due to its agentless defaults, but there are some (perhaps Spotify was most well known at the time) who run Puppet agentless too.

Having a server, something like Tower, is necessary as soon as you want to manage distributed configuration for clusters, and if you manage monitoring and backup systems.

Re: Chef to be acquired by Progress

#144

Post by dharmab » Wed, Sep 09, 2020, 8:38 PM UTC

xorcist wrote: post #142

dharmab wrote: post #134

Earlier quoted context omitted.

> That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration. But Kubernetes solves most of this problem in an easier way with Pods, ConfigMaps, Secrets, Services and Endpoints.

That is your configuration, which you (may) want to manage. Your whole infrastructure contains much more than that, and managing all that as a coherent whole is what these tools do.

Yeah, but what's left after you slim down your VMs to a Linux kernel, an SSH daemon and a container runtime? Is a CM system really justified at that point? Why not bake VM images and treat the VMs as immutable?

Re: Chef to be acquired by Progress

#145

Post by locusm » Thu, Sep 10, 2020, 1:59 AM UTC

joaquin2020 wrote: post #84

locusm wrote: post #39

Wow, I was a Progress DBA back in the day. They always felt very under the radar till they acquired Telerik.

Now I think I remember them. Weren't they an embedded database on Windows popular with PeachTree and such?

Progress ran on Unix varieties and Windows, had its own 4GL language that you built apps in to talk to the relational side. Ran some pretty big shops like Ideal Electrical/Burson Automotive etc here in Aus. This was 20 years ago mind you...

Re: Chef to be acquired by Progress

#146

Post by datashaman » Thu, Sep 10, 2020, 5:21 AM UTC

amiga-workbench wrote: post #13

PaulHoule wrote: post #5

What's a good alternative to Chef?

NixOS seems to be quite interesting, an OS with declarative provisioning baked right in.

Tried installing NixOS a few days ago. Live CD created an appealing desktop environment, could not get it to install on a partition though. There is no installer to speak of, I followed the instructions closely but ended up with a starter configuration that lacked network access (which was required to install the network components; ikr). gave up.