为什么基于云的架构和开放源代码不会总是混合在一起

为什么基于云的架构和开放源代码不会总是混合在一起

• 来源:网络
• 更新日期:2020-09-10

摘要：从某种程度上说，开源在云端已经取得了巨大的成功。像Kubernetes这样的开源解决方案已经把封闭源代码作为主力。然而，在其他方面，云中的开源完全失败了。基于云的架构继续为实现

从某种程度上说，开源在云端已经取得了巨大的成功。像Kubernetes这样的开源解决方案已经把封闭源代码作为主力。然而，在其他方面，云中的开源完全失败了。基于云的架构继续为实现开源保护用户自由的创始目标带来根本问题。对于许多组织来说，使用云意味着将控制权交给专有解决方案提供商，并面临着严格的锁定风险。

这些观察提出了一个问题：为什么开放源代码在云中没有更大的影响力？如何使云计算对开放源代码更友好？

云的开源问题

从云时代的早期开始，开源和云之间就一直处于紧张状态。

当自由和开放源码软件在1980年代由Richard Stallman和GNU项目首次出现时，其主要目标（正如Stallman当时所说的那样）是向任何想要它的人提供软件源代码，以便用户可以使用计算机并相互协作。

如果在本地设备上运行软件，那么访问源代码就可以实现这些目标。它确保您可以研究程序的工作原理，与他人共享修改并自己修复错误。只要源代码可用并且您可以在自己的设备上运行软件，软件供应商就不能“分割用户并征服他们”。

但是，当软件迁移到基于云的体系结构时，这种计算方式会发生根本变化。在云计算中，作为最终用户访问的软件运行在由其他人控制的设备上。即使该软件的源代码可用（在SaaS平台上通常不可用，尽管从理论上讲可能是这样），但其他人（尤其是拥有运行该软件的服务器的人）仍可以控制您的数据，决定软件的配置方式，决定何时更新软件等等。最终用户之间没有团结，最终用户与软件提供商之间没有平等。

Stallman和其他自由软件的倡导者早就意识到了这一点。到2010年，Stallman 感叹用户使用基于云的软件时放弃的控制权，并创造了“服务软件替代品”之类的术语来模拟SaaS架构。他们还引入了Affero通用公共许可证，旨在将GNU通用公共许可证（主要的免费软件许可证）的保护范围扩展到网络上托管的应用程序。

这些努力的成果充其量是平庸的。自2000年代中期以来，Stallman对用户不使用SaaS平台的要求对阻止云的爆炸性增长几乎没有任何作用。如今，很难想到无法通过SaaS架构获得的主要软件平台，也很难找到在软件自由性问题上回避SaaS的最终用户。

而且，尽管Affero许可证获得了广泛的关注，但其推动云计算中自由和开源软件事业发展的能力受到限制。Affero许可证的主要目的是确保软件供应商不能声称基于云的软件未“分发”给用户，因此不受传统开源许可证（如GPL）的约束。这总比没有好，但是对于解决与用户使用基于云的服务时面临的数据控制，软件修改等相关的问题，它却无济于事。

因此，基于云计算的体系结构继续对自由和开源软件的基本目标构成根本挑战。很难想像一种解决这些挑战的方法，更难以想象它们在云计算应用比以往任何时候都强大的世界中消失。

开源云计算的成功

通过另一种更积极的方式讲述云中开源的故事。从某些领域的角度来看，例如私有云和“云原生”基础架构技术，开源取得了巨大的成功。

像Kubernetes这样的项目，Kubernetes是一个开放源代码应用程序编排平台，它已经变得非常占主导地位，甚至不再没有竞争对手了。即使是VMware（其虚拟机编配工具与Kubernetes竞争）现在也在运行自己的Kubernetes发行版，Kubernetes赢得了编排器战争。

OpenStack是一个用于构建私有云的平台，对于基于云计算的体系结构的开源而言，也取得了类似的成功案例。也许它还没有像Kubernetes那样彻底抹杀竞争者，但是OpenStack对于寻求建立私有云的公司来说仍然是一个非常成功的，广泛使用的解决方案。

可以对Docker得出类似的结论，Docker是一个开放源代码容器化平台，对于那些想要比专有虚拟机更敏捷，更节能的解决方案的公司而言，它已成为首选解决方案。

甚至在公司确实希望使用普通的虚拟机构建云计算的情况下，Linux内置的开源虚拟机管理程序KVM现在也可以与来自VMware和Microsoft等厂商的竞争VM平台保持竞争。

在构建基于私有（或较小程度上为混合）的云基础架构时，开源在过去十年中做得很好。十年前，不得不依靠专有工具来填补空白，而Kubernetes、OpenStack、Docker和KVM等平台现在已成为事实上的解决方案。

开源与公共云

但是，当查看公共云时，开源似乎不太成功。尽管主要的公共云为Kubernetes和Docker之类的平台提供SaaS解决方案，但它们倾向于将它们包装在专有扩展中，这些专有扩展使这些平台的开源程度不如实际。

同时，公共云中的大多数核心IaaS和SaaS服务均由封闭源软件提供支持。如果要在Amazon S3中存储数据，或在Azure Functions中运行无服务器功能，或在Google Cloud中启动连续交付管道，则将使用其源代码永远都看不到的专有解决方案。尽管事实上存在许多此类服务的开源等效项（例如Qinling、无服务器功能服务或CI/CD的Jenkins）。

云市场的消费者方面也由封闭源解决方案主导。尽管存在诸如Zoom和Webex之类的平台的开源替代方案，但即使在专有协作平台的隐私和安全性缺陷引起恐慌的情况下，它们也很少受到关注。

建立更好的开源云

对于在云中运行更多开源软件的一个明显反对意见是，云服务需要花费托管费用，这使供应商更难提供免费的开源解决方案。由于用户提供了自己的基础架构，因此可以轻松地将Firefox交给人们安装在自己的计算机上。但是，托管等效于Zoom的开源程序要昂贵得多，这需要庞大且昂贵的基础架构。

但是，这种观点反映了缺乏想象力。有传统的集中式云基础架构的替代方案。与传统的IaaS基础架构相比，分布式对等网络可用于托管开源云服务，而服务提供商的成本要低得多。

同时也要指出，许多专有的云服务都是免费的。从这个意义上说，有关SaaS提供商需要补偿其基础设施费用，因此不能提供免费和开源解决方案的说法没有任何意义。如果Zoom可以免费使用基本用法，则没有理由也不能将其开源。

诚然，将更多的云服务开源是无法解决上面讨论的有关用户在他人拥有的服务器上运行代码时放弃的控制的根本问题。但这至少将为用户提供一些了解他们使用的SaaS应用程序或公共云IaaS服务如何工作的能力，以及扩展和改进它们的更多机会。

想象一下一个世界，例如，Facebook或Gmail的源代码处于打开状态。我们怀疑对于隐私问题的关注会减少，如果有人可以看到代码，那么第三方将有更多的机会构建与这些平台集成的出色解决方案。

但是，就目前而言，这些愿景似乎是不现实的。几乎没有迹象表明云中的开源将超越已经占据主导地位的私有云和应用程序部署壁ni。对于任何同意Linus Torvalds认为该软件免费的软件更好的人来说，这是一个耻辱。