That’s absolutely right, but I think it illustrates one of the problems with inventing your own tech stack, is that it might make perfect sense when you start the project, but several years down the road it might just be an inferior version of an open-source project.

My personal sense is that this even applies to stuff like Borg, but who knows?

You can't really predict the future if a large tech company will properly fund an open source project to reproduce what they have internally, and if that will be any good in time, especially if none of it exists. In the mean time, you need a solution to problem X.

I've even written a few libraries like that, and still stuff out there isn't that good or does not exist years later, because it's too niche, yet still a generic issue in the industry. Can't open source it although.

In an alternative timeline, Buck for example could of been the OSS solution that google decided to devote their resources to, and then in the end it would of been a good idea that FB created their own version of it.

To be clear, what I’m saying is that “this is a problem with reinventing stuff”, I’m not saying “you shouldn’t reinvent stuff.”

You think Borg might be an inferior version of Kubernetes?

It will be.

Mind you, Kubernetes was originally made written at Google by engineers that previously worked on Borg. So they will naturally design it to address problems with Borg. Kubernetes’s original project code name was “Seven of Nine”, because Seven of Nine is a friendlier Borg.

Just because someone subsequently writes another program, that does not assure the superiority of the later edition. People who wrote Borg thought Omega was going to be better, but Omega failed except for a few things that got cherrypicked back into Borg.

I particularly can't agree that k8s is a necessarily friendlier Borg. Borg is on rails; there are fewer choices for the user to make. K8s tries to be flexible enough to be used in various production environments, which leads to it being harder to use rather than easier.

Some of the flexibility decisions for k8s come from Omega and are mentioned as impossible to backport to Borg.

Sometimes you also get issues on k8s where a google engineer responds "it's not done yet because we really, really don't want to repeat what a fiasco it was under Borg".

So I'd say it might be better even in direct comparison ;)

I imagine part of the perceived usability problem comes from the fact that often users of k8s are also playing the role of borg-sre, whereas 99% of borg users do not need to deal with that.

Sure, and to be clear, when I say “it will be” that it’s little more than a guess on my part.

Google has enough project churn internally that services and programs do stand a good chance of getting replaced, though. There’s plenty of history.

It seems like you might be under the impression that bazel and blaze are not the same codebase?

If Google made a good build system with features not available in open source, eventually open-sourced it, continue to use it, and lots of other people are eager to use it, how does that demonstrate that they shouldn't have invented a build system?

I guess the comment wasn’t clear enough, because that’s absolutely not what I was saying.

“Problem with X” is not the same thing as “you should not do X”.

I’m also not getting why you think that I’m ignorant of Bazel’s origins, specifically, since I was talking about Borg.

You'd replied to a comment about build systems and bazel.

Regarding Borg vs k8s, it's worth noting that k8s was never built to replace Borg or to even try to match the feature set of Borg. There are some nice things about k8s (like the ease of running an entire cluster on your local machine), but since k8s tries to be all things to all people it's not even close to being viable (or competitive with what Borg can do) for Google itself.