在传统的运维领域有很多问题比较难解决，比如服务器因为各种各样的原因，突然负载高或者 CPU 高等，这时在传统领域通常需要大量的手动运维操作，而在 K8s 领域结合可观测、健康检查，只需配置好 liveness 和 readiness，就可以实现自动化的运维，K8s 会自动进行切流以及自动化地重新调度，极大地降低了运维成本。
不仅 ECS 机是托管的，K8s 也是内部托管运维的，客户完全不需要购买服务器或者购买 K8s 或者运维 K8s，甚至都不需要懂 K8s，极大地降低了客户的入门门槛和薪资负担。
而在 SAE 中，用户就可以把一些与业务无关的特性交给 SAE，用户只需要关注自己的业务，包括微服务的用户中心、群组中心等，以及和 SAE 的 CI/CD 工具做一个集成，就可以快速实现微服务架构。
作为一个复杂的业务应用，如何实现技术支撑对蚂蚁非常关键。蚂蚁目前正在尝试许多FAAS相关的技术选型，但从更大的范围来看，微服务仍然是主流的选择。蚂蚁所使用的微服务架构本身也在不断演进，比如把和业务无关的功能下沉到Sidecar，将数据库的一些中间件mesh化等。尽管从应用研发的角度看，蚂蚁所使用的架构风格相比于原来发生了很大的变化，但从整体趋势来看，最主要的变化仍在于将和业务能力无关并且和基础设施相关的能力下沉。
微服务思想以及相关的技术为 IT 架构的发展带来了一系列深刻的变革：
易于开发和维护：一个应用只会关注一组特定的业务功能，通过服务拆分，能减少应用之间的耦合度，让开发和维护更加简单。
技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
加快系统演进速度：每一个应用都可以独立的进行版本更新，通过灰度发布等技术手段能确保发布过程中整个系统稳定运行。
世上没有免费的午餐，微服务技术让 IT 系统变得更敏捷、更健壮、更高性能的同时，也带来了架构复杂度的提升。对于开发者而言，要想更好的驾驭微服务架构，需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。幸运的是，针对这些普遍存在的难题，业界涌现了一系列优秀的开源技术组件和工具，让开发者可以更轻松的构建微服务应用。像 Spring Cloud 和 Dubbo 这样的技术框架，经过多年的发展，已经演化为微服务领域的通用标准，极大地降低了微服务的门槛，但这些技术框架依然没有办法解决其中两个最大的挑战，这两个挑战成为摆在开发者面前的两座大山。
资源利用率低的根本原因，在于以服务器为载体的应用架构中，开发者需要将构建好的程序包部署到服务器上，从而对多个用户事件进行响应。为了确保事件响应的及时性，需要让程序长驻于服务器上，而且尽可能保守的规划资源，以避免出现负载过重而导致服务崩溃的情况。在这个过程中，实际的负载在时间上分配并不均衡，从而导致整体的资源利用率偏低。
定时弹性机制：对于会预期发生的周期性行为，可以设置定时弹性策略。举例：如果每天的上午 9 点是业务高峰，可以定时每天 8 点半增加实例数量，并在 9 点半减少实例数量。
基于指标阈值的弹性机制：对于超出预期的业务流量突增，可以设置基于指标阈值的弹性策略，根据 CPU 、内存等资源指标，以有 QPS 等业务指标让应用实现自动的弹性缩。
