边车和运维者模型可能会成为主流的软件分发和消费模型，在某些情况下甚至会取代软件库包和框架。
如果您是一个软件供应商，可能您已经考虑过将您的软件作为API或基于SaaS的解决方案提供给潜在用户，这是最快的软件消费模型，并且尽可能地提供了便利；根据软件的性质，您可能还会将软件作为库或运行时框架进行分发(如Spring框架等)；也许现在是时候考虑是否也可以将它作为容器提供给运维者了，这种分发软件的机制和最终的体系结构具有一些库机制无法提供的非常独特的好处。
Kubernetes上的软件应用程序架构的发展将朝着由运营者管理的sidecar边车模型发展。边车和运营商两个模型可能会成为主流的软件分发和消费模型，在某些情况下甚至会像我们过去那样取代软件库和框架。
边车模型允许以不同语言编写的应用程序组合可以更快地交付联合价值，而无需运行时耦合。让我们看一些边车和操作员的具体示例，然后我们将探索这种新的软件组合范例如何影响我们。
什么是Kubernetes的运维者与边车模型？
在Kubernetes中，边车是通过在单个Pod中组织多个容器轻松实现的。Pod构造可确保将容器始终放置在同一节点上，并可以通过网络，文件系统或其他IPC方法进行交互来进行协作。Kubernetes运维者 可以将边车与平台的其余部分进行自动化、管理和集成。
边车代表了与语言无关的可扩展数据平面，为定制应用程序提供了分布式原语。运维者代表集中管理和控制平面。
边车模型的实现
- Istio，Consul等服务网格使用Envoy等透明服务代理 为分布式系统提供增强的联网功能。。Envoy可以提高安全性，支持高级流量管理，提高弹性，添加深度监视和跟踪功能。不仅如此，它还了解越来越多的第7层协议，例如Redis，MongoDB，MySQL和最新的Kafka。它还增加了响应缓存功能，甚至还提供了WebAssembly支持，可启用各种自定义插件。Envoy是透明服务代理如何将高级网络功能添加到分布式系统而不将其包括在分布式应用程序组件的运行时中的一个示例。
- 除了上面典型的服务网格外，还有一些项目，例如Skupper，这些项目通过外部代理传递应用程序网络功能。
- Cloudstate 是Sidecar模型的另一个示例，但这一次是为无服务器开发模型提供有状态抽象。它通过GRPC提供有状态原语，用于EventSourcing，CQRS，Pub / Sub，键/值存储和其他用例。同样，它是边车和操作员在行动的例子，但是这次是无服务器编程模型。
- Dapr是一个由Microsoft发起的相对较年轻的项目，它还使用sidecar模型来提供针对开发人员的分布式系统原语。Dapr为状态管理，服务调用和故障处理，资源绑定，发布/订阅，分布式跟踪等提供抽象。Dapr和Service Mesh区别：带有Istio的Envoy被注入并从服务中透明地运行，并且代表一种运维工具；Dapr必须通过HTTP或gRPC显式调用，面向开发人员的显式工具。
- Apache Camel是一个成熟的集成库，可以在Kubernetes上重新发现自己。其子项目Camel K 大量使用运营商模型来改善开发人员体验并与Kubernetes平台进行深度集成。尽管Camel K不依赖于sidecar，但通过其CLI和操作员，它能够在不到一秒钟的时间内重用同一应用程序容器并在远程Kubernetes集群中执行任何本地代码修改。这是通过运营商模型开发人员为目标的软件使用量的另一个示例。
有一些基于GraalVM实现的新Java项目，例如Quarkus。 从而减少了资源消耗和应用程序启动时间，从而使更多的工作负载吸引了边车(现在的JavaEE和Spring都无法做到)。所有这些创新将使边车模型更具吸引力，并使创建更多此类项目成为可能。
更具体用例的项目：例如对长期运行的有状态编排（例如，边车中的业务流程模型和注释（BPMN）引擎）进行的处理，我并不感到惊讶。边车上的作业调度程序。无状态集成引擎，即Sidecar中的Enterprise Integration Patterns实现。
运维者模型
(banq注：将软件直接交付给运维者，软件研发和软件实施的两个阶段实现分离，研发团队交付带有yaml配置的Docker容器镜像，实施团队直接一键部署运维监控，两者之间不再扯皮。)
基于容器的运维者交付模型好处是：
- 支持多语种消费者，通过提供可通过开放协议和标准使用的库，可以开放为所有编程语言。
- 应用架构不可知，显式的sidecar体系结构（与透明的sidecar体系结构相反）是一种软件功能消耗的方法，它作为以开发人员为中心的API后面的单独运行时。它是一个正交功能，可以添加到任何应用程序中，无论是单块，微服务，基于函数，基于参与者还是介于两者之间的任何东西。它可以在不太动态的环境中紧挨着一个整体，或者在动态的基于云的环境中紧挨着每个微服务。在Kubernetes上创建辅助工具很简单，并且在许多其他软件编排平台上也可行。
- 容忍释放阻抗不匹配：您的团队与消费使用的第三方库供应商之间的阻抗不匹配变得更易于管理。
当某个功能作为库包或框架使用时，它会包含在您的应用程序运行时中，您有责任了解它的工作原理，配置，监视，调整和升级。这是因为语言运行时（例如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，虽然迟了一步，但是有希望。)