MongoDB's engineering team writes about database internals, storage engines, build tooling, CI systems and developer workflow at the company.
HN commenters link it for the story of switching from SpiderMonkey to V8 and back, and for the post explaining why MongoDB built its own CI system instead of using Jenkins.
Well, I'll be the first one to admit that I was naive to expect <5% variance prior to this experience. But I guess you are going to far by framing this as a common wisdom?
In the HN discussion about cockroachdb cloud report 2021 (https://news.ycombinator.com/item?id=25811532), there was only 1 comment thread that talks about "cloud weather".
In https://engineering.mongodb.com/post/reducing-variability-in-performance-tests-on-ec2-setup-and-key-results, high profile engineers still claimed that it is perfectly fine to use cloud for performance testing, and "EC2 instances are neither good nor bad".
Of course, both the cockroachdb and mongodb cases could be related, as any performance variance at the instance level could be masked when the instances form a cluster, and the workload can be served by any node within the cluster.
> Is there a comparison to Jenkins available?
Not exactly, but we published a blog post about why we took the time to write a new CI system, and that post does touch upon why we didn't use Jenkins + plugins.
https://engineering.mongodb.com/post/evergreen-continuous-integration-why-we-reinvented-the-wheel/
Interestingly, MongoDB switched from SpiderMonkey to V8 only to switch back a few releases later.
https://engineering.mongodb.com/post/code-generating-away-the-boilerplate-in-our-migration-back-to-spidermonkey