有些中大型企业会有多套的测试环境，这些测试环境一般晚上都不使用，在 ECS 模式下，是需要长期保有这些应用实例的，闲置浪费的成本比较高。
应用开发不仅需要关注业务逻辑，还需要关注数据，将领域模型、业务流程、配置等数据以Online形式存储。近几年，数据库技术发生了很大的变化，HBase等分布式数据库提供的强一致保证给云原生应用的设计和开发带来了许多好处。
在一个频繁迭代的系统中，每个应用会经常性面临新版本发布需求，需要对应用的上线、下线、更新、回滚等流程进行集中性的管理，并配合精细粒度的灰度发布手段，减少版本迭代对业务造成的影响。
Serverless 技术的出现，为提升资源利用率提供了新的思路。Serverless 是一种构建和管理基于微服务架构的完整流程，允许开发者脱离服务器资源而直接部署应用。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）的计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作服务器资源，真正做到了部署应用无需涉及基础设施的建设。
通过多种弹性机制，能够对系统容量进行精细粒度的管理，使资源的使用量能随着业务流量的变化而调整，从而极大程度的增加资源利用率，大幅降低资源成本。
根据调研机构IDC公司最近发布的一份《全球人工智能支出指南》，预计全球人工智能预算将在未来四年翻一番，到2024年将达到1100亿美元。
在一个简单的微服务架构中，如果某应用处于整个链路的入口位置，它的前端一般会挂上负载均衡组件（上图中的应用 A），以承接来自于最终用户的业务请求。这类应用在进行生命周期管理的时候，复杂度会更高，为了确保应用在新版本发布过程中的平衡稳定，会经过如下的步骤：
delete也是天然满足结合律的，而无论之前都有什么操作，只要执行就好了。
在insert和update操作里面，都有一个转换的过程，而这里有个前提，那就是从DRC拿到的变更数据每一条都是全字段的。可能有人会说这里的转换可以用replace into替换，为什么没有使用replace into呢，首先由于顺序错乱的情况毕竟是少数，而且我们并不单纯复制数据，同时也是在复制操作，而对于DRC来说，replace into操作会被解析为update或insert。这样无法保证消息唯一性，也无法做到防循环广播，所以并不推荐。
模块化程度越来越高 - 自包含的应用打包方式，应用与底层物理基础设施解耦。
自动化运维程度越来越高 - 自动化的资源调度和弹性伸缩能力，用户将关注点逐渐聚焦到应用自身。
比如，服务网格 Istio、机器学习平台 Kubeflow 以及无服务器应用框架 Knative 等等。通过这样的架构分层，进一步降低了技术门槛，加速了云价值释放。对于企业客户而言，他们可以通过 Kubernetes 这样的开放标准来设计企业的云架构、避免厂商锁定的顾虑，更好地支持多云 / 混合云。容器技术和生态的发展会加速云计算规模经济形成。所有的云厂商都在加大对容器技术领域的投入。
