边车和运维者模型可能会成为主流的软件分发和消费模型,在某些情况下甚至会取代软件库包和框架。
如果您是一个软件供应商,可能您已经考虑过将您的软件作为API或基于SaaS的解决方案提供给潜在用户,这是最快的软件消费模型,并且尽可能地提供了便利;根据软件的性质,您可能还会将软件作为库或运行时框架进行分发(如Spring框架等);也许现在是时候考虑是否也可以将它作为容器提供给运维者了,这种分发软件的机制和最终的体系结构具有一些库机制无法提供的非常独特的好处。
Kubernetes上的软件应用程序架构的发展将朝着由运营者管理的sidecar边车模型发展。边车和运营商两个模型可能会成为主流的软件分发和消费模型,在某些情况下甚至会像我们过去那样取代软件库和框架。
边车模型允许以不同语言编写的应用程序组合可以更快地交付联合价值,而无需运行时耦合。让我们看一些边车和操作员的具体示例,然后我们将探索这种新的软件组合范例如何影响我们。
什么是Kubernetes的运维者与边车模型?
在Kubernetes中,边车是通过在单个Pod中组织多个容器轻松实现的。Pod构造可确保将容器始终放置在同一节点上,并可以通过网络,文件系统或其他IPC方法进行交互来进行协作。Kubernetes 运维者 可以将边车与平台的其余部分进行自动化、管理和集成。
边车代表了与语言无关的可扩展数据平面,为定制应用程序提供了分布式原语。运维者代表集中管理和控制平面。
边车模型的实现
有一些基于GraalVM实现的新Java项目,例如 Quarkus。 从而减少了资源消耗和应用程序启动时间,从而使更多的工作负载吸引了边车(现在的JavaEE和Spring都无法做到)。所有这些创新将使边车模型更具吸引力,并使创建更多此类项目成为可能。
更具体用例的项目:例如对长期运行的有状态编排(例如,边车中的业务流程模型和注释(BPMN)引擎)进行的处理,我并不感到惊讶。边车上的作业调度程序。无状态集成引擎,即Sidecar中的Enterprise Integration Patterns实现。
运维者模型
(banq注:将软件直接交付给运维者,软件研发和软件实施的两个阶段实现分离,研发团队交付带有yaml配置的Docker容器镜像,实施团队直接一键部署运维监控,两者之间不再扯皮。)
基于容器的运维者交付模型好处是:
当某个功能作为库包或框架使用时,它会包含在您的应用程序运行时中,您有责任了解它的工作原理,配置,监视,调整和升级。这是因为语言运行时(例如JVM)和运行时框架(例如Spring Boot或应用程序服务器)决定了如何包括,配置,监视和升级第三方库。
而当软件功能被用作单独的Runtime运行时环境(例如,边车或独立容器)时,它会以 Kubernetes运算符 的形式附带其自己的控制平面。
由于控制平面了解其管理的软件(操作数)并具有所有必要的管理智能,否则它将作为文档和最佳实践分发了,因此,这将带来很多好处。此外,运营商还与Kubernetes进行了深度集成,并提供了平台集成和操作数管理智能的独特组合。运算符由创建应用的同一开发人员创建,他们了解容器化功能的内部结构,并且知道如何最佳地操作。
未来的软件发行和消费使用
未来是作为带有控制平面的边车分发的软件,
假设您是Java框架的软件提供商。您可以将其作为存档或Maven工件进行分发。也许您走得更远,然后分发了容器映像。无论哪种情况,在当今的云原生世界中,这还不够好。
用户仍然必须知道如何在零停机时间内修补和升级正在运行的应用程序。他们必须知道要备份和还原其状态的内容。他们必须知道如何配置其监视和警报阈值。他们必须知道如何检测复杂故障并从中恢复。他们必须知道如何根据当前的负载配置文件调整应用程序。
在所有这些以及类似的场景中,Kubernetes运算符形式的智能控制平面就是解决答案。运营商将应用程序的平台和领域知识封装在以声明方式配置的组件中,以管理工作负载。
假设您提供的软件库作为依赖项包含在使用者应用程序中。也许它是上述后端框架的客户端库。例如,如果它使用Java,则可能已认证它可以在JEE服务器上运行,必须提供Spring Boot Starters,Builders,Factory和其他实现都隐藏在干净的Java接口后面。您甚至可能也将其反向移植到.Net。
使用Kubernetes运维者和小边车,所有这些对消费者都是隐藏的。工厂类被运维者模型替换,唯一的配置接口是自定义资源的YAML文件。然后,运营者模型负责配置软件和平台,以便用户可以将其作为显式的辅助工具或透明的代理使用。在所有情况下,您的应用程序还是都可以通过远程API使用,并且与平台功能甚至其他从属操作员完全集成。
通过远程API而不是Maven等嵌入式库使用的软件
未来标准API除了Java数据库连接(JDBC)API,Java缓存API(JCache),Java持久性API(JPA)之外,我们还将使用CloudEvents之类的基于HTTP的多语言API。用于消息传递,缓存,可靠的网络,cron作业和计时器调度,资源绑定(其他API,协议的连接器),幂等性,SAGA等的Sidecar中心API。
所有这些功能都将随表格中包含的管理层一起提供运营商,甚至包裹着自助式用户界面。运营商是此处的关键推动力,因为它们将使这种更加分散的架构易于在Kubernetes上进行管理和自我操作。
总结
在交付速度和可操作性的驱动下,这是一种思想上的巨大转变,转向了一种不同的分发和使用软件的方式。这是从单一运行时架构到多运行时应用程序架构的转变。这与摩尔定律结束时硬件行业从单核平台向多核平台的转变相似。通过构建难题的所有要素,这种变化正在慢慢发生:我们已经统一采用并标准化了容器,我们已经通过Kubernetes制定了事实上的编排标准,CloudEvents广泛有了适当的标准,就可以使用Quarkus等轻量级运行时。有了这样的基础,应用程序,生产力工具,实践,标准化的API和生态系统也会随之出现。(banq注:怪不得Spring公司战略转移到K8s,虽然迟了一步,但是有希望。)