Chef to be acquired by Progress • Hacker News Board

Re: Chef to be acquired by Progress

#121

Post by kraig » Tue, Sep 08, 2020, 11:56 PM UTC

rmoriz wrote: post #119

swalberg wrote: post #103

Earlier quoted context omitted.

I brought Chef into the online side of the NFL several years ago. We still use it, though less and less as we get more things into containers. I've got my gripes with it, but I'd never second guess my decision to use Chef, or trade it for anything else. Those problems sound like people aren't taking the same care in their cookbooks that they are in their regular software. If you write bad cookbooks and don't at least…

I'm using Chef since 2010 for myself and customers. I never understood the hate but I saw so many developers not getting it and/or overengineering it to a state which was beyond their capability to debug. For example the different levels of attribute types. I saw "senior" developers writing nasty Ruby code (actually `system("rm -rf directory")` to delete directories (outside the chef DSL) because they didn't understa…

It's going back, at least on the HCL front. Have a look at Pulumi and prepare to throw TF in the trash.

Re: Chef to be acquired by Progress

#122

Post by chucky_z » Wed, Sep 09, 2020, 12:12 AM UTC

nunez wrote: post #72

PaulHoule wrote: post #5

What's a good alternative to Chef?

Ansible! (I’ve heard mixed reviews about Ansible Tower though.)

Skip AWX entirely and just use Jenkins. As insane as this sounds, I've personally done Jenkins => AWX => Jenkins twice. A good shared library can entirely replace AWX and the level of authn/authz plugins with Jenkins blows away any granularity with AWX.

Re: Chef to be acquired by Progress

#123

Post by rufugee » Wed, Sep 09, 2020, 12:41 AM UTC

