不可能永远保持同样的用户流量，二八原则对于很多业务系统依然适用（ 80% 的用户流量集中在 20% 的时间段）。
这是因为在 Serverless 的世界中，不再具有服务器资源这样的概念，应用的载体是 SAE 调度出来的沙箱容器，每个实例只有在真正投入使用后，才会按使用时长进行计费。
对于开发者而言，他们不用关心应用到底部署在物理机里面，还是虚拟机里面，或是容器里面，也不需要知道底层的操作系统是什么版本的，只需要关注每个应用实例占据多少运算资源就可以了。如果应用需要从 4 个实例扩容到 6 个实例，或者缩容到 2 个实例，只需要一个指令就可以完成，甚至与 SLB 的绑定关系，都可以自动的建立或解除，这是 Serverless 技术为开发者带来的巨大价值。
以及应用层（包括 JVM 分析、接口调用分析等方面）的监控能力。如果需要更高级的 SQL 分析、异常分析、链路上下游和接口快照，可以集成阿里云应用时间监控产品（ARMS）。
对于线下 IDC 而言，计算资源是需要预先规划的，扩容并不是一件简单的事情，可能会因为各种条件的制约而导致扩容无法实现。
根据这个流程，如果需要扩容一个应用实例，保守估计也需要 20 分钟以上，其中购买、系统初始化、应用部署都需要占用大量的时间。假设系统流量突增，需要在 2 分钟之内紧急扩容，这个方案就无用武之地了。
因此在数据采集层需要建立了一套标准的数据采集体系方案，并致力全面、高性能、规范地完成海量数据的采集，将其传输到大数据平台。
既需要能支持实时流式计算、也能实时各种时间窗口的批量计算。另一方面，也通过数据同步工具直连异构数据库（备库）来抽取各种时间窗口的数据。
特别是要由唯一团队负责将核心业务数据统一加入数据中间层。允许部分业务数据有独立的数据团队按照统一的OneModel体系方法论建设数据体系
在面向应用提供服务时，业务团队或深入业务线的数据团队有极大的自由度，只要依赖数据公共层，即可自由的建设ADS数据应用层。
