2 ms·
Their product seems to be offering "buildkit as a service" and I'd guess from their perspective the safest isolation boundary is at the VM level. Unknown why th
by mdaniel 1y ago
Their product seems to be offering "buildkit as a service" and I'd guess from their perspective the safest isolation boundary is at the VM level. Unknown why they don't boot up a bigger .metal instance and do their own virtualization but I'm sure there are fine reasons
- jacobwg 1y agoWe also do GitHub Actions runners as a service, so a very high volume of differently-sized ephemeral VMs. We’ve experimented with .metal hosts, however they represent a bin-packing optimization problem, in that you will always be running some amount of spare compute / trying to fit the incoming build requests to physical hosts as tightly as possible. Eventually you realize, IMO, that doing the bin packing yourself is just competing with AWS, that’s what they do when you launch a non-metal EC2 instance and it’s best to let them do what they’re good at. Hence why we’ve focused on optimization of that launch type, rather than trying to take over the virtualization. There’s other security and performance reasons too: AWS is better at workload isolation than we can be, both that the isolation boundary is very strong, and that preventing noisy neighbors is difficult. Especially with things like disk, the strategies for ensuring fair access to the physical hardware (rate-limiting I/O) themselves have CPU overhead that slows everything down and prevents perfect bin-packing.