为什么开源应该是云原生环境的首选

让我们回到 20 世纪 90 年代，那时专有软件盛行，但开源开始崭露头角。是什么导致了这种转变？更重要的是，当我们转向云原生环境时，今天我们可以从中学习到什么？

基础设施历史课

我将从高度主观的开源视角开始回顾过去 30 年的基础设施历史。在 20 世纪 90 年代，Linux 对于大多数组织来说只是雷达上的一个小点，如果他们知道它的话。早期有一些公司迅速看到了 Linux 的好处，主要是将其作为专有 Unix 的廉价替代品，但部署服务器的标准方法是使用专有形式的 Unix，或者越来越多地使用 Microsoft Windows NT。

这种工具的专有性质为更多的专有软件提供了肥沃的生态系统。软件被打包在盒子里在商店出售。甚至开源也加入了包装游戏；你可以从货架上购买 Linux，而不是占用你的互联网连接从免费来源下载它。去商店或与你的软件供应商合作只是你获取软件的方式。

图片来源

opensource.com

我认为事情发生变化的地方是 LAMP 堆栈（Linux、Apache、MySQL 和 PHP/Perl/Python）的兴起。

LAMP 堆栈是一个主要的成功案例。它稳定、可扩展且相对用户友好。与此同时，我开始看到对专有解决方案的不满。一旦客户在 LAMP 堆栈中尝到了开源的滋味，他们就改变了对软件的期望，包括

• 不情愿被供应商锁定，
• 对安全性的担忧，
• 渴望自己修复错误，以及
• 认识到当软件在孤立状态下开发时，创新会被扼杀。

在技术方面，我们也看到了组织使用软件方式的巨大变化。突然之间，网站宕机变得不可接受。人们越来越依赖扩展和自动化。尤其是在过去十年中，我们已经看到基础设施从传统的“宠物”模式转变为“牲畜”模式，服务器可以被换出和替换，而不是被保留和命名。公司处理大量数据，导致人们更加关注数据保留以及处理数据并将其返回给用户的速度。

开源，凭借开放社区和主要公司不断增加的投资，为满足我们开始使用软件方式的变化奠定了基础。系统管理员的职位描述开始要求具备 Linux 技能，并熟悉开源技术和方法。通过 Chef cookbooks 和 Puppet modules 等开源工具，管理员可以共享其工具的配置。我们不再孤立地配置和调整 MySQL；我们创建了一个系统来处理

基本部分，以便我们可以专注于为我们的雇主带来特定价值的更有趣的工程工作。

如今，开源无处不在，围绕它的工具也是如此。曾经对这个想法持敌对态度的公司不仅通过互操作性计划和外展活动拥抱开源，还发布他们自己的开源软件项目并围绕它建立社区。

图片来源

opensource.com

转向云

今天，我们生活在一个 DevOps 和云的世界中。我们已经收获了开源运动带来的创新成果。Tim O'Reilly 所谓的“内部开源”现象急剧兴起，即在公司内部采用开源软件开发实践。我们正在共享云平台的部署配置。像 Terraform 这样的工具甚至允许我们编写和共享我们如何部署到特定平台。

但是这些平台本身呢？

“大多数人只是在不思考的情况下消费云……许多用户正在将成本投入到不属于他们的基础设施中，并且他们在不思考的情况下放弃关于他们自己的数据和信息。”
— 爱德华·斯诺登，OpenStack 峰会，2017 年 5 月 9 日

现在是时候更多地思考我们对迁移或扩展到云的本能反应了。

正如斯诺登强调的那样，现在我们面临着失去对我们为用户和客户维护的<0xC2><0xA0>数据的控制权的风险。除了安全性之外，如果我们回顾一下我们转向开源的原因列表，其中最重要的原因也是对供应商锁定以及无法推动创新甚至修复错误的担忧。

在您将自己和/或您的公司锁定在一个专有平台之前，请考虑以下问题

• 我正在使用的服务是否遵循开放标准，还是我被锁定了？
• 如果服务供应商倒闭或被竞争对手收购，我该怎么办？
• 供应商在与客户清晰诚实地沟通关于宕机、安全等方面的问题方面是否有历史记录？
• 供应商是否响应错误和功能请求，即使是来自较小客户的请求？
• 供应商是否会以我不舒服的方式（或更糟的是，我们的客户协议不允许的方式）使用我们的数据？
• 供应商是否有处理长期、不断增长的增长成本的计划，特别是如果初始成本很低？

您可能会完成这份问卷，讨论每个要点，并且仍然决定使用专有解决方案。这没关系；公司一直都在这样做。但是，如果您像我一样，宁愿找到更开放的解决方案，同时仍然从云中受益，那么您确实有选择。

超越专有云

当您展望专有云解决方案之外时，您的第一个开源选择是投资于核心运行在开源软件上的云提供商。OpenStack 是行业领导者，在其七年的历史中拥有 100 多个参与组织和数千名贡献者（包括我一段时间）。OpenStack 项目已经证明，与多个基于 OpenStack 的云进行交互不仅是可能的，而且相对容易。云公司之间的 API 相似，因此您不一定会被锁定在特定的 OpenStack 供应商中。作为一个开源项目，您仍然可以影响基础设施的功能、错误请求和方向。

第二种选择是继续在基本级别使用专有云，但在开源容器编排系统内使用。无论您选择 DC/OS（构建于 Apache Mesos 之上）、Kubernetes 还是 Docker in swarm mode，这些平台都允许您将专有云系统提供的虚拟机视为独立的 Linux 机器，并将您的平台安装在其之上。您只需要 Linux——并且不要立即被锁定到云特定的工具或平台中。关于是否使用特定的专有后端，可以根据具体情况做出决定，但如果您这样做，请尽量关注未来，以防需要迁移。

无论选择哪种方案，您都可以选择完全脱离云。您可以部署您自己的 OpenStack 云，或者将您的容器平台内部迁移到您自己的数据中心。

做出登月壮举

最后，我想谈谈开源项目基础设施。早在三月份，来自各个开源项目的参与者齐聚 南加州 Linux 展，讨论为其项目运行开源基础设施。（更多信息，请阅读我对本次活动的总结。）我将这些项目正在做的工作视为基础设施开源的最后一步。除了我们现在正在进行的基本共享之外，我相信公司和组织可以使其基础设施更加开源，而不会放弃使其与竞争对手区分开来的“秘方”。

已经开源其基础设施的开源项目已经证明了允许多家公司和组织提交有理有据的错误报告，甚至补丁和功能，给他们的基础设施的价值。突然之间，您可以邀请兼职贡献者。您的客户可以通过了解您的基础设施“在幕后”的样子来获得信心。

想要更多证据？请访问 开源基础设施 的网站，了解更多关于正在开源其基础设施的项目（以及他们发布的广泛的基础设施）。

在 Elizabeth K. Joseph 于费城 FOSSCON 8 月 26 日举行的题为 基础设施的开源 的演讲中了解更多信息。