分布式云为每个人构建

CPU周期比以往任何时候都便宜，云计算从未如此无处不在。所有主要的云提供商都提供宽大的免费层，以及GitHub操作等服务为开源存储库提供免费计算资源。那么为什么这么多开发人员仍然在笔记本电脑上建立软件？

尽管有丰富的廉价甚至是免费云计算的尴尬，但我所知道的大多数项目以及大多数开发人员仍然可以直接在其本地机器上进行大多数软件开发 - 建设和运行代码。云构建 - 他们分发，或者只是在大于你前面的机器的单个巨型实例上运行 - 在大型，复杂的组织内部相对普遍，但为单个开发人员，开源项目或较小的操作罕见。

最近，我在使用AWS Lambda和我的骆驼项目中在90秒内扮演LLVM。今天我想分享Llama设计背后的更大愿景，为什么我认为Llama的方法最终可以使分布式云建立普遍访问，甚至更小的开源项目和个人爱好者开发人员。

我相信骆驼的设计 - 由AWS Lambda大部分启用 - 可以消除最重要的障碍，以使用云编译。通过更新的成熟和实施工作，我认为它有可能使云构建几乎是各种开发人员的默认值，而且我对此未来非常兴奋。

让我们来看看这样做的功能和设计决策。

骆驼使用便宜，并且在您没有积极运行建筑时，几乎没有成本。

我的LLVM Build成本约为0.40美元。如果您使用EC2直接使用EC2，请在96核心C5实例上为您提供大约10分钟的按需计算。我没有基准测试，我估计该实例可能会在大约3分钟内构建LLVM。在纸上使Llama能够更加昂贵3次...但只有当您设法启动和停止EC2实例时，只需在您需要时才。如果你要留下那个例子，而闲置甚至一个小时，那么赶到骆驼才能难以置信。另一方面，当您没有进行构建时，骆马会自动缩放，而Lambda令人印象深刻的冷启动性能意味着当您需要时始终存在。

此外，Lambda透明地缩放到中间利用水平。如果您只有仅构建的增量重建，例如源文件的10％，则Llama的成本将是整体构建的10％，没有额外的调整或配置。

因此，骆马不仅与EC2最佳案例有竞争力，而且开发人员更简单地管理，并消除离开实例的风险并用3000美元的账单（C5实例的粗糙的月费）陷入困境。

当你没有运行构建时，骆马总是成本（几乎）没有任何东西。如果你只做一个月，你仍然只支付每月几美分。如果通过比较，将保留暂停的C5实例，您可能会使用EBS磁盘，费用为8¢/ gb-mo。如果您围绕大型构建树，则可以自行加起来，但更重要的是，它更重要地为不常见的用户创造了认知开销：何时值得保留您的实例，以防您需要做更多的构建，并且何时值得转换它可以节省一些雄鹿，以更高的启动时间和配置成本下次想要它的成本

如果您正在使用云实例来构建软件，请以某种方式您必须将代码达到它。两个最明显的选择是：

保持源结账远程，并使用SSH或类似VS代码的远程开发的内容开发

在本地保持结账，并使用rsync或类似于将源复制到云中，并将工件返回到笔记本电脑。

任何一种选项都会对您的工作流程施加了更改，要求您单独思考本地和远程计算机，并将工作分配到两种机器之间至少一定程度。如果您执行第一个选项，即使您没有执行任何构建，您也必须在执行开发或阅读代码时支付DEV机器。

相比之下，LLAMA利用S3和文件级缓存，以透明地和按需移动工作站和Lambda之间的各个文件和伪影。您可以在本地开发，并以完全相同的方式运行，您可以在没有骆驼的情况下完全相同。一切正常工作完全相同，除了你的构建更快！