I dealt the Progress from about 2003 to 2008 or so. They were an absolute horrible company to work with and essentially held us hostage on an old platform because we refused to pay an exorbitant "platform change fee". And by exorbitant, I mean HUGE. Fortunately, we sponsored an open source OpenEdge ABL and DB replacement project (FWD - https://www.beyondabl.com) and have been running our converted project very successfully since 2009. We went from OpenEdge / Progress DB to Java / PostgreSQL in an automated way. For anyone else held hostage by Progress Software because of your reliance on Progress 4GL (OpenEdge ABL) I encourage you to take a look.

Perhaps the company itself has improved since then. I certainly (for Chef's sake) hope so.

Re: Chef to be acquired by Progress

#124

Post by sagichmal » Wed, Sep 09, 2020, 1:03 AM UTC

A litmus test: who writes Chef recipes in your org? A relatively small group of engineers responsible for infrastructure provisioning, or any engineer who wants to deploy software? The latter is a pathological case and super destructive to engineering teams, but in my experience almost inevitable if you use Chef for the former.

Re: Chef to be acquired by Progress

#125

Post by jameshush » Wed, Sep 09, 2020, 1:38 AM UTC

swalberg wrote: post #103

user5994461 wrote: post #55

My 2 cents on Chef is that's it's long dead. The handful of people I know who used chef professionally all gave strong negative feedback about it and moved away to ansible. While I can't comment on the exact problems because I didn't use it personally, there was a recurring mentions of losing states, seemingly destroying systems and configurations instead of setting things up. People were adamant that moving away fro…

I brought Chef into the online side of the NFL several years ago. We still use it, though less and less as we get more things into containers. I've got my gripes with it, but I'd never second guess my decision to use Chef, or trade it for anything else. Those problems sound like people aren't taking the same care in their cookbooks that they are in their regular software. If you write bad cookbooks and don't at least…

I can confirm that the NFL Chef cookbooks were great. I worked at the NFL and previously introduced Chef at a startup beforehand. The biggest issue I had at the startup were application developers cutting corners when creating ANY infrastructure code, not just Chef recipes. The devil IS the details when it comes to infra code, and the lack of detail, not the tool itself can really bite you.

Re: Chef to be acquired by Progress

#126

Post by DaiPlusPlus » Wed, Sep 09, 2020, 1:46 AM UTC

zedfoxus wrote: post #106

mellosouls wrote: post #74

Fwiw Progress is most notable as a provider of OpenEdge, a database/development hybrid that was interesting/infamous for its contrarian 4GL based approach. While you could access the database via SQL that was very much the second class citizen; it's native 4GL was fully integrated, and long predated attempts like Linq to hide developers from SQL. https://www.wikipedia.org/wiki/OpenEdge_Advanced_Business_La...

OpenEdge has pretty good SQL support. Progress management I talked to did NOT want to stand behind SQL for CRUD applications. They were OK with SQL's use for ETL and were adamant that OpenEdge should be used only with 4GL for CRUD application. I wrote several blogs to explain the cool CRUD apps one could write. I did observe that 4GL devs were very shy to use anything but 4GL to work with Progress. Yes, SQL is treate…

> Progress management I talked to did NOT want to stand behind SQL for CRUD applications.

Of course not - the entire business model behind OpenEdge (which is far from "open") is to have applications built with their laughably irrelevant ABL/4GL language and only working with data in OLTP / one-record-at-a-time because that makes it almost impossible to switch to the conventional (RDBMS + web-service + frontend) architecture that the entire industry shifted to 20 years ago.

OpenEdge (nee "Progress DB") was a cool platform in the late-1980s through to the early 2000s because it supported IBM's AS/400, MS Windows, and Linux - with their UI system that let you design an input form once and have it magically work in text-mode AS/400 terminals and the Windows desktop - but the fundamental design of OpenEdge is still based on its AS/400 roots and it really doesn't work well with modern systems (e.g. it has this design with multiple "broker" processes which is a PITA to configure).

Their anti-open-source article on Progress' website that the GP post linked to was infuriating to read: it felt like the same anti-GPL propaganda that did the rounds around 2003 when SCO was claiming Linux contained their copyrighted code and Microsoft was astroturfing articles about the "risks" of open-source code and seemingly intentionally confusing people about MIT/Apache vs. GPL licenses. Le sigh.

Re: Chef to be acquired by Progress

#127

Post by devonkim » Wed, Sep 09, 2020, 3:32 AM UTC

carlosf wrote: post #93

geerlingguy wrote: post #83

Earlier quoted context omitted.

The fact that I've never heard of Habitat or InSpec means either they're extremely niche and not as popular as I think Chef would've hoped, or I'm completely out of touch with both app packaging and sec tooling. I'm hoping it's the former, but I wouldn't be too surprised if the latter since the 'enterprise' ecosystem of cloud tooling has grown exponentially in the past decade.

You're not out of touch, Terraform + Containers + People realizing that building immutable things is much better than managing state pretty much killed Chef and Puppet.

After having spent the past decade across about 12+ companies in various capacities furiously trying to make software immutable and to isolate state to dedicated services like DBs, message brokers, and networked caches, I’m not sure if it’ll go away without many companies rewriting software from the ground up effectively to support cloud native-ish assumptions like 12F but much more like avoiding leaving transactional state on-disk that can’t be recovered. There’s a TON of software out there that is written like it’s the 90s still. The market for managing legacy stateful software is matured to its finality and nobody wants to try to attempt to revolutionize it anymore is what I’m seeing, not that nobody is doing it anymore. Essentially, if one is writing new software that isn’t containerized in 2020 you’re writing the systems equivalent of COBOL.

But anyone could see many years ago that it’s easier to flatten and reinstall stuff than trying to painstakingly manage various moving pieces. We were limited by our technology unless one was using stuff like zones in BSD or Solaris.

The surprise for me has been how rapidly huge behemoth organizations like the DoD has shifted to technologies like K8S when they took so many years just to get onto VMware and some configuration management.

Re: Chef to be acquired by Progress

#128

Post by nunez » Wed, Sep 09, 2020, 4:01 AM UTC

xorcist wrote: post #68

fooqux wrote: post #38

Earlier quoted context omitted.

From my viewpoint, Puppet's portfolio is comprised of mostly half-baked stuff. You have Puppet itself, which is decent, and then an almost Google-level of weird stuff. They keep announcing new products but so far nothing seems to be sticking and they're all ludicrously expensive IMHO. Meanwhile, their core technology is kind of a dead end. More and more people are looking to manage containers and other serverless typ…

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 protocol and is very dependent on a client-server relationship. You need to edit config files and fake a puppet master. That’s work.

Re: Chef to be acquired by Progress

#129

Post by mkesper » Wed, Sep 09, 2020, 6:31 AM UTC

TinyRick wrote: post #48

fooqux wrote: post #34

I know nothing of Progress. Are they OSS friendly? I'd hate to see some of the OSS chef-managed tools die on the vine because of this.

From the Progress press report... "We have a long history of supporting open source communities so I am proud to say that we will continue to nurture the vibrant and thriving Chef open source community."

What value is in such a PR?

Re: Chef to be acquired by Progress

#130

Post by Fost_Power » Wed, Sep 09, 2020, 6:35 AM UTC

purpleidea wrote: post #19

It's confirmed then. Absolutely nobody wants to buy Puppet. Anyone know why that fell through?

I was surprised when I saw the Chef numbers, ouch. I think they must have been simply running out of money and options. If they had a strong balance sheet, you would have expected them to at least be picked up by a reputable PE firm. I hadn’t even come across Progress As a software co till this announcement.

On Puppet, I think they are a different beast to Chef at this point. They seem hyper focused on the larger enterprises rather than SMB or startup land. I came across them at both of the banks I recently contracted for, for example. Whilst I wasn’t hands on myself, there was a big project to roll out Puppet’s impact analysis and CD product at the last place.

I also ‘think’ Puppet are about double the size of Chef and saw their BlackRock debt round announced. You don’t get money from someone like that unless your at scale and you don’t get debt (especially at a time like this) unless you can afford the payments+interest. So, they must be at least growing if not profitable as well.