holoway

I’m Adam Jacob (the quoted person in Matt’s article). Happy to answer questions :)

Every thread here about how it’s vanity is bananas. They’re going to build computers! With software to go with them! So that you can have the same experience that the hyperscale companies do. It’s a great bet.

This isn’t a blitz to help with fundraising: they already have the money.

They are also hiring - which is why they have a long list of principles and values, and talk about each other. They’re looking for kindred spirits.

This is a good idea, from people with a history of good ideas.

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.

They aren't claiming to make it open source - they are making it open source. I explain my perspective on the motivation here: https://medium.com/@adamhjk/goodbye-open-core-good-riddance-...

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.

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.

Happy to answer questions about it, if anyone has any. :)

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.

I think we agree (and it's probably self evident) that it's hard but necessary work to try and get the boundaries right, and it requires a lot of refactoring before things stabilize. In the early stages of work, that refactoring is frequent and often deep. Later, it (usually) becomes infrequent and shallow.

I think it's important to separate internal dependencies from external ones. My personal advice is to treat external dependencies in whatever way the language prefers, and upgrade on a cadence. This is because you can't have any real impact on your external dependencies - even if they are critical, you can essentially treat them as a black box for terms of this conversation. For the rest of my response, lets assume we're talking internal dependencies.

The thing about breakage "for no reason" is that you are still broken, you just don't know it yet. One assumes the team that broke you had a reason. It might be a good or bad reason, from your point of view, but it wasn't no reason. When I talk about forcing the conversation, this is why. It's not better to hide from the changes, or pretend that you are safe. You aren't. All that happens is you move the time between when the breakage was introduced, and when you discover it. Most frequently, that discovery happens when the upgrade becomes critical (security) - and the time to apply the change has gotten longer, and the team who made the breaking changes no longer remembers clearly the drift. This makes teams even more less likely to move.

By ensuring these types of changes hurt, and are understood to be a shared responsibility (the consumer has a responsibility to move, the producer has a responsibility to understand and protect the stability of their consumers), teams have the impetus to design and build systems that ensure their stability. It's one thing to ask for things like circuit breakers, backwards compatible interfaces, etc. It's all theoretical from a single engineers, or single teams, point of view. It's not a panacea, but when the contract is structured this way, everyone adapts to the issue: producers get more defensive, consumers get less debt.

Like I say in the original, I think this comes down to perspective. When my concern was primarily the efficiency of a single team, who was small enough to stay connected through conversation and shared understanding, it matters way less.

A lot of your reply comes from the perspective of wanting, as an engineer, to just Get Things Done again. I get it, and I'm sympathetic. It is harder to work this way, because you can't take the easy shortcuts (pinning, delaying the upgrade, ignoring your consumers, etc.) - but that's precisely the point. Those things are bad in the long term.

Disclaimer: it depends. :) Since that's not a good answer at all, I'm going to write the rest of this as if I have the answer, even though I know I do not, because it's deeply situational.

Equal care does need to come from the other side of the contract. Most frequently, I see teams B, C, and D in a polyrepo world do the worst of all worlds: take dependencies liberally, pin them in place, and try to forget about them. Of course, high functioning engineering teams (and cultures) will try and avoid this: they will be thoughtful about dependencies, and they will keep them up to date. In practice, they most frequently do not. This is especially true in the enterprise broadly. When we get it wrong, and take a dependency we wish we hadn't, how do we know? When do we know? What is our recourse? If I depend on code in the monorepo that diverges, I'm more likely to know near to the point of divergence (because of the nature of the system). That means the conversation about how to fix it happens sooner. I'm not interested in avoiding error - that's going to happen. I'm interested in how close to the introduction of the error do we understand it, and how do we communicate about its remediation.