骆驼的方法是明确的，有一些缺点。它比需要较少的网络往返更少的系统慢，它会增加对实现的复杂性。它还使构建取决于您的工作站的网络速度;从慢速无线连接构建可能最终在带宽而不是计算上的瓶颈。尽管如此，我强烈地相信这一选择，因为我认为呈现完全透明的用户体验，并要求尽可能小的行为改变了巨大的力量。

一些构建系统 - 最常见的谷歌的Bazel - 本身支持透明的远程构建执行。但是，访问此功能要求您在Bazel中重写您的项目整个构建（除了运行或查找远程构建执行程序的成本和复杂性）。这是一个相当相当大的任务，因为Bazel非常严格，非常自以为是。而且，即使您取得成功，您的少数用户也将安装Bazel，其重量级依赖项将危害许多潜在的用户和贡献者。

Llama使用Classic DistCC范例来为编译器（GCC或Clang）提供替换（LLAMACC），并依赖于构建系统自己的并行性1.此方法允许它在那里几乎所有C和C ++构建系统，开箱即用，大惊小怪。

专门化，比如cmake或ninja可能更加表现 - 在未来可能仍然有意义 - 但在这里，我也在骆驼的设计中优化了广泛的采用和新项目的低障碍和新的开发人员。

我试图设计Llama需要尽可能少的配置;最终目标是，使用一个或两个命令，您可以使用镜像本地桌面的云编译环境设置Llama，并在任何和所有项目中使用该图像。

AWS和基础架构的技术在很大程度上通过AWS和基础架构的技术启用了此功能，这让我定义了一个单个CloudFormation模板，该模板在一次下降时设置所有Llama的主要依赖项。我还提供了工具，以帮助构建编译器工具链和管理本地节点和云环境之间的系统标题，但这是Llama可能更加抛光的另一个地方。 AWS Lambda最近的Docker支持 - 在我第一次建造Llama的时候宣布 - 在这里帮助，让Llama开发人员和用户使用标准化和广泛理解的Docker图像和Dockerfiles来构建编译器图像。

几十年来，技术人员谈到了“效用计算” - 计算为计量，按需服务的愿景，与我们认为电力或运行水作为实用性的方式。

现代云时代被许多人作为实现这一愿景的认识，其中我们租用时间（最近，最近，第二次），几乎没有人拥有他们的在比例下拥有自己的硬件。

但是，云环境仍然相当涉及配置和运营，并倾向于要求用户的大量专业知识。对我来说，在运行计算的行为 - 使用云的全部功率和比例之前，效用计算的愿景永远不会完整，至少就你愿意付钱 - 大约是简单而无忧无虑的打开你家的龙头进行淡水。

骆驼是我努力实现这一愿景的 - 至少 - 软件构建的具体问题。谢谢亚马逊兰德，以及云技术的一般进步，我相信我们终于达到了具体实现这一愿景，我希望我们能够做到这一点。

也就是说，要清楚，骆马还没有完全实现这一愿景。这是一个年轻的项目，少数用户还有我，而且很多锋利的边缘和粗糙的角落。但是，我认为结果如我的LLVM构建性能 - 在那里优于一些最大的机器可以买到的东西可以买到这一方法，即这种方法是可行的，如果我们推动它就可以成功。

我已经谈到了这里的软件在这里构建，因为这是一个域，我对我很熟悉，而且因为这是我选择用LALLLEACC解决的那个。但是，我认为这里的愿景可以超越构建软件。我想到了一个世界间交互方式执行的大多数计算密集型任务，无缝地将云点燃，同时保留用户体验，好像所有数据都在本地可用。

作为可行性的另一个具体示例，在GG纸之前，同一团队展示了Excamera，它以类似的方式使用Lambda来执行视频编辑和转码。在该项目之间，GG和Llama之间，我觉得我们已经证明了愿景具有广泛的可行性;现在我们只需要完成建造它！

特别是在当今的多夜世界中，任何值得谈论的构建系统都有一些方法可以使用多个核心运行构建，这些内容经常由构建在其顶部的开发人员进行。 ↩︎