对于数据驱动，很多人做到一定程度之后，脑海中会形成一定的方法论和体系，进而形成驱动流程和组织机制。大家也听了很多方法论，包括增长黑客等，貌似自己已经很懂数据驱动了，但是实际操作起来可能连“什么是事件属性这种基础的概念都不了解”，这是很多业务线同学普遍的现状。
架构复杂性：Serverless 开发者无需关注底层基础设施的复杂性，但是应用架构的复杂性需要格外关注。事件驱动架构和细粒度函数微服务，与传统开发模式非常不同。大家需要根据业务需求和自己的技术能力，在合适的场景应用，然后逐渐扩大应用范围。
现在，很多企业都想实现数据闭环，其实闭环就是非常典型的方法论。那么，这个方法论究竟能不能解决问题？能不能在组织和团队里运行起来？背后是否缺失了哪些环节？在这里，陈新祥分享了一个国内的实际案例。
在整个流程里，最关键的是要有专人做统一收口，基于对数据和采集的理解做分流，中间规范跟标准动作要规范，因为不论是新版还是新功能上线都要走这个流程。
十年前，Google成为了分布式系统链路追踪服务的先行者，并通过《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》这篇著名论文阐述了如何在超大规模系统上建设低损耗（low overhead）、应用级透明（application-level transparency）、大范围部署（ubiquitous deployment）的链路追踪服务。
理想的微服务应用只有不同层级之间的单向依赖，这种依赖的原则是高层应用依赖于低层应用。同层应用之间的相互依赖，或者低层应用依赖于高层应用都是违背这个原则的。假设我们在全局拓扑视图里面，找到了环状依赖关系，说明微服务应用之间的依赖关系不清晰，可以考虑对应用的层次结构进行重构。
基准代码 转化为一份部署(非开发环境)需要以下三个阶段：
构建阶段，将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码,获取和打包依赖项,编译成二进制文件和资源文件。
同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、 基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-Runtime Microservices）。
DevOps 过程考核的标准应该鼓励团队更加注重工具的建设，自动化的加速和各个环节优化，这样才能最大可能发挥度量的作用。
从 ISV 和客户视角去看零售云该怎么构建产品和快速交付，而云原生技术体系将可以帮助快速构建 2B 生态的产品和技术体系。云原生技术体系基本可以使用阿里云的云产品和技术基础实施，面对不能满足的场景需要考虑自建还是共建方式