As far as CI and global coordination goes, the cost is high in either direction if the system is distributed, and the solutions are similar in my experience. I think the worst case is the mixed one (which is a world I inhabit) - you wind up splitting your investment in both style and effort across both approaches. With the monorepo style, one big advantage is where the complex CI interactions can be encoded, since you have access to more of the code itself. Granted, at scale, you likely are testing against artifacts rather than point in time commits outside of the component in question (this is very similar to what you're going to do in a polyrepo, too.)

I think solid testing design requires real effort and understanding of the system under test, regardless of repository layout. Which brings us back to communications again. The more you can see, and the more clearly experienced the pain is across the teams, the more likely you are to have the critical conversations needed to improve the system - rather than making local fixes ("my teams tests are fast", "their component sucks").

Author here. The Right Way :tm: is situational - there isn't one right answer to things like when and how to make contracts, or how to break them. When I used the term "force", you'll see that I'm usually talking about dialog between people and teams.

It's not that it's a single right way to do it. There isn't, and anyone who tells you there is has something to sell you, or is inexperienced enough to not have seen enough of the problem domain.

What is for certain: teams need to have tooling that causes the conversations and behavior that lead to the outcomes we want. As systems and teams scale large enough, this tooling becomes essential - without it, teams go their own way, and in so doing, may or may not create the culture needed for the outcomes you want.

I have never once in my career, so far, had to tell a team to communicate less. When we're talking about engineering organizations that are large enough to diverge, you must solve these problems somehow, and it needs to be systemic and intentional.

Habitat uses some simple data structures that are basically CRDTs. We used them because they made the user experience better (not needing infrastructure other than the gossip itself). One thing I learned early on that journey was that the more specific your use case, the easier a fully distributed model is. As soon as you need generic primitives a-la etcd or zookeeper, everything gets orders of magnitude harder.

Sure. Habitat's supervisor is a very low-level thing - it manages the lifecycle of your service, participates in the gossip ring, etc. That means a failure at runtime of the supervisor is pretty unacceptable, and similarly, you don't want anything (like a long GC pause, for example) to get in the way of the supervisor doing what it needs to do.

Rust gives us 3 things we needed, and it says so right on the website: fast, no segfaults, thread safety. Additionally, it's community is top notch. We've found the language to be great to work with, especially when you're refactoring. The type system makes it clear where it's possible for the code to fail, making it easier for us to reason about keeping the supervisor safe.

I wrote this while I was evaluating languages for the early habitat prototypes: https://medium.com/@adamhjk/rust-and-go-e18d511fbd95#.d35imt...

Best, Adam

We're totally going to do it.

We struggled with this! I think we found the right balance, but time will tell.

Nope! You can use it with docker, and we think it makes the experience better. We love docker.

This is Adam - Rust has been amazing to work with, and was the prefect choice for this platform. It's great.

Ezra was so good to me. He helped write Chef, tool our idea and ran with it as a critical part of Engine Yard cloud. We wrote chef solo together . He and his wife made my wife and I feel warm and welcomed in San Francisco. Rest well, big guy.

From my (admittedly super ignorant position) it felt very similar - message passing, spawn, etc. The primitives felt very similar. I'm sure they differ hugely in details ;)

Yeah, I was doing this for fun. I'm pretty secure in my day job. :)

It's absolutely lightweight. First impressions for sure, writing what were very small programs. I tried to be clear about that. :)

I am absolutely quite (completely) new to both languages.

Also, Pallet is sweet - I (Adam Jacob, one of the authors of Chef) have talked with Hugo, looked at the code, and played with Pallet. It's good sauce, and it's not quite the same kind of beast as Chef/Puppet. It's much more like what the logical conclusion of tools like Capistrano and Func/Fabric hope to be when they grow up.

It's also super fun to use, partly because Clojure is a great language.

As one of the founders of Opscode, and of Chef, it's crazy to say that the reason we started Chef was because we didn't want to buy a support contract.

We have no beef with Puppet - from our experience building fully automated infrastructures at scale, it wasn't the tool we wanted (and it still isn't,) so we built Chef - the tool we wanted. It turns out it's also the tool lots of other people wanted, and we're incredibly proud of it.

There is nothing dirty here, no matter how much the internet wishes it to be so.