先讲一个故事。

4000多个模块，100万条指令，超过5000人年，耗资数亿美元，这是IBM公司开发 OS/360系统的投入成本。有人预估，IBM投入成本达到了美国「曼哈顿」原子弹计划的四分之一。尽管如此，项目还是延期交付，并且在交付使用后发现了大量缺陷。

那时，正处第二次软件危机，人机和谐共处持续了十余年。但，机器算力持续膨胀，它超出了人类个体生理极限，也超出了人类群体的沟通极限。

现在来看，现有的许多软件架构和开发方法，都在逐渐与硬件算力规模对齐。例如，适配云计算与分布式的主流架构形式的微服务，它们在为人们解决了更复杂软件问题的同时，也正在让企业现代化应用的建设、交付与运维推向更高层次。

今天你我所谈的云原生，便是这次变革浪潮的开端。

云原生的孕育：生于云上，长于云上

云原生，英文名为Cloud Native，顾名思义，云原生是云计算的「娃」，它生于云上，长于云上，在云上以一种全新的、高效的方式帮助企业部署应用。

可以说，云计算产业发展近二十年，发展的重点从「面向云迁移应用」转向「在云上构建应用」，云计算也已然开启了新的范式——以容器、微服务等为代表的云原生时代。

其实，云原生这个概念，在八年前才第一次被完整系统地提出。

2013年，Pivotal（美国云软件开发工具与服务公司）的Matt Stine，根据多年经验，总结出了一套方法论，包括对文化、组织架构的重组和建设，还有具体的操作工具。

Matt特别点出了，基于DevOps、持续交付、微服务、敏捷基础设施等技术和管理方法，让企业也能「享受」云的高效和持续的服务能力，这标志着相对完整的「云原生」范畴，正式形成。

不过，这在当时并没有引起太大的注意。

直到2015年，CNCF（云原生基金会）正式定义了「云原生」，才被大众广泛认识。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

眼下，云原生加速开启了一次技术产业革命，它蕴藏了很多广阔且还未被挖掘的前景。

据Forrester《亚太区市场趋势预测2022》报告，2021年，全球云原生应用持续上升，开发人员报告其组织中容器（33%至42%）和无服务器技术（26%至32%）的使用率都发生了迅猛增长，两者在一年内都增长了75%以上。

来看明年，在采用云优先战略的亚太公司中，30%将转向云原生，以推动技术驱动的创新。一些亚太地区的公司将优先考虑基于容器、面向微服务的架构，在混合云和多云环境中具有分布式能力，而不是只为新工作负载采用云解决方案。

用过云原生的企业，直呼「真香」，云原生使用率上升，并迎来了「寒武纪大爆发」时代。它为什么受到企业追捧？有哪些特点？对企业IT工作模式和文化产生了哪些影响？遇到了哪些挑战？企业如何解决？

就云原生技术特点、发展趋势和未来前景，红帽中国首席架构师张家驹、招商银行资深云计算架构师罗文江、Elastic开发者布道师、中国DevOps社区组织者刘征和某信息科技公司首席架构师任钢，在2021年红帽论坛“云原生之夜”期间展开了对话，其中的观点值得云计算产业深思。

云原生的练就：三大绝技，各显灵通

刚才提到，云原生概念，本是一系列思想集合，包括微服务、持续交付和容器化等等。任钢指出，它们也构成了云原生的三大特点，各有侧重，各显灵通，我们逐个来看。

“在云原生的场景里，如今已经离不开容器化了。”任钢说道。

容器，不仅能够让「砖头」更小，「颗粒度」更细，「搬砖」更轻松，实现比虚拟化更细的资源分割。再配合K8S等编排、调度工具的加持，IT基础设施秒级弹性不在话下。

“谈到容器化，不仅是指以Docker为代表的容器化和容器引擎技术，还有容器化运行平台、底层的云平台资源，在企业内部还要有一些物理架构、混合架构。”任钢说，容器实现了多种环境的互操作性，让计算资源的颗粒度比虚拟机更小，部署更灵活。一旦把云应用容器化之后，就很方便企业在所有环境上做统一管理和部署。

对于微服务来说，有人比喻，如果说此前软件是「钢筋混凝土般」的「单体大块头」，那么，微服务「化整为零」的思路，将「大块头」变成了模块化、积木式的「乐高」，将单体大应用，拆分成功能相对独立的小应用。同时，K8S和ServiceMesh等一系列技术，也让「搬砖」更轻松。

任钢对微服务有两种理解——狭义微服务和广义微服务。

狭义微服务，就是单指把一个很大的单机程序，变成一个个小的服务；广义微服务，不仅包括前者，更包括了微服务管理，例如，微服务的发现机制、微服务的配置、微服务的网关等等，这些构成了整个微服务的架构。

“然而，不管是广义还是狭义，企业都要接受并且实践微服务这个概念。”任钢说。

张家驹更是强调，微服务不光是一个技术问题，也是一个整体业务拆分、研发组织、团队分工问题。正如1968年一个叫梅尔文·康威的程序员的论文中所写，有什么样的组织架构就会设计出什么样的系统架构，这就是著名的康威定律。

