sccache[1] is a similar project, which supports remote execution and caching for C, C++, and Rust. Unfortunately the remote-execution mechanism is designed for Mozilla's internal environment and doesn't support cloud backends like Lambda or Google Cloud Build. But the code is well-structured Rust and not too big, adding a cloud backend would be a nice project.<p>[1] <a href="https://github.com/mozilla/sccache" rel="nofollow">https://github.com/mozilla/sccache</a>
I was considering buying a new dev machine a few months ago. I'd been hearing great things about the new Ryzen chips with 16+ cores, but then I saw the price tag and thought about what percentage of the time I'd even be fully utilizing that many cores: probably less than an hour or two a day, on average, if that. And then there's the cost of powering it. It would be much less expensive up front to just spin up a VM in GCP and suspend it when I'm not coding. The trick would just be making the experience as seamless as possible (maybe build an LSP proxy that automatically suspends/resumes the VM?). Nelson seems to be solving the build performance issue with llama, but I'm curious about running LSP servers in the cloud.
Very nice! I really like the ease-of-use of this, as well as the scale-to-zero costs. That's a tricky thing to achieve. Seems like it could become a standard path to ease the migration from local to remote builds.<p>If the author is interested in standardizing the same, I'd suggest implementing the REAPI protocol (<a href="https://github.com/bazelbuild/remote-apis" rel="nofollow">https://github.com/bazelbuild/remote-apis</a>). It should be amenable to implementing on a Lambda-esque back-end, and is already standard amongst most tools doing Remote Execution (including Bazel! Bazel+llama could be fun). And equally, it's totally usable by a distcc-esque distribution tool (recc[1] is one example) - that's also what Android is doing before they finish migrating to Bazel ([2], sadly not yet oss'd).<p>The main interesting challenge I expect this project to hit is going to be worker-local caching: for compilation actions it's not too bad to skip assuming the compiler is built into the container environment, but if branching out into either hermetic toolchains or data-heavy action types (like linking), fetching all bytes to the ephemeral worker anew each time may prove to be prohibitive. On the other hand, that might be a nice transition point to switch to persistent workers: use a lambda backed solution for the scale-to-0 case, and switch execution stacks under the hood to something based on reused VMs when hitting sufficient scale that persistent executors start to win out.<p>(Disclaimer: I TL'd the creation of this API, and Google implementation of the same).<p>[1] <a href="https://gitlab.com/BuildGrid/recc" rel="nofollow">https://gitlab.com/BuildGrid/recc</a><p>[2] <a href="https://opensource.googleblog.com/2020/11/welcome-android-open-source-project.html" rel="nofollow">https://opensource.googleblog.com/2020/11/welcome-android-op...</a>
This is a pretty interesting project, a low setup distributed build cluster is cool. That said I find the arguments against Bazel pretty weak. Yes with a distcc model you can scale out the compilation stage of C++ project quickly, but what about the test execution, linking, ProtoBuf code generation, or caching? In either case, Bazel or Llama you have to make your build system aware of how these actions work in some way in order to distribute or cache them.<p>The difference is with Bazel you also gain a suite of solutions for large software projects like container creation, target visibility control, isolation, dependency fetching, and build graph analysis. Also with the larger community behind Bazel adopting it for a large project is getting easier over time.
I haven't checked, but I'm willing to bet that the costs for a one-time Fargate task and Lambda are similar enough that Fargate will be vastly simpler. Both can use containers, but Fargate is more explicitly built to just run a container without managing any server. And there's EKS Fargate, too.<p>Fargate Spot pricing is $0.012144 (vCPU Hour) + $0.0013335 (GB hour) + $0.000111 (Ephermeral Storage hour). Pricing is per second with a 1-minute minimum. So for one hour of compiling on 1 vCPU, 1GB ram, 1GB storage, that's $0.0135885, to run any old Docker container.<p>Lambda cannot execute for longer than 900000 milliseconds, or 15 minutes. For 15 minutes at 1GB for 1 request, that's $0.02. For 4 requests (1 hour) that's $0.06.
<i>forty cents buys you about 10 minutes of on-demand compute on a 96-core c5 instance</i><p>This is incorrect. 48 cores, 96 threads.<p>vCPUs mostly refer to threads, not cores. There are some exceptions. More here...<p><a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-optimize-cpu.html" rel="nofollow">https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance...</a><p>...and here (which is inexplicably missing the c5.24xlarge):<p><a href="https://aws.amazon.com/ec2/physicalcores/" rel="nofollow">https://aws.amazon.com/ec2/physicalcores/</a>
I think there's a bit of oversimplification going on. Sure, free, or almost free, stuff is available everywhere. But at what cost?<p>How much work do we have to do to get this "free" thing? What privacy do we give up? What if we're working on something that's part of a product, or otherwise proprietary?<p>The idea that everyone is doing it, so we should stop being sticks in the mud and just jump on the bandwagon, is harmful and ignorant.<p>"My data has never been stolen from the cloud" is about as ridiculous as the fortune quote, "As far as we know, our computer has never had an undetected error." How would you know until it's way too late?<p>Or, even better, you find out the data you've used in the cloud has been leaked on the Internet. Was it AWS? Was it crappy software on your laptop? Or was it a breach on your network? You've just made finding out that much harder, particularly because the cloud doesn't have logs that you can audit, nor real, understanding humans with whom you can correspond.<p>People who don't understand security can't really be faulted for eschewing the idea of using the cloud for everything, but people who know better really shouldn't be pushing these unhealthy ideas.