告别 PaaS 和 IaaS

告别 PaaS 和 IaaS

作为一名软件工程师,为什么你只需要掌握 Kubernetes ?

翻译自 Saying Goodbye to PaaS and IaaS

Kubernetes 正在接管,不是吗?

几乎每个人现在都听说过 Kubernetes ,许多各种规模的组织正在使用它或至少在考虑在生产中使用它。然而,Kubernetes 不仅仅是用于运行容器化工作负载的技术。它可以改变您的 DevOps 文化。通过设计,它抽象了底层基础设施,同时允许我们在需要时创建或修改它。

软件工程师将不再需要使用 PaaS 或 IaaS 。

太过激进了吗?

也许是的,但这不是把 Kubernetes 置于至高无上的地位,让它成为我们所有问题的唯一解决方案。我完全意识到 Kubernetes 、容器和微服务可能并不是每个问题和每个组织的解决方案。然而,根据我在过去几年帮助组织成为云原生的经验,许多人在实施 DevOps 文化时遇到了很多困难。

我坚信 Kubernetes 可以帮助解决这个问题。

Kubernetes 将长久存在

毫无疑问,Kubernetes 不仅仅是一个会消失的炒作技术。

我还记得 2014 年 Kubernetes 刚刚被捐赠给 CNCF 时我开始使用它。当时几乎它是唯一的用于运行容器化工作负载的开源技术。如今,使用容器的组织中约有一半正在使用 Kubernetes 在生产环境中运行它们。

但Kubernetes的意义不仅仅在于操作容器化工作负载。

起源

我喜欢讲述这个故事,我最初是在 Nigel Poulton 的课程中听到的。然而,这是 Kubernetes 的简短故事。

IT 基础设施虚拟化(即基础设施即服务,简称 IaaS )的兴起始于大约20年前,由亚马逊开创,随后有微软IBMDigital Ocean 等等。

当时,亚马逊的优势是巨大的。虽然如今谷歌也提供按需基础设施服务,但在当时,谷歌正在思考如何利用自己的专业知识在这个领域中胜过竞争对手。

谷歌还试图往前看,自问:

我们如何将所有云基础设施,包括裸金属服务器,统一到一个合适的抽象层中?

这是一个聪明的问题,因为当时已经清楚,每个基础设施提供商在其提供的细节上会略有不同(函数即为一个很好的例子)。

答案就是 Kubernetes 。

为什么?因为 Kubernetes 可以在每个云提供商上运行,甚至可以在裸金属服务器上运行。使用 Kubernetes 的开发人员无需担心或甚至了解它实际在哪个基础设施上运行。

崛起

当我和人们谈论 Kubernetes 时,我喜欢告诉他们我认为它是运行软件的头号平台。当然,你可以看出我是一个铁杆粉丝——部分原因是因为我参与了这个令人惊叹的社区,并喜欢在这里做贡献——但我们来快速看看为什么 Kubernetes 真的是解决许多问题的瑞士军刀。

一切都始于容器。没有容器,就不需要 Kubernetes ,对吧?

根据 CNCF 的 2022 年调查,容器现在被视为主流,有 44% 的受访者表示他们在大多数或所有生产应用中使用容器。其中一半使用容器的组织在生产中使用 Kubernetes 来部署其中至少一部分容器( 64% 的最终用户和 49% 的非最终用户)。

你可能会说这只是数字,只代表世界各地正在发生的特定领域的软件工程。你可能还会说,对很多人来说,Kubernetes 并不是合适的工具。在这些陈述中,你可能是对的。

但是我们来考虑一下。

对于许多组织、用例和环境来说,Kubernetes 是合适的工具。即使对于你正在处理的特定产品或所在的团队/部门来说,学习如何使用 Kubernetes 也是非常有价值的。

而且,我想用上述 CNCF 调查中的一个有趣事实来强调这一点。

Kubernetes 的使用逐渐不仅局限于运行应用负载,还用于辅助负载。这意味着安全控制、服务网格、消息系统、可观察性和持续集成/持续交付工具。令人惊讶的是,从 2021 年到 2022 年,辅助负载的数量将超过应用负载。然而,辅助负载的数量同比增长了 211% 。

https://www.cncf.io/reports/cncf-annual-survey-2022/

Kubernetes 不仅仅是用于编排容器化应用负载的旗舰工具。

它正在成为云的操作系统

如何实现DevOps?

也许你已经看到了未来发展的方向。自从诞生以来,DevOps 运动一直在试图弥合开发人员和运维人员之间的鸿沟。而且有很多不同的方式来做到这一点。

我见过开发人员变成运维人员,反之亦然,还有 DevOps 职位和整个团队,最新的变化是平台工程师或团队。不管你采取什么解决方案,根本动机始终是赋予开发人员建立和运行他们自己的软件的能力。

