“乏味”（boring）是对基础架构技术所能给予的最高赞誉之一。没有人想要在“火辣时髦”的技术上运行关键任务应用程序。但如果是乏味的技术呢？那很好。
　　乏味表明一项技术的普遍性和可信度已到了某种程度，它广为人知且易于管理。Kubernetes已部署在78%的企业的生产环境中，可以说已到了这个程度，已被广泛认为是“切实可行”的支持云的标准底层技术。
　　或者换句话说，Kubernetes已变得“乏味”。
　　就在云原生计算基金会（CNCF）帮助协调其他一系列项目的开发，以填补Kubernetes在基础架构层留下的任何空白之际，Kubernetes方面的对话已开始转移到堆栈上层。今年4月，知名的开发者倡导者Kelsey Hightower表示，Kubernetes只解决了更新改造应用程序的一半问题：
　　“在基础架构层‘更新改造’应用程序方面投入了大量的努力，但是在应用程序层（想想框架和应用程序服务器）方面没有同等的投入，我们只解决了一半问题。”
　　对此我们该怎么办？

填补应用程序和基础架构之间的空白

　　Lightbend的首席技术官兼联合创始人Jonas Bonér在接受采访时说：“基础架构与构建完整应用程序之间存在巨大空白。”Bonér帮助启动了开源项目Akka，该项目位于堆栈中的Kubernetes之上，旨在解决基础架构和应用程序之间的一个复杂问题。正如Bonér所说：“程序员要做的实际工作就是填补这个巨大的空白，这就意味着为业务部门提供服务等级协议（SLA），这在分布式系统中很难实现，但应用程序层要充分利用Kubernetes及其生态系统，就需要这么做。”
　　Bonér继续说，企业组织需要让介于应用程序和基础架构之间的系统完全切实可行。不是说关键在于替換任何系统，而是往工具箱添加更多工具，并将基础架构隔离模型以及网络施加的约束扩展到应用程序本身中——并以一种直观、灵活、强大但又简单的编程模型来提供。
　　正如特斯拉的两名工程师在去年一次会议上所讨论的，特斯拉依赖“数字孪生”功能支持其电网，这一切得益于Akka和Kubernetes的结合。特斯拉工程师Colin Breck说：“我们的大多数微服务在Kubernetes中运行，而Akka和Kubernetes可谓天作之合。”
　　他解释道：“Kubernetes可以处理扩展方面的粗粒度故障，因此可以进行诸如增加或减少Pod、运行存活监测或以指数退避机制重启失效Pod之类的操作。然后，我们使用Akka处理细粒度故障，比如断路或重试单个请求，以及为单个实体的状态（比如电池在充电或放电）建模。”

　　据Bonér声称，云原生堆栈上的Kubernetes方面仍存在3个尚未解决的领域，带来了Akka等技术提供的新抽象：应用程序层组合、状态性用例和传输中数据用例。

支持声明式应用程序层组合

　　Bonér特别指出：“人们常常使用一套旧的工具、习惯和模式，它们通常源自传统的（整体式三层）设计，这种设计抑制和约束了Kubernetes提供的云模型。”他表示，我们需要将容器、服务网格和编排“非常好”的模型一直扩展到应用程序/业务逻辑，那样我们可以在充分利用它的同时代表应用程序维护端到端保证。
　　无服务器技术指明了道路：它提高了抽象级别，并提供一种声明式模型：平台消除和管理尽可能多的样板代码、基础架构和操作，从而使开发人员专心于核心方面：业务逻辑及工作流程。

改进对状态性用例的支持

　　云生态系统的大部分主要处理所谓的类似12因素应用程序（12-factor）的应用程序，即无状态应用程序。有时这可能正是你需要的。但重要的应用程序通常结合无状态用例和状态性用例。
　　Bonér说：“我们需要更多更好的工具来处理好状态。如今，价值通常在于数据，通常在于蕴含大多数业务价值的状态性用例——确保你可以快速访问这些数据，同时确保正确性、一致性和可用性。”
　　在云中，除非有非常好的模型以及支持它的工具，否则会被迫回到三层架构：每次将所有内容推送到数据库中，无论它用于状态的通信、协调还是长期运行。
　　重要的是，你还需要良好的状态模型来补充无状态方法，从而为工具箱增添更多的选择。Bonér特别指出，如今，Kubernetes处理状态性用例的程度实际上仅在其StatefulSets功能中得到支持，但StatefulSets是为实施数据库等基础架构的人员设计的，而不是为应用程序开发人员设计的。
　　Bonér说：“因此，这里仍存在巨大空白。这是Akka真正发挥用场的地方。”

处理快速数据或传输中数据用例

　　可以说，Kubernetes生态系统尚未为基于流和基于事件的用例提供强大支持。Bonér表示，像Istio这样的服务网格是围绕请求-响应模型设计的，“可能会挡路”。流也常常是状态性的，各阶段在内存中聚合数据，同时需要确保可用性。Bonér表示，Knative社区正在竭力解决该问题，但我们刚迈出了一步。
　　推动业界迈向这些新方向的主力军似乎是低代码/无代码/“前后端脱钩”概念，这些概念为无服务器运动起到了推波助澜的作用。
　　Bonér说：“无服务器使我们更有望解决将Kubernetes模型扩展到应用程序本身这个问题。这就是关键。尽可能地进行抽象，转而使用一种声明式配置模型，而不是编程模型，在该模型中你定义应该执行的操作，而不是定义如何执行。”

“切实可行”的应用程序基础架构

　　随着云原生堆栈继续在Kubernetes基础架构层上发展，应用程序层的这些概念如何实际服务于特定的语言开发人员还需拭目以待。虽然应用程序架构许多最棘手的挑战长期以来一直是服务器端Java开发关注的点，但我们似乎正朝着Jamstack架构迈进：JavaScript开发人员日益要求访问切实可行的应用程序基础架构，尤其是当端点设备数量急剧增加时。
　　这倒不是说后端基础架构不重要。正如Ian Massingham所言，这是承认前端开发人员的数量远超过后端开发人员，这有其充分理由：需要构建的应用程序比需要为托管它们而创建的基础架构多得多。通过Akka之类的开源项目在两者之间架起桥梁变得越来越重要。
　　本文作者Matt Asay是亚马逊网络服务（AWS）的负责人。Asay以前是Adobe的开发者生态系统负责人。加盟Adobe之前，Asay在多家开源公司担任过一系列职务。他是开源组织（OSI）的名誉董事会成员，拥有斯坦福大学法学博士学位，主要研究开源及其他知识产权（IP）许可问题。
　　原文网址
　　https：//www.infoworld.com/article/3567648/what-comes-after-kubernetes.html