Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chef to be acquired by Progress

blog.chef.io

Post reply on HN
Print view View original

101–110 of 146 posts

Re: Chef to be acquired by Progress

#101

Post by johncoogan »

nunez wrote: post #73

Chef was acquired for $220M cash. According to Crunchbase, Chef raised $105M total up to a Series E. Investors aside, did anyone make money here? Either way, I’m glad that they are continuing to exist. Chef was onto something with Habitat and (especially) InSpec.

It depends on the price they paid for stock or the exercise price for stock options. If you were an early employee and your received options when the company was only worth $10m or something low, you could make money.

The risk is that one of the later investors had a ratchet or something that would allow them to claim more of the proceeds in a sale. You can't just take $220M cash, subtract $105M in funding and pass that to the founders and employees. The preferred shares were probably "participating" meaning they get a portion of the common.

Here's an example of a ratchet: https://www.forbes.com/sites/petercohan/2015/11/07/unicorn-s...

Re: Chef to be acquired by Progress

#102

Post by xorcist »

fooqux wrote: post #76
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 is a great tool for managing containers, and so is Chef. Eh. While I won't say that it can't be used, I will argue that it's not the best tool for the job. I wouldn't call it a "great tool" for that purpose, although I suppose that depends on your workflow. I prefer to take the approach that containers are immutable once built. If you want to change the container, fine- make your changes, build a new instanc…

Not sure what the argument here is. Different builds for prod, qa and test?

Even if that was workable, which is a question in itself, there is still configuration outside the packaged application. AWS keys, metrics and logs, dashboards, that sort of things.

Re: Chef to be acquired by Progress

#103

Post by swalberg »

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 give a cursory review of the community cookbooks you use, you'll end up with a mess. If you treat it like the customer facing software it is, I find it a pleasure to work with.

Our cookbooks have CI pipelines that run some basic tests and we have automation around rolling out changes. We rely on a lot of conventions to avoid storing state, but we still have nodes auto provisioning their own storage and load balancers where necessary. It's let us stand up a ton of infrastructure and make changes safely and quickly. That's not to say we couldn't have made Puppet/Ansible/etc work, because IMHO it's more about your development practices than anything else.

edit: we only use Chef Infra and some Inspec. Not talking about Habitat.

Re: Chef to be acquired by Progress

#104

Post by nunez »

johncoogan wrote: post #101
nunez wrote: post #73

Chef was acquired for $220M cash. According to Crunchbase, Chef raised $105M total up to a Series E. Investors aside, did anyone make money here? Either way, I’m glad that they are continuing to exist. Chef was onto something with Habitat and (especially) InSpec.

It depends on the price they paid for stock or the exercise price for stock options. If you were an early employee and your received options when the company was only worth $10m or something low, you could make money. The risk is that one of the later investors had a ratchet or something that would allow them to claim more of the proceeds in a sale. You can't just take $220M cash, subtract $105M in funding and pass t…

I figured there were one or more investors participating preferred especially since Chef held most of their valuable IP as an open source project.

Re: Chef to be acquired by Progress

#106

Post by zedfoxus »

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 treated as a second/third class citizen even though I felt SQL was an exceptional way to use OpenEdge with other languages. If there were valid technical reasons to not use SQL, I didn't hear it from 4GL devs or Progress management.

To be fair, 4GL and OpenEdge work very well together.

Re: Chef to be acquired by Progress

#107

Post by nunez »

geerlingguy wrote: post #83
TinyRick wrote: post #60

Earlier quoted context omitted.

I disagree that it's "long dead". Keep in mind that Chef (the company) has several different products too...Chef Infra (traditional configuration management) has fallen out of favor and Ansible seems to be the popular choice these days, but there are still a lot of big Chef Infra shops (e.g. Facebook [0]) that have invested heavily into configuring their environments using Chef Infra, which would require a good bit o…

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.

Holy shit; if /u/geerlingguy hasn’t heard of Hab or InSpec, then Chef really could’ve done a better job marketing them. (This user is very well known in the config management space.)

Re: Chef to be acquired by Progress

#108

Post by zedfoxus »

vander_elst wrote: post #4

What is the product offering of Progress? Quickly went through the website.. not sure, but it sounds more like smoke and mirrors..