你构建它,你运行它。

这就是 DevOps 的口号。尽管我个人不喜欢 DevOps 的职位或整个团队,但我喜欢平台工程的理念。当我在一家专注于 DevOps 的公司为 Cloud Foundry 构建数据服务时,我在技术层面上对 DevOps 的理念是建立一个平台。就像一个内部PaaS(如 Heroku、Cloud Foundry 等)。

这并不是什么新鲜事。我们为许多大型领先行业的客户运行了多个 Cloud Foundry 实例,使他们的开发人员能够构建和运行他们的软件。棘手的问题在于平衡类似 Cloud Foundry 的平台的限制和团队开发人员可能需要的灵活性。

如果他们需要新的数据库、网络或子网、Blob 存储等,他们仍然需要依赖运维团队。那么支持性的工作负载呢?比如安全控制、持续集成/持续交付或可观测性工具?这些也可能需要由运维部署和维护。

选项的扩展

让我们总结一下目前的情况。容器无处不在,我们有这个强大的工具可以在规模上对它们进行编排。然后,我们有开发人员和运维人员,我们仍然希望减少摩擦,以便快速交付价值。但是有许多不同的方法可以做到这一点,每种方法都有其优缺点。似乎没有一种方法是万能的。

这本身不一定是一个问题,但是让我们花一分钟来看看不同选项的影响。

  • 运维人员可以给开发人员访问 IaaS 层。这将给开发人员很多自由和灵活性。但这也意味着他们需要很多运维知识。而且我们不能忘记 IaaS 提供商之间的微妙差异。开发人员需要了解不止一个 IaaS 提供商。但公平地说,在这种情况下,开发人员和运维之间的差距将非常小,因为开发人员可以自己提供所需的一切。但开发人员想要拥有这种深入的运维知识吗?他们是否有能力?他们是否被允许?考虑所有治理和安全约束。
  • 运维人员可以为开发人员引入一个通用的平台即服务(PaaS)。比如说 Cloud Foundry 。它会为开发人员抽象出底层基础设施,并为他们提供一些接口来运行他们的应用程序(部署、扩展、查看日志等)。开发人员几乎不需要运维知识,但他们的灵活性也会受到限制。但如果他们需要数据库、消息服务、持续集成/持续交付或其他什么东西,仍然会有一个小的差距。

当然,这些不是唯一的可能性。我在可能性范围上指出了一些点。在这个范围内还有完全不同的选项,类似于我指出的选项,但细节上有所不同。一如既往,真相位于中间。

然而,我希望至少从开发人员的角度来看,能有一种统一的方式。我认为 Kubernetes 可以成为这种统一。它可以成为以统一方式提供开发人员所需一切的平台。

但等等,Kubernetes 是用于运行容器化工作负载的,对吗?那么我们如何使用 Kubernetes 在基础设施层面部署应用?

一戒统领天下

在过去几年中,我们看到了在 Kubernetes 领域成立的新公司,它们专注于为开发人员部署和管理(多/云)平台。Upbound 就是这样一家公司,他们创建了 Crossplane ,这是一个开源项目,可以用来创建他们所称的控制面。

控制面就是你登录到云服务提供商帐户时看到的东西。它允许我们将 Kubernetes 用作我们之前讨论的平台。一个地方,可以控制一切,包括应用程序和基础设施、配置、策略和权限。它允许开发人员进行自助服务,最酷的是,通过单个 Crossplane 安装,您甚至可以从不同的云提供商中提供基础设施资源,实现真正的多云体验。

我是 Crossplane 的铁杆粉丝,因为它运行在 Kubernetes 上,因此利用了 Kubernetes 的能力,比如自我修复和(自动)扩展。猜猜怎么着,通过 Crossplane 部署的基础设施组件也是如此。Kubernetes 将使用其协调机制,确保一切始终处于所期望的状态。

这不是很棒吗?

这里有一个小仓库,其中包含了使用 Crossplane 提供 Azure 资源的入门指南。我保证将来会发表一篇后续文章,更深入地介绍 Crossplane 。

结论

大约两年前,我说过 Kubernetes 会接管,而且事实证明我没错。相反,每个人都知道 Kubernetes ,许多组织都在使用它。然而,Kubernetes 并不是在软件工程中所有问题或难题的解决方案。

但是通过 Kubernetes 和类似 Crossplane 的工具的帮助,我们可以弥合开发人员和运维之间的鸿沟。云原生的所有动力一直都是为了提高上市时间。但我必须说,通过 DevOps 、平台人员或团队引入更多的隔阂似乎不是正确的方法。

通过强大的平台来抽象基础设施,让开发人员可以全力构建和运行他们的软件,这对我来说更自然。

希望你喜欢这篇文章,并且我非常乐意听取任何反馈或了解你对这个主题的看法。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注