3 ms·

I agree to a large extent. But specifically in the case of - using bazel instead of make - using a monorepo ever - using Google-style canary deployment ever

by mlthoughts2018 8y ago

I agree to a large extent. But specifically in the case of - using bazel instead of make - using a monorepo ever - using Google-style canary deployment ever I think they are just nearly totally objectively bad ways to solve problems whether at Google scale or otherwise, with obvious alternatives that are strictly dominating in the sense of being unilaterally better in all use cases. These techniques have to be kept afloat with the money faucet. I guess I can agree that if you have enough money that you can offer pay packages that cause people to be willing to endure the hardship of propping bad systems up, then you don’t have to care about what systems are effective. For example, you could shoot lots of holes in a boat and then hire a full time staff on $500k / year to scoop water out fast enough that the boat seems to operate just fine. Then get the ACM to write a big publicity piece about how hole-filled boats are the best design and anyone not shooting holes in their boat is Doing It Wrong. This is not even exaggeration to offer as an analogy to Google’s combo use of monorepos + bazel.

londons_explore 8y ago
Bazel is designed for big projects and distributed compilation. Unless your company has >500 engineers, it isn't going to make sense. I like monorepos - and in my experience you don't need special tooling for them until you have thousands of engineers. I just don't really see the point in splitting all my business logic into 50 different repos all of which have 25 branches and then I'm having versioning, dependency, and incompatibility hell between them. One repo, one 'master' branch, lots of tests, and as soon as all tests pass, auto-deploy! The 'canary deployment server', complete with webUI I think is a mistake, even for Google. If they were using kubernetes, it would have a 'Deployment' object, and canarying should be a feature of that, just like rolling updates are. Actually how that works is an implementation detail of kubernetes and is abstracted away.
- gerash 8y ago
  I've used Unix make for personal projects (during and after school) and bazel at work. "bazel" is more about type checking the build artifacts, caching and guarantees about hermetic and reproducible builds. The distributed compilation is just supported but not a requirement IIUC. idk if it's the best tool but definitely an upgrade over "make". Whereas "make" looks like an old pseudo scripting utility which has too many degrees of freedom with not much guarantee and is fragile as a result. I think those who learned its quirks love it but I don't. I've also liked mono repos at work as long as their operations are not sluggish. They immensely help global refactoring, static analysis and reduce the amount of merge conflicts.
berdario 8y ago
- I'm not sold on Bazel (I'm more of a Nix person), but hermetic builds are obviously a good idea - You don't need the added complexity of having to manage tooling to track dependencies across multiple repos. A single repo is just fine. You'll obviously want to split off repositories when you want to contribute stuff as open source, and in other cases http://danluu.com/monorepo/ http://danluu.com/monorepo/ - what you describe as "Google-style canary" is not actually Google-style or recommended by Google See the SRE workbook: https://landing.google.com/sre/workbook/chapters/canarying-releases/#use-a-gradual-canary-for-better-metric-selection https://landing.google.com/sre/workbook/chapters/canarying-r... (obviously, Google is big, so different teams might do things differently)
- mlthoughts2018 8y ago
  Whether using a monorepo or not, you should be creating versioned artifacts that are stored in a separate artifact repository, and different sections of your codebase (whether sharing the same repo or not) should express dependency via consumption of versioned artifacts from the artifact repository. As a result, sometimes you can even require _more_ tooling to adequately handle dependency in a monorepo vs multiple repos. When you consider that a default natural constraint of all software development is that it must adapt and cope with changing tools, usage demands, etc., then it quickly becomes important to allow any given project to use arbitrarily unique build tooling, deployment tooling, libraries, languages, databases, etc. Trying to shoehorn them all into a mandated set of monorepo tooling just doesn’t work, once again meaning you often need much more tooling to reach minimum required levels of flexibility with monorepos as compared with polyrepos.
  - joshuamorton 8y ago
    There's no reason to rely on versioned artifacts as dependencies if each binary bundles all deps. This is what bazel does. In practice your second complaint about tooling isn't particularly true. Android apps, webservers, and language runtimes live in the same repo without issue.
    - 8y ago

londons_explore 8y ago

Bazel is designed for big projects and distributed compilation. Unless your company has >500 engineers, it isn't going to make sense. I like monorepos - and in my experience you don't need special tooling for them until you have thousands of engineers. I just don't really see the point in splitting all my business logic into 50 different repos all of which have 25 branches and then I'm having versioning, dependency, and incompatibility hell between them. One repo, one 'master' branch, lots of tests, and as soon as all tests pass, auto-deploy! The 'canary deployment server', complete with webUI I think is a mistake, even for Google. If they were using kubernetes, it would have a 'Deployment' object, and canarying should be a feature of that, just like rolling updates are. Actually how that works is an implementation detail of kubernetes and is abstracted away.

gerash 8y ago
I've used Unix make for personal projects (during and after school) and bazel at work. "bazel" is more about type checking the build artifacts, caching and guarantees about hermetic and reproducible builds. The distributed compilation is just supported but not a requirement IIUC. idk if it's the best tool but definitely an upgrade over "make". Whereas "make" looks like an old pseudo scripting utility which has too many degrees of freedom with not much guarantee and is fragile as a result. I think those who learned its quirks love it but I don't. I've also liked mono repos at work as long as their operations are not sluggish. They immensely help global refactoring, static analysis and reduce the amount of merge conflicts.

berdario 8y ago

- I'm not sold on Bazel (I'm more of a Nix person), but hermetic builds are obviously a good idea - You don't need the added complexity of having to manage tooling to track dependencies across multiple repos. A single repo is just fine. You'll obviously want to split off repositories when you want to contribute stuff as open source, and in other cases http://danluu.com/monorepo/ http://danluu.com/monorepo/ - what you describe as "Google-style canary" is not actually Google-style or recommended by Google See the SRE workbook: https://landing.google.com/sre/workbook/chapters/canarying-releases/#use-a-gradual-canary-for-better-metric-selection https://landing.google.com/sre/workbook/chapters/canarying-r... (obviously, Google is big, so different teams might do things differently)

mlthoughts2018 8y ago
Whether using a monorepo or not, you should be creating versioned artifacts that are stored in a separate artifact repository, and different sections of your codebase (whether sharing the same repo or not) should express dependency via consumption of versioned artifacts from the artifact repository. As a result, sometimes you can even require _more_ tooling to adequately handle dependency in a monorepo vs multiple repos. When you consider that a default natural constraint of all software development is that it must adapt and cope with changing tools, usage demands, etc., then it quickly becomes important to allow any given project to use arbitrarily unique build tooling, deployment tooling, libraries, languages, databases, etc. Trying to shoehorn them all into a mandated set of monorepo tooling just doesn’t work, once again meaning you often need much more tooling to reach minimum required levels of flexibility with monorepos as compared with polyrepos.
- joshuamorton 8y ago
  There's no reason to rely on versioned artifacts as dependencies if each binary bundles all deps. This is what bazel does. In practice your second complaint about tooling isn't particularly true. Android apps, webservers, and language runtimes live in the same repo without issue.
  - 8y ago