对于那些致力于将人工智能技术融入产品并开发新的使用方式的组织来说，机器人和自动驾驶汽车并不是其关注的重点。与其相反，人工智能技术的开发是从人们的行动中学习，从而在日常生活中更有效地提供帮助，为人们解答问题，并在工作和家庭中通过语音识别和语言处理功能完成任务。
署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 。整个过程都不需要修改代码。
基准代码 转化为一份部署(非开发环境)需要以下三个阶段：
构建阶段，将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码,获取和打包依赖项,编译成二进制文件和资源文件。
例如：状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、 基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-Runtime Microservices）。
文化（Culture）---要实施 DevOps，就首先要让开发和运维人员认识到他们的目标是一致的，只是工作岗位不同，需要共担责任。这就是 DevOps 需要首先在文化层面解 决的问题。只有解决了认知问题，才能打破不同团队之间的鸿沟，实现流程自动化，把大家的工作融合成一体。
自动化（Automation）---DevOps 的持续集成的目标就是小步快跑，快速迭代，频繁发布。实施 DevOps，首先就要分析已有的软件开发流程，尽量利用各种工具和平台，实现开发和发布过程的自动化。经过多年发展，业界已经有一套比较成熟的工具链可以参考和使用，不过具体落地还需因地制宜。
Serverless 和 容 器 技 术 也 开 始 融 合 得 到 了 快 速 的 发 展。通 过 Serverless 容 器， 一 方 面 根 本 性 解 决 Kubernetes 自身复杂性问题，让用户无需受困于 Kubernetes 集群容量规划、安全维护、故障诊断等运维工作；一方面进一步释放云计算能力，将安全、可用性、可伸缩性等需求下沉到基础设施实现。
当然，这是他们根据产品的情况以及公司所处的发展阶段做的取舍：当时公司不急着变现于是收入被拿掉了，日活做的数据没有太大作用于是被拿掉了，拉新也被拿掉了。
他们觉得产品留存很好，在当下阶段团队已经做到能力范围的上限了，投入更大的精力也不会有很大的提升。之后，他们只留下了日活跃占比和日活跃参与度，并调整了内部的报表体系。
Serverless 具备很多优势, 比如：降低运维成本，提升系统安全性，提升研发效率，加速业务交付等等。然而 Serverless 还有一些不能回避的问题需要我们来做判断：
