1.1.2 企业为什么需要云原生
云的核心理念是弹性，站在云的视角，过去我们常以虚拟化作为云平台和与客户系统交互的界面，为企业带来灵活性的同时也带来了一定的管理复杂度。容器的出现，在虚拟化的基础上向上封装了一层，逐步成为云平台和与客户系统交互的新界面之一，应用的构建、分发和交付得以在这个层面上实现标准化，大幅降低了企业 IT 实施和运维成本，提升了业务创新的效率。从技术发展的角度看：开源让云计算变得越来越标准化，容器已经成为企业应用分发和交付的标准，可以将应用与底层运行环境解耦；Kubernetes成为资源调度和编排的标准，屏蔽了底层架构的差异性，帮助应用平滑运行在不同的基础设施上；在此基础上建立上层应用抽象（如微服务和服务网格），逐步形成应用架构现代化演进的标准，开发者只需要关注自身的业务逻辑，无须关注底层实现。云原生正在通过方法论、工具集和理念重塑整个软件技术栈和生命周期，帮助企业和开发者在云上构建和运行可弹性扩展、容错性好、易于管理、便于观察的系统。有了诸多标准化的产品技术，企业上云的拐点已经到来，云原生已经成为释放云价值的最短路径之一。
云并非把原先在物理服务器上运行的东西放到虚拟机里运行，真正的云化不仅是基础设施和平台的事情，应用也要改变传统的做法，实现云化的应用——应用的架构、应用的开发方式、应用部署和维护技术等都要做出改变，真正发挥云的弹性、动态调度、自动伸缩等一些传统IT所不具备的能力。这里说的“云化的应用”也就是“云原生应用”。云原生架构和云原生应用所涉及的技术很多，如容器技术、微服务、可持续交付、DevOps等。
1．业务复杂需要云原生
PC的普及，改变了人们加工处理个人数据的方式；移动互联网的普及，改变了人们获取信息的方式；即将到来的万物互联的时代，改变了人们与周围世界的交互方式。随着业务的发展，企业IT架构也随之发生巨大变化，而业务又深度依赖IT能力。
IT系统让人们的工作和生活越来越简单便捷的同时，其自身的架构却变得越来越复杂。随着技术的发展，业务规模的暴增，商业模式的创新，企业的应用系统也经历了单体应用、应用分层、分布式应用、云应用等不同应用形态。原来一个系统由一个团队就可以开发维护，慢慢发展到一个系统由数十个应用构成，需要几十个团队相互协作，甚至像淘宝、天猫这样的巨型系统，需要上千个应用，由几百个团队开发维护。微服务架构能够解决大型分布式系统的团队协作问题，每个团队独立负责一个或者若干个服务，团队对于所负责的服务拥有绝对的决策权，以减少组织的技术决策成本。服务之间通过契约化的接口以缩小沟通范围，只要接口不变，就无须关注外部的变化，从而减少组织的技术沟通成本。
在微服务架构中，应用的数量大幅增加，性能、一致性等问题越来越严重，架构变得越来越复杂，大量服务的治理也变得充满挑战，如何处理和解决这些问题？正如人类社会发展伴随着技术革命与社会大分工一样，云原生技术的出现解耦了很多复杂性，这是IT技术的进步。
（1）以Docker为代表的容器技术实现了应用与运行环境的解耦，众多业务应用负载可以被容器化，而且应用容器化满足了敏捷、可迁移、标准化的需求。
（2）Kubernetes的出现实现了资源编排调度与底层基础设施的解耦，应用和资源的管控也开始得心应手，容器编排实现资源编排、高效调度。
（3）以Istio为代表的服务网格技术实现了服务实现与服务治理能力的解耦。
业务的发展能驱动技术的进步，技术的进步又反哺业务创新。云原生概念及技术提出几年以来，得到众多软件厂商以及云厂商的参与支持，他们也在纷纷贡献自己的产品与技术，绝大多数云厂商提供了容器、Kubernetes编排管理的OpenAPI、软件开发工具包（Software Development Kit，SDK）等丰富的开发工具，实现第三方被集成，为云的生态伙伴提供更多的可能性。这样的技术分层推动了社会分工，极大促进了云原生技术和云原生生态的发展。
2．业务创新需要云原生
互联网（尤其移动互联网）的蓬勃发展提高了业务的推广速度，云产品以及服务大幅降低了海量数据与高并发的技术门槛，二者共同作用，使业务的创新速度达到了前所未有的程度。每天有无数的新App产生。一个App从最初上线到日活跃用户过十万、百万、千万，可能只需要短短几个月的时间。我们正处在一个业务快速增长的时代，产品既需要更快的交付速度以便验证业务可行性，又需要更好的用户体验以便在众多的App中脱颖而出。这也是传统企业竞争不过互联网公司的原因。其中一个重要的因素是产品的进化速度太慢，不能根据用户的反馈快速迭代。当某个功能用户使用频率比较高时，产品的发展方向可能会随时发生转变，需要不断在市场中调整和演进产品的发展路线。万众创业的时代机会转瞬即逝，如果不能在第一时间抓住市场的热点，企业很快就会被市场淘汰。有研究数据表明：中国互联网企业的平均生命周期普遍在3～5年。“3年”成为划分一个企业生命周期的分界线。
产品交付速度的提高不能以降低可用性为代价。我们知道，变更是可用性的“天敌”，以阿里巴巴为例，有统计数据表明，超过50%的线上故障是变更引起的，也正因如此，每逢重要的节假日或者大促活动节点，我们都会进行“封网”，以确保线上系统的稳定和可靠。当然这也是目前技术不够成熟，不得已而为之的折中和让步。就像目前很多传统企业的线上管理策略，提升可用性的一种方法就是少发布、多审核，这显然是和快速试错、快速交付、快速迭代的互联网思想背道而驰的。在传统行业中，企业的应用系统一般是有一个工作时间的，应用的发布和变更会选择在非工作时间进行。但在互联网行业中，尤其在全球化背景下，我们要求应用系统具有7×24小时不间断的在线服务能力，不存在非工作时间，甚至不存在业务低峰期，这就对企业的应用系统运维提出了更高的要求。云计算已经重塑了软件的整个生命周期，从架构设计到开发，再到构建、交付和运维等所有环节。云原生通过一系列产品、工具、方法减少变更导致的可用性问题，而不是因噎废食地控制变更、减少发布次数。
互联网公司经常提到他们每天实现几十次，甚至上百次的发布。为什么频繁发布如此重要？如果你可以每天实现上百次发布，那么你就可以几乎立即从错误的版本中恢复过来；如果你可以立即从错误中恢复过来，那么你就能够承受更多的风险；如果你可以承受更多的风险，那么你就可以做更“疯狂”的试验——这些试验结果可能会成为你接下来的竞争优势。
3．业务不确定性需要云原生
云最主要的特性之一就是弹性，这也是企业应用上云最核心的需求。随着移动互联网的普及，以及网红经济、热门事件营销、秒杀大促等商业模式的推陈出新，企业的业务流量变得无法预估。当然，为了应对突发流量的冲击，企业也可以购买更多更高规格的服务器；但对于绝大部分业务平峰期以及低峰期， CPU都是空闲的，这会让资源使用率指标很低。通过云的弹性伸缩，可以应对业务突发流量的冲击，保证业务的平稳运行，提高资源利用率，降低IT运营成本。
随着企业的应用系统进行分布式改造，应用由一个单体应用被分割为众多的微服务应用，整个应用集群的节点数由原来的数十个快速上升到了数百以至上千个，垂直拆分带来良好隔离性的同时，也使资源的利用率大幅下降。互联网公司通过以下两个开创性的举措来解决这个问题。
（1）不再继续购买更大型的服务器，取而代之的是用大量更便宜机器来水平扩展应用实例。这些机器更容易获得，并且能够快速部署。
（2）将大型服务器虚拟化成几个较小的服务器，并向其部署多个隔离的工作负载，从而改善现有大型服务器的资源利用率。
纵观IT应用服务器的发展历史：大型机→小型机→x86服务器→虚拟机→容器→Serverless，越来越朝着轻量化的方向发展，这也符合云原生敏捷基础设施的策略。轻量化意味着更好的弹性，应用部署时间相应减少：月（大型机）→天（小型机）→小时（x86服务器）→分钟（虚拟机）→秒（容器）→毫秒（Serverless）。极致的弹性是企业解决业务不确定性的有效手段。
云原生的核心技术之一是容器。容器技术的兴起源于2013年开源的Docker。容器的价值可以从下面两个层面阐述。
（1）从应用架构层面，容器技术可以方便地支持微服务架构实现应用的无状态化，更加灵活地应对变化和弹性扩展。在软件生命周期管理方面，容器技术可以帮助把DevOps等最佳实践落地成可运用的标准化工具和框架，大大提升开发效率，加速迭代。DevOps的概念最早起源于2009年的欧洲（更早的20世纪90年代提出的柔性生产模式中也有DevOps的思想），但一直不温不火，直到Docker容器技术的流行，最近几年DevOps才为人们所津津乐道。
（2）从基础架构层面，容器技术带来的可移植性，可以帮助开发者和企业更便捷地上云和迁云，让应用在自有数据中心和云端实现动态迁移。随着容器技术和云计算的计算、存储、网络的进一步融合，更快速地推动从传统以基础设施为中心，向以应用为中心的IT架构转变。
容器解决了应用与运行环境的解耦，把运行环境也作为一种资源支持可编程式的管理；Kubernetes的出现则让资源的动态编排与管理变得更加简单，充分满足业务不确定对资源的弹性要求。
综上所述，云原生不是一个产品，而是一套技术体系和一套方法论。企业数字化转型是思想先行，从内到外的整体变革，更确切地说，它是一种文化，更是一种潮流，是企业云计算战略的必然导向。