我们最近一直在与机构合作，将他们现有的项目从自定义、共享和集群的 LAMP 堆栈迁移到 Pantheon 平台。在实践中，这个过程 95% 是取证的。您不能依赖命名约定或第一次出现，只能手动跟踪 DNS 到 Apache 虚拟主机配置到 webroot 到配置文件。不过，为什么基础设施会以这种方式结束是很清楚的：不同的站点对规模和可用性有不同的需求，我们在过去通过将每个站点与一些具有相似需求的群组一起部署来实现这一点。我们建立 Pantheon 是为了改变这种状况，并且在这个过程中我们发明了一些非常巧妙的技术。
万神殿之路
如果您以旧方式做事，您会注意到关于 Pantheon 网站启动的第一件事是，我们不会在您创建网站时让您陷入关于网站底层基础设施的艰难决定。您需要做的就是为站点命名并选择 Drupal 或 WordPress。它是需要一个简单的堆栈还是一个大型集群是以后的决定——而且很容易改变。
将 90 年代的架构转移到云服务器上
与使用 Acquia 或 WP Engine 开始项目的方式相比，第一步——在编写一行代码之前——是决定你将自己锁定在什么基础设施中。 Acquia 想知道您是需要单个服务器、集群还是 多站点 安装。 WP Engine 想知道您是否会在他们的共享主机上，或者他们会为您架设一组机器（顺便说一句，这需要数周时间）。因为关键的、难以改变的决定是预先发生的，所以计划一个漫长的采购过程。而且，如果您的预期站点流量水晶球不准确，请计划计划的停机时间和主要成本变化以切换基础架构。
毫不奇怪，这些公司在项目初期就将最关键和最难以预测的决定之一强加给您：他们根本没有 Pantheon 拥有的负载平衡、文件系统、容器和上游技术。因此，为了弥补他们无法提供一种可以扩展和缩小以满足所有需求的产品，他们为每组需求部署了不同的遗留式基础设施变体。新需求？新产品。在买家意识到所有产品唯一的共同点就是品牌之前，它会很好地检查买家的箱子。
负载均衡、容器、文件和上游
容器和 Pantheon 的自定义负载平衡是齐头并进的。 容器 为应用程序服务器、数据库和其他资源提供动态扩展。平均而言，我们可以在一分钟内（通常更少）为站点部署额外的容器。我们部署的容器很小，将更多的鸡蛋分散到更多的篮子中，从而隔离了故障。但是，如果我们依赖传统的负载均衡器配置（静态后端配置和监控），这会产生比灵活性更多的开销。相反，我们运行自己的基于 Go 的负载均衡器，该负载均衡器按需发现额外的容器、扩展流量并无缝避免故障（无需通常花费几分钟时间来发现后端“关闭”）。这项技术意味着 Pantheon 客户不必提前选择网站需要哪些应用程序资源或是否需要高可用性 (HA)。
我们的竞争对手也需要尽早做出基础架构决策，因为这会影响他们存储文件的方式。在一台或共享的机器上，他们通常将它们存储在本地，这不允许扩展到多台机器但便宜且快速。当您选择集群配置时，他们通常会部署 GlusterFS 或硬件 NAS，这允许多个应用程序服务器，但速度较慢且成本太高，无法用于较小的站点。 （而且，如果您在单个节点上测试站点并部署到集群，不要期望可预测的结果。）在 Pantheon，我们使用 C 和 Python 开发了 一个文件系统 ，我们将其用于从沙箱到任务的每个项目-关键企业网站。该技术使客户无需在项目设置时选择单节点或集群配置，并提供测试和生产环境之间的一致性。
另一个在采购时不好做的决定是是否有任何站点需要定制开发（即它们是否是彼此 100% 的橡皮图章）。在 Pantheon 上，每个站点都以其“上游”（Drupal、WordPress、相关产品）的橡皮图章开始，但它是孤立的，以后可以接受自定义更改。这是多站点的所有好处，包括代码共享、批量升级和视觉统一性，而且没有不灵活或缺乏安全性和资源隔离的缺点。
由于只有一种产品可用于在 Pantheon 上构建、测试和部署站点，因此每个项目（无论大小）都显示在具有统一团队管理系统的单个仪表板中。无需记住站点使用何种基础设施类型来访问该站点的工具，或者在忘记时求助于取证。
构建网站时有足够多的艰难选择。根据您的需求变化（而不是按照传统技术的要求）扩展基础架构，从而更快地启动项目并避免成本和时间意外。