云原生「寒武紀大爆發」，它為什么這么「香」？
先講一個故事。
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 微服務的本質：
“將一個個業務功能拆分出來，并由一個微型團隊來開發、構建、運維，團隊與團隊之間通過定義清晰的邊界進行溝通”。
