未来 10 年的云开发

Blog
Author:
Aaron TorresAaron Torres
Published On:
4月 25, 2022
Estimated reading time:
1 minute

云开发

多年来,云开发变得越来越复杂。现在,开发人员需要了解各种云技术,包括 API、基础设施即代码软件(如 Terraform 和 Pulumi),以及云上资源的生命周期。随着时间的推移,工程组织在云管理上投入的资源越来越多。

我们的研究发现,中型企业和快速增长的初创企业 62% 的工程能力用于功能开发,该数值正持续下降。这意味着每 10 个工程师中只有 6 个在开发和改进面向客户和用户的功能,而且这种趋势没有朝着正确的方向发展。基于多次大型公开调查,我们还发现 Devs 团队和 Ops 团队都认为复杂性是他们面临的最大挑战,与 2008 年相比,比例增加了 17%。生态系统已经累积了五年的技术,这使得处理难度日益增加。

Kubernetes 是许多公司正在使用的云/容器平台。Humanitec 2021 年的一项研究表明,1800 多名受访者中的大多数低估了 Kubernetes 的复杂性,这给紧跟当前行业趋势的新公司带来了问题。

(相关信息源于 Humanitec 2022 白皮书)

这些问题的核心是微服务的崛起,而这和我们大多数人得到的承诺完全不同。

微服务

在过去,开发人员使用 Chef 和 Puppet 等工具将遗留单体应用作为一个大单元进行部署和管理。

现在,使用微服务,可以更容易地实现故障隔离、独立部署、服务自定义环境、模块化代码和团队边界优化。

实现这种新式技术需要开发和运行数十个、数百个,有时甚至数千个小模块。因此,开发了工具,仅使用胶带就可将这些小模块组合在一起。

微服务是云的汇编代码——低级构建模块,它有助于执行不同配置和优化程度的代码包。开发人员和运营商须考虑实例计数、扩展规则、拓扑结构和服务定义、pod 结构、计算和数据存储优化、服务发现以及其特定业务和应用所需的特定工具。

因此,两种解决方案的优势都未充分实现。随着公司加速数字化转型,他们开始深刻地认识到,与当前的方法相比,微服务以及类似程度的无服务器范式更昂贵、更难使用、更复杂、更难引入、更难集成、更难开发/运营。

与传统数据中心相比,云在大规模运行时成本较高,且基于微服务的架构的复杂性使得它很容易陷入成本高昂的反模式。这将导致购买和雇佣更多抢手的基础设施和平台工程师,但由于微服务固有的底层性质,其从根本上消减组织其他部分复杂性的能力几乎总是不足。

理想的新架构

此处有个问题:“计算机工程的哪些方面可以用来缩小这一差距?”我们需要一个新的结合了单体应用和自适应系统优势的架构。自适应系统利用了先前场景中的架构,为了使其有效,须显著降低开发人员的认知负荷。

新的解决方案应具备以下特点……

  • 沿用现有架构的优势
  • 确保工具和编程语言的可用性
  • 与生态系统整合,而不是试图取代生态系统
  • 确保用户代码可识别、可调试和可修补——即使在生产过程中

单体应用、微服务和无服务器架构都有明显的优势,新架构也须具备这些优势,同时应降低获得这些优势的复杂性。

因此,它应匹配开发人员和运营商的现有技能集,而非简单地引入新的开发模式。生态系统已经为公司和组织面临的许多挑战提供了大量解决方案。新架构须补充这些服务,而非试图替换它们来加快采用速度。

此外,在生产过程中,如果开发人员、运营商和 DevOps 从业者无法操作、调试和修补他们的应用程序,那么该架构在行业中将不会被广泛采用。

易用性应是奋进的方向,解决方案须关注更高级别的开发人员和运营商意图,而不是低级微服务。这意味着描述性机制需要编纂该意图。程序员应以适合他们的方式编写代码。解决方案应尽早利用该意图来确定幕后需要什么后端布线和分析来满足其需求。如此,运营商将能够快速变更其运营服务。

构建和部署

构建和部署过程对任何新的服务架构来说都十分重要。该类过程和技术堆栈对组织至关重要,与上一节所述观点类似,新架构应补充而非完全取代这些工作。

在新架构中,集成层将更加重要。集成层将以单体仓库或多体仓库方式构建所有模块化服务。并行执行、测试、部署、分支和典型集成步骤也将变得更加重要。大多数分布式系统将能感知到它们在全世界的各个部分,新构建的系统须保持微服务带来的这种优势。

现有的基础设施解决方案通常具备一些比较智能的功能。它们可以向用户展示如何编写代码以及如何进行构建和部署。如果您按照指示去做,就能享受广告中所宣传的好处。

但是,必须有人来运行和操作它。很多人会说,这没什么问题,因为它是开源的。您可以查看它、下载它,并对其进行更改。但实际上,大多数公司没有时间或专业知识来做这件事。最终,您会陷入这样一种境地:整个公司的技术和业务都依赖于知道如何管理系统的人,而这个系统一半是由他人管理的。

解决方案该足够简单,您可以自己进行操作。如果出现问题,您应能够在不依赖外部干预的情况下进行修复。

总结

最终来看,支持这种新架构的工具应消减复杂性,而不是将其传递给其他开发人员、运营商或第三方。

借助 Klotho,我们正在实现一个基于这些原则的新架构,将三个过去未被同时应用的原则结合在一起:编译原理、应用分布式系统和基于约束理论的规划。将您的应用程序作为起点,您可以编写自己的代码。在您的代码中,您可以通过高级注释向我们展示您的意图。您只需运行 Klotho,您的应用程序就可以变成云原生程序。

根据您的经验,您认为在下一代云架构中,哪些点比较重要?