大公司中一个个独立作战的小团队，它们的组织沟通与协助方式，正是微服务的本质，也彰显了云原生很强大的魅力。

谈云原生，避免不了要谈云原生的组织、流程、文化，自然就与DevOps核心理念分不开。

作为一种主流的软件开发交付模式，DevOps的应用，很好地填补了开发端和运维端之间的信息鸿沟，研发和运维水乳交融，你中有我，我中有你。确切讲，DevOps并不像是某种技术，而是一种软件工程文化。

其实，DevOps早在与云原生之前推出，并且在企业落地和应用，已经积累了大量的基础，云原生概念火了之后，基于DevOps的应用系统交付结合到云原生之中，发展到如今，DevOps变成了云原生的一大特征。

“另外，DevOps在云原生中很重要的理念之一，便是持续交付。持续交付就表示，代码可以小时级别、分钟级别实现部署，每一个业务需求都能以最短的时间交付给用户。”刘征表示。

云原生的历练：准入门槛，恶补功课

与云原生技术变革相伴的，是它对各行各业以及IT从业群体的影响。

以招商银行自身探索实践举例来看。招行是金融行业数字化转型中的一面旗帜，在很多技术理念上大胆创新。

沿着时间线看，2015年，开始研究DevOps技术；2016年，做DevOps平台建设；2017年开始推广，2018年全面落地。“DevOps目前支持了总行、分行还有子公司的IT业务，规模流水线已经上万，后面又衍生出一些需求空间，比如原来的流水线CI/CD，前置到需求空间，满足各个室组的电子看板需求。”罗文江谈招行这些年的探索。

目前，招行有超过30人的研发团队，上个月已经发布了99个迭代。“不过，如果各位有机会进招行，首先要把DevOps学会，要不然没法干活。”罗文江打趣说道，不懂DevOps，很难胜任IT建设工作，因为DevOps在银行数字化转型起到了非常重要的作用。

在罗文江看来，DevOps应该是一家优秀企业早就应该具备的一项能力，很多企业要做云原生之前，恐怕要恶补一下DevOps这门「功课」，否则很难驾驭。

或者，企业可以向技术提供商寻求帮助，就像招行在进行底层基础设施平台建设的时候，就选择了红帽来提供技术支持，到如今，OpenShift支撑了招行DevOps上万条流水线的并发度。

不过问题来了，DevOps可以更快交付转型微服务架构的应用，但是非微服务架构的应用是否都要转型到微服务架构的应用？罗文江认为并不一定。

技术间的融合已经在发生，但要不要上微服务，要根据各个团队的业务系统的需求特征，由团队自主选择。

一些典型的例子，也贯穿在招行的实践中。

在2019年，招行做了一个SaaS应用，叫做幸福通，它是从银行的工资代发场景出发，从中小企业的上下链，如财务、人事等流程入手，打通批发、零售各个系统，打通不同终端。这个应用必须要迭代开发，快速交付市场。当时的IT团队就选择了微服务架构，现在基本能做到一年一个大版本迭代。

云原生的图景：技术碰撞，享受价值

作为构建云原生应用非常重要的一个框架，红帽开源Quarkus相对Spring Boot 框架Java的“老式语言”，完全继承了云原生的基因。

“它推出的时候，完全是基于Kubernetes来做的，设计之初，就做到像「电」一样，叫它启动就启动，让它退出就退出；而Spring Boot不是这样，它启动慢，占用内存大，耗费资源多等等，这就是两者之间最大的一个区别。”任钢说道。

谈到云原生时代的运维新范式，例如，不可变基础设施，刘征认为其背后所暗含的意义在于，对IT运维团队颠覆性改变和指数级价值创新。

和可变基础设施相比，不可变基础设施在处理服务器的方法，如创建、维护、更新、销毁等方面差异很大。前者，可部署后进行更改；而后者，需保持不变并最终被替换。

如何来理解？他做了一个非常有趣的比喻：如果任何一个虚拟机坏了，或它的服务出现故障，可以像牛一样「宰掉」，换新的直接替换它；而对待可变基础设施，需要像猫咪一样去「娇养」。

任钢认为，这种颠覆性的概念转变，一方面能够保证基础架构中更高的一致性和可靠性，以及更简单、更可预测的部署过程；另一方面，它可以缓解或完全防止可变基础架构中常见的问题，例如配置漂移等。

“即使你再不习惯，也要果断适应到新的不可变基础设施操作方式上来，享受云原生时代的好处。”任钢坦言。

结语

显然，云原生不仅提升的是交付速度，且是企业现代化应用的建设、交付与运维的重新定义，云计算的推翻、重构和迭代。

云原生，它恰逢之时，在万千行业数字化转型浪潮当下，被挖掘，被扩散，逐渐形成星火燎原的势态。

*1 CNCF（云原生基金会）定义下的「云原生」：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

*2 康威定律：

”系统设计（产品结构）等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构，简单一点理解就是：系统设计受限于设计系统的组织架构形式“ 。

*3 微服务的本质：

“将一个个业务功能拆分出来，并由一个微型团队来开发、构建、运维，团队与团队之间通过定义清晰的边界进行沟通”。