OpenEdge is their DB. It has 1 storage engine but 2 ways to get to it: SQL and 4GL. If you write SQL, OpenEdge is relational DB. If you write 4GL, OpenEdge isn't relational unless you write relationship on application layer. Yeah, it's interesting.

4GL (aka ABL or Advanced Business Language) is the language that works best with OpenEdge. You write 4GL code, compile and deploy it to a specialized Tomcat environment called PASOE (Progress Application Server for Open Edge). It's their container to run 4GL apps.

WebSpeed is their middleware to serve APIs using 4GL code. Companies stuck in the desktop world are using WebSpeed to refactor their code and expose business logic to other languages through WebSpeed API middleware.

They acquired Telerik some time back. Those controls are used by .NET web devs and desktop devs. They are cool controls. I like them. Telerik controls are also integrated with their 4GL desktop environment. Kendo UI are tools/controls for the web and are pretty neat as well. Fiddler is also their product now.

DataDirect is a suite of connectors to make it easy for devs to connect between different DBs from 4GL, and for other languages to use DataDirect to connect to OpenEdge or call 4GL methods.

Corticon is their version of Dell Boomi or Alooma or Prismatic.io. It's a tool to run business processes with no code or low code. It's neat if you have tech savvy business analysts who like to use tools like that.

Sitefinity is their version of WordPress/Drupal/content frameworks. Sitefinity has its place.

NativeClient is their product to build mobile-first application across various platforms. They whipped up a neat app at their conference and it really worked well. Yes, it may have been cowboy-coded a bit, but it worked as intended.

Now they acquired Chef. I am sure there was a demand for orchestration within their client-base. They are making improvements steadily. They have a strategy. They have a niche target market, primarily in LATAM and EU and less so in North America. They do not have a great version control, static analysis, dynamic analysis, orchestration tools. Companies like Intuit and Fiserv seems to have built their own ecosystem around 4GL tools, but many companies just have primitive means of development with 4GL, still. Progress is trying to stay current. Their customers are much slower at adopting to changes in engineering; perhaps what they have just works for them. Not sure.

Acquiring chef is a good move. I've worked with their products for 2-3 years. It wasn't fun. I don't like 4GL. I'd like if Progress made SQL a first class citizen and invite PHP/Python/Ruby/etc. communities to write code against OpenEdge. From a business standpoint, I feel they are trying their best to stay modern and relevant. They are acquiring products that are indeed making their ecosystem cohesive.

Re: Chef to be acquired by Progress

#109

Post by fooqux »

xorcist wrote: post #102
fooqux wrote: post #76

Earlier quoted context omitted.

> Puppet is a great tool for managing containers, and so is Chef. Eh. While I won't say that it can't be used, I will argue that it's not the best tool for the job. I wouldn't call it a "great tool" for that purpose, although I suppose that depends on your workflow. I prefer to take the approach that containers are immutable once built. If you want to change the container, fine- make your changes, build a new instanc…

Not sure what the argument here is. Different builds for prod, qa and test? Even if that was workable, which is a question in itself, there is still configuration outside the packaged application. AWS keys, metrics and logs, dashboards, that sort of things.

Well, the container manifest (or whatever you call it) is checked into version control. How you choose to deploy that is up to you, but a ton of CICD tools out there are made for just that purpose.

Likewise, how you separate config data and deploy to production is an age old problem with many solutions as well. Sure, Puppet can even be a solution here, but you're just kicking the can down the road. How do you separate your Puppet code from data? Put it in Hiera? OK, how do you promote Hiera? It's the same issue.

Both of these issues were solved long ago before Puppet came along, and what we all learned from back then still applies: separate your data, config, and code. Version control as much as possible. There are many simple solutions that don't require Puppet. Hell, set up a bind mount to an external config store. Or something fancier like your CICD tool bundling the config data and signing it with a cert that only a certain environment can use so you never get dev code running in prod.

The argument is that when your infrastructure is immutable (which is the direction most of us are going) you don't need a tool to manage the configuration of said infrastructure. Because it can't change. When you do want it to change, you just follow the typical code SDLC and use the powers of version control and CICD.

Post reply on HN