淺談云原生—從概念到趨勢
閱讀完本文你將會
- 學到非常實用的云原生術語。
- 了解云原生是什么。
- 明白云原生的關鍵因素。
- 洞察2022年云原生的趨勢。
The Cloud isn’t a place, it’s a way of doing IT.
– Michael Dell, the founder of Dell Technologies.
1、 云原生是什么?
云原生(Cloud Native)，從字面上理解就是云計算和土著的意思——云計算上的原住民。
從Cloud來看，云可以看作是一種提供穩定計算存儲資源的對象。為了實現這一點，云提供了虛擬化、彈性擴展、高可用、高容錯性、自恢復等基本屬性。
再看Native，云原生和在云上跑的傳統應用不同。一些傳統應用是基于SOA(Service-Oriented Architecture,面向服務架構)架構來搭建的，然后再被放到云上。這些傳統應用沒有充分運用到云的優勢。
因為云作為一種分布式架構，它的原住民應該也是要符合這一特性的——就像我們常說的一方水土養一方人，如果水土不服那就會很糟糕!而微服務是具有分布式設計的屬性的。
其次云作為一種PaaS(Plarform as a Service, 平臺即服務)服務，云上的原住民的整個生命周期都應該是基于云的理念來實現的，那么就需要一套自動化的開發流程來實現。
這些是從字面上對Cloud Native的解構，然后我們再來看看云原生計算基金會(Cloud Native Computing Foundation, CNCF)提供的官方定義：
Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
根據官方定義，我們總結下云原生就是：
- 基于容器、服務網格、微服務、不可變基礎設施和聲明式 API 構建的可彈性擴展的應用。
- 基于自動化技術構建具備高容錯性、易管理和便于觀察的松耦合系統。
- 構建一個統一的開源云技術生態，能和云廠商提供的服務解耦。
云原生是關于速度和敏捷性的。企業的業務系統正在從實現業務能力演變為加速業務速度和增長的戰略轉型武器。
同時，隨著用戶的要求更多，業務系統也變得越來越復雜。它們更加期望快速的反應能力，創新的功能，以及零停機。
性能問題、重復性的錯誤和無法快速迭代已不再被接受。當出現上述這些情況，你的用戶將會訪問你的競爭對手。
2、云原生的關鍵因素
云原生的速度和敏捷性來自于許多因素。
本章我們將會講述其中最主要的六大因素。
（1）云架構(Cloud Infrastructure)
云原生系統充分利用了云服務模式的優勢。這些系統的設計目的是為了在動態、虛擬化的云環境中茁壯成長。它們廣泛使用PaaS的計算基礎設施和管理服務。它們將底層基礎設施視為一次性的-在幾分鐘內完成配置，并通過自動化按需調整、擴展或銷毀。
在云原生領域，有一個類比的概念叫做Pets vs. Cattle，字面理解的意思就是寵物 vs. 牛。
Pets-寵物
在傳統的數據中心，服務器被視為寵物：一臺物理機器，被賦予一個有意義的名字，并由你照顧。你通過向同一臺機器添加更多的資源來進行擴展。如果服務器生病了，你要照顧它直到恢復健康。
在這種模式下，服務器被視為不可缺少的系統組件，永遠不可能停機。一般來說，它們是人工建立、管理和手動"喂養"的。這方面的例子包括大型機、單獨的服務器、HA(Highly Available,高可用)負載均衡器/防火墻、主/從數據庫系統等。
Cattle-牛
而Cattle的服務模式是不同的。你把每個實例作為一個虛擬機或容器來配置。它們是相同的，并分配給一個系統標識符。你通過創建更多的實例來進行擴展。當一個實例變得不可用時，沒有人注意到。
Cattle的模式使用不可改變的基礎設施。服務器不會被修復或修改。如果一個服務器出現故障或需要更新，它就會被銷毀，然后配置一個新的服務器。所有這些工作都通過自動化完成。
由兩臺以上的服務器組成的陣列，一般使用自動化工具構建，陣列中沒有哪個服務器是不可替代的。通常情況下，故障事件不需要人工干預，因為陣列表現出 "繞過故障"的屬性，通過重新啟動故障服務器或通過三重復制或編碼擦除等策略復制數據。
這方面的例子包括網絡服務器陣列，多主機數據存儲，如Cassandra集群，以及幾乎所有的負載平衡和多主機。
（2）現代設計(Modern Design)
你會如何設計一個云原生應用程序?你的架構會是什么樣子的?你會遵守哪些原則、模式和最佳實踐?哪些基礎設施和操作問題是重要的?
十二因素
如何構建一個云應用?業界廣泛接受的一個準則就是十二因素。
12因素是一系列云原生應用架構的模式集合。這些模式可以用來說明什么樣的應用才是云原生應用,可以用來衡量一個后端服務是否適合上云。
本節的反例并不是指技術本身不夠好，而是指它們的一些原生特性對于開發復雜的應用不夠友好。
CodeBase-基準代碼
One codebase tracked in revision control, many deploys。
一份基準代碼可以多份部署，可通過版本控制進行追蹤。
反例：多個無關項目、數百萬行代碼全部放到一個倉庫;對于差異需求，直接復制項目倉庫單獨開發，同時維護多個倉庫代碼。
Dependencies-顯式和隔離的依賴
Explicitly declare and isolate dependencies。
每個微服務都可以顯式聲明依賴并且互不干擾，擁抱變化而不影響整個系統。
反例：Node.js之父Ryan Dahl另起爐灶創造了Deno，Deno的import遠程代碼就是Node世界的npm反向極端，造成了隱式依賴;Golang在1.13之前沒有go module的時候，也是違反這條原則的。且不說不清晰的第三方依賴容易導致"投毒"，這對代碼的問題定位、維護、交接都是很大的負擔。
Config-配置分離至環境
Store config in the environment。
配置數據和構建產物完全分離，配置數據單獨管理，只在運行環境中出現。
反例：環境相關的配置，混在容器鏡像、甚至代碼包中，每個環境需要單獨構建打包一個版本。這種做法在傳統的開發模式中很常見。
Backing Services-分離后端服務
Treat backing services as attached resources。
把后端服務當作附加資源。后端服務是指程序運行所需要的通過網絡調用的各種服務，包括數據庫，緩存，消息隊列等。
反例：把緩存服務和應用服務打包到同一個容器鏡像，通過/var/redis.sock這樣的Domain Socket形式訪問;或者把第三方應用服務的源碼直接復制到自己的代碼中，在一個進程中互相調用。
Build, release, run-分離構建、發布、運行
Strictly separate build and run stages。
每個版本必須在構建、發布和運行階段實行嚴格的分離。每個版本都應該被標記為唯一的ID，并支持回滾的能力。CI/CD系統有助于實現這一原則。
反例：開發改完代碼，本地打個Patch發給運維，也不告知產品經理改了什么，直接口頭告訴運維批量更換某些文件。
Processes-無狀態的服務進程
Execute the app as one or more stateless processes。
每個微服務應該在自己的進程中執行，與其他正在運行的服務隔離。如果存在狀態，應該將狀態外置到后端服務中，例如數據庫、緩存等。
反例：應用服務的多個實例之間互相通信，共享一些內存數據;或者開發自治的集群選主、任務分發等功能。
Port Binding-端口綁定
Export services via port binding。
每個微服務都應該是獨立的，其接口和功能都暴露在自己的端口上。這樣做提供了與其他微服務的隔離。
反例：提供出去部署的包的是放到Tomcat的war、放到IIS的dll，自己本身沒有描述通信協議，也沒有指定綁定的端口，完全依賴Tomcat/IIS的配置。
Concurrency-并發能力
Scale out via the process model。
通過進程模型進行擴展，擴展方式有進程和線程兩種。進程的方式使擴展性更好，架構更簡單，隔離性更好。線程擴展使編程更復雜，但是更節省資源。
反例：把Session放到內存中。
Disposability-快速啟動和優雅終止的易處理
Maximize robustness with fast startup and graceful shutdown。
快速啟動和優雅終止可最大化健壯性，只有滿足快速啟動和優雅終止，才能使服務更健壯。
反例：很重的Java服務啟動耗時十幾分鐘;縮容靠kill -9強殺進程;服務也沒有實現收到SIGTERM信號進入"跛腳鴨狀態"，也沒有等待請求處理完再關閉進程。
Dev/prod parity-環境等同
Keep development, staging, and production as similar as possible。
盡可能地保持整個應用生命周期的環境相似，包括開發環境、預發布環境、線上環境等。
反例：開發環境不容器化，產線容器化;開發環境用的MariaDB，產線用的MySQL;開發環境數據庫沒主從，產線配置了主從同步。這樣在MySQL讀寫分離時，主從同步那幾毫秒的延遲導致各種奇怪Bug，在開發環境也許永遠都重現不出來。
Logs-作為事件流的日志
Treat logs as event streams。
將微服務產生的日志視為事件流。微服務架構中服務數量的爆發需要具備調用鏈分析能力，快速定位故障。
反例：項目中寫了一堆log4xx的復雜配置，日志文件存哪個路徑、多長時間輪滾、保留多久刪除。傳統的軟件這是必備的，但云原生應用，請僅保留打印到標準輸出/標準錯誤。還有一個反模式的例子，在應用內就通過代碼把日志拋到Kafka這類Broker中，無形中也讓應用服務和Kafka耦合到了一起。
很多人不相信日志打印到stdout/stderr就完事了，是因為不夠了解云原生世界中，各類日志收集和處理組件的強大。我們對傳統的做法習以為常，卻忘記了"單一職責原則"。
Admin processes-分離管理類任務
Run admin/management tasks as one-off processes。
把后臺管理任務當作一次性進程運行，一些工具類在生產環境上的操作可能是一次性的，因此最好把它們放在生產環境中執行，而不是本地。
反例：在應用服務運行環境中安裝一個數據庫客戶端，運維人員手動跑一堆修改數據庫的SQL;或者安裝一些運維腳本，放到機器的cron table定期執行一些腳本。
3、微服務(MicroServices)
（1）微服務是什么?
微服務架構是以開發一組小型服務的方式來開發一個獨立的應用系統，每個服務都以一個獨立進程的方式運行，每個服務與其他服務使用輕量級(通常是 HTTP API)通信機制。
這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署，同時服務會使用最小規模的集中管理(例如 Docker)能力，也可以采用不同的編程語言和數據庫。
如何確定微服務的顆粒度(Service granularity)，即如何定義這個"微"字?
對于這種問題的沒有共識，因為正確的答案取決于業務和組織背景。
把服務做得太小被認為是不好的做法，因為那樣的話，運行時的開銷和操作的復雜性就會壓倒微服務的好處了。當服務變得過于精細時，必須考慮其他的方法-比如將功能打包成一個庫，將功能轉移到其他微服務中。
所以微服務的"微"不能簡單認為是"小"的意思，我們可以理解為"合適"。
（2）微服務的優勢
- 云原生系統包含了微服務，微服務具有以下優勢。
- 由于組成服務的規模較小，它們可以從一開始就由一個或多個小團隊來構建，并且劃分好服務邊界。這使得在需要時更容易擴大開發力度。
- 一旦開發完成，這些服務可以獨立部署，也很容易識別熱門服務，并將它們獨立于整個應用進行擴展。
- 微服務還提供了更好的故障隔離，在一個服務出錯的情況下，整個應用程序不一定會停止運行。當錯誤被修復后，可以只為相應的服務進行部署，而不是重新部署整個應用程序。
- 微服務架構帶來的另一個優勢是更容易選擇最適合所需功能的技術棧(編程語言、數據庫等)，而不是被要求采取更標準化的、一刀切的方法。
下表展示了單體架構和微服務架構的對比：
（3）微服務的劣勢
事物都有兩面性，雖然微服務具有諸多的優勢，但是我們也需要正視使用它帶來的挑戰。
復雜性
首先，服務之間的通信可能很復雜。一個應用程序可能包括幾十個甚至幾百個不同的服務，而它們都需要安全地進行通信。
其次，微服務的調試變得更具挑戰性。一個應用程序由多個微服務組成，每個微服務都有自己的日志，追蹤問題的來源可能很困難。
最后，微服務的設計、開發、部署、測試會更加復雜。
接口控制
每個微服務都有自己的API，應用程序依靠它來實現一致性。雖然你可以很容易地對一個微服務進行修改而不影響與之交互的外部系統，但如果你改變了API(接口)，如果改變后不能向后兼容，任何使用該微服務的應用程序都會受到影響。
微服務架構模型導致了大量的API，這些API對企業的運作都是至關重要的。因此接口控制變得至關重要。
成本上升
要使微服務架構在企業中發揮作用，你需要有足夠的托管基礎設施，并有安全和維護支持，你還需要有熟練的開發團隊來理解和管理所有的服務。
如果你已經有了這些東西，轉移到微服務所涉及的成本可能會更低。但大多數目前正在運行單體架構的企業將需要投資于新的基礎設施和開發人員資源，以便進行轉移。
4、容器(Containers)
（1）容器是什么
Containers are a great enabler of cloud-native software.
《Cloud Native Patterns》的作者Cornelia Davis說，“容器是一個偉大的云原生推動者”。
而云原生計算基金會也將微服務容器化作為指導企業實現云原生藍圖的第一步。
容器是一種操作系統虛擬化形式。可以使用一個容器來運行從小型微服務或軟件進程到大型應用程序的所有內容。
容器包含所有必要的可執行文件、二進制代碼、庫和配置文件。但是，與服務器或計算機虛擬化方法不同，容器不包含操作系統映像。因此，它們更輕便且可移植，其開銷很小。
容器化一個微服務并不難，你只需要將軟件代碼和所需要的所有組件(例如庫、框架和其他依賴項)打包成一個二進制文件——容器鏡像。鏡像存儲在容器的注冊表中，而注冊表可以位于你的計算機上，在你的數據中心，或在一個公共云上。
當一個應用程序啟動或擴展時，你會將容器鏡像轉化為一個正在運行的容器實例。該實例在任何安裝了容器運行時引擎的計算機上運行。你可以根據需要決定擁有多少個容器化服務的實例。
下圖顯示了三個不同的微服務，每個微服務都在自己的容器中，并且都在同一臺主機上運行。
圖.容器
每個容器是單獨維護自己的依賴關系和運行時間集的，它們可能彼此不同。從圖上我們可以看出，不同版本的產品微服務是在同一個主機上運行的。
每個容器共享主機操作系統、內存和處理器，但是彼此是隔離的。這里很好地體現了上文中12因素的依賴性原則。
（2）容器的優勢
輕量級、可移植性
在容器中運行的應用程序可以輕松部署到多個不同的操作系統和硬件平臺。它們能夠共享主機的操作系統內核，不需要為每個容器提供單獨的操作系統，且允許應用在任何基礎架構(裸機、云)上運行相同的操作系統，甚至在虛擬機(VM)中。
成本降低
與傳統或硬件虛擬機環境相比，容器所需的系統資源更少，因為它們不包含操作系統映像。
改善了應用程序的開發
開發人員在一個主機環境中使用容器時，可以像在另一個主機環境中一樣使用相同的工具，如此，在各個操作系統間開發和部署容器化應用就變得更加簡單。而且容器支持敏捷的 DevOps工作，以加速開發測試并縮短生產周期。
容器 vs 虛擬機
虛擬機(VM)是一種創建于物理硬件系統(位于外部或內部)、充當虛擬計算機系統的虛擬環境，它模擬出了自己的整套硬件，包括 CPU、內存、網絡接口和存儲器。
容器化和虛擬化的相似之處在于它們都允許應用完全隔離，以便在多個環境中運行。而它們的主要區別在于尺寸大小和可移植性。
虛擬機在兩者中尺寸較大，通常以千兆字節為度量單位，且包含它們自己的操作系統，所以可以同時執行多個資源密集型功能。由于虛擬機的可用資源大大增加，因此它們可以抽象、分離、復制和模擬整個服務器、操作系統、臺式機、數據庫和網絡。
容器則要小得多，通常以兆字節為度量單位，且其中僅包含應用及其運行環境。
虛擬機高度兼容傳統的單體式 IT 架構，容器則兼容更新的新興技術，例如云、CI/CD(Continuous Delivery,持續交付;Continuous Deployment，持續部署) 和 DevOps。
由于容器的特性，微服務和容器可以很好地協同工作，因為容器中的微服務具有容器的所有的可移植性、兼容性和可擴展性。
（3）容器編排(Container orchestration)
雖然像Docker這樣的工具可以創建鏡像和運行容器，但是你也需要工具來管理它們。我們可以使用容器編排工具來完成容器的部署、管理、擴展以及聯網。容器編排可以為需要部署和管理成百上千個容器和主機的企業提供便利。
那么容器編排到底做了什么呢?
- Scheduling-任務安排。
自動提供容器實例：
- Affinity/anti-affinity-親和/反親和。
- Health monitorinh-健康檢測。
自動檢測和糾正故障。
- Failover-故障轉移。
自動將一個失敗的實例重置到一個健康的機器上。
- Scaling-自動擴展。
自動添加或刪除一個容器實例以滿足需求。
- Networking-聯網。
管理用于容器通信的網絡層。
- Service Discovery-服務發現。
使容器能夠相互定位。
- Rolling Upgrades-滾動更新。
協調增量升級，實現零停機部署，自動回滾有問題的更新。
我們可以發現容器編排體現了12因素中的易處理原則和并發性原則。
5、后端服務-Backing services
圖.后端服務
App在運行過程中通過網絡消費的任何服務都可以稱為后端服務。在傳統的操作系統中，這些服務可以通過網絡、UNIX套接字訪問，甚至可以是一個子進程。例子包括并不限于：
- 數據庫(MySQL，PostgreSQL)。
- 消息隊列(Kafka, RabbitMQ)。
- 文件存儲(NFS，FTP)。
- 日志服務。
- 緩存系統。
- SMTP服務。
你可以管理自己的后端服務，也可以讓云廠商代管。云廠商提供豐富的后端服務，你無需擁有該服務，而是可以直接消費。
云廠商操作大規模的資源，并承擔性能、安全和維護的責任。云原生系統傾向于云廠商提供的后端服務。在這方面，我們可以在時間和勞動力上節約很多。如果是自己托管，那么遇到的運行風險會比較麻煩。
最佳實踐是將后端服務視為附加資源，動態地與微服務綁定，而配置信息存儲在外部配置中。這一原則在上文的12因素中得到了闡述。
12因素中的因素4規定，后端服務應該通過一個URL暴露，這樣做可以使資源和應用脫鉤，使其可以互換。
因素3規定，配置信息應該被移出微服務，并通過代碼外的配置管理工具實現外部化。
后端服務也體現了12因素中"無狀態的服務進程"原則，把依賴的服務分離出去，一些應用服務已經可以實現"無狀態"了。
但有時候，還需要對應用內部做一些改造才能實現無狀態。無狀態是水平擴展的前提，對于Serverless應用更是必要條件。
6、自動化(Automation)
如你所見，云原生采用微服務以及容器化技術以實現它的速度和敏捷性。但是這還遠遠不夠，你如何配置這些系統所運行的云環境?如何快速部署應用程序的功能和更新?
我們先來了解下IaC(Infrastructure as Code,基礎設施即代碼)的概念。
基礎設施即代碼 (IaC) 指的是通過代碼而不是手動流程來管理和配置基礎設施。IaC 有時也稱為"可編程基礎設施"，可將基礎設施配置完全當作軟件編程來進行。
IaC 協助將基礎設施管理從數據中心內的物理硬件過渡到虛擬化、容器和云計算。對于 IaC、網絡、虛擬機、負載平衡器和連接拓撲都使用高級語言進行編碼，將應用開發所依靠的環境標準化。
完成編碼后，DevOps 能夠啟動、拆解和擴展基礎設施，以響應不斷波動的需求。這樣的敏捷性能夠造就更快、更簡單的軟件開發、測試和部署。
（1）基礎設施自動化(Infrastructure Automation)
我們可以使用特定的工具(比如Azure Bicep)來對所需要的云基礎設施進行聲明性的編寫。資源的名稱、位置、容量都是參數化和動態的。你編寫的腳本會受到版本控制。調用該腳本即可在不同的系統環境中配置一致的，重復性的基礎設施。
你可以重復運行同一個腳本而不產生副作用。如果團隊想更新資源，他們可以編輯并重新運行腳本。
在《什么是基礎設施即代碼》一文中，作者Sam Guckenheimer描述道：“實施IaC的團隊可以快速、大規模地交付穩定的環境。他們避免手動配置環境，并通過代碼來保證理想環境的一致性。采用IaC的基礎設施部署是可重復的，可以防止因配置漂移(Configuration Drift)或依賴性缺失而導致的運行問題。DevOps團隊可以使用一套統一的實踐和工具來快速、可靠和大規模地交付應用程序及其支持的基礎設施。”
（2）部署自動化(Deployment Automation)
前面的12因素中的因素5提到，每個版本必須在構建、發布和運行階段實行嚴格的分離。每個版本都應該被標記為唯一的ID，并支持回滾的能力。
為什么要強調"構建、發布、運行"三個階段一定要分離開來呢?
有兩個好處：
職責和關注點的分離。構建是開發測試人員更關注的、發布是產品經理更關注的、運行是運維更關注的;
流水線模式帶來的效率提升，以及各階段之間的緩沖空間，每個階段有專門的工具和方法論。
怎么做到這三個階段的分離呢?流水線的運行不是靠人力保障的，自動化系統很重要。
CI/CD系統有助于實現這一原則。它們提供獨立的構建和交付步驟，幫助確保一致的、高質量的代碼，并可隨時提供給用戶。
- 開發者在開發環境中開發了一個功能，通過代碼、運行和調試的"內循環"進行迭代。
- 完成后，這些代碼被推送到代碼庫中，如GitHub或BitBucket。
- 然后CI自動構建、測試和打包應用程序。
- 到了發布階段，CD系統將打好的包，外部應用和環境配置信息合成一個不可變的版本。該版本被部署到一個指定的環境中。每個版本都應該是可識別的。
- 最后，發布的功能在生產環境中運行。
使用這些技術，企業已經從根本上改變了他們發布軟件的方式。許多企業已經從每季度一次的發布轉變為按需更新。
以上就是云原生的六大關鍵因素了，下面讓我們來看看云原生在2022年的新趨勢。
3、云原生的趨勢
在過去幾年中，IT行業見證了云原生技術的指數級增長。當我們來到2022年，我們需要關注以下五個關鍵的云原生趨勢。
1、WebAssembly在云原生環境中的崛起
WebAssembly已經發展成為一個高性能、跨平臺、多語言的軟件沙盒環境，可用于云原生軟件的組件。鑒于容器運行時和WebAssembly(WASM)之間驚人的相似性，Kubernetes可用于協調WASM組件。
WasmCloud、WasmEdge、KubeEdge和Krustlet等項目使WASM成為云原生宇宙的一等公民。
將打包成WebAssembly的軟件與容器化軟件一起運行是極有可能的。Kubernetes可以無縫地協調這兩種組件。
2、云原生安全
隨著網絡安全越來越被重視，云原生安全在2022年也會受到更多的關注。
有兩個領域會獲得更多的關注——軟件供應鏈和eBPF(Extended Berkeley Packet Filter)
軟件供應鏈
軟件供應鏈類似于現實世界中的商業供應鏈。資源被消耗，然后通過一系列的步驟和過程進行轉化，最后提供給客戶。
現代的軟件開發是將公共領域中的各種組件作為開放源碼項目進行組裝和整合。在復雜的軟件供應鏈中，一個被破壞的軟件會對多個部署造成嚴重損害。所以務必要保證軟件供應鏈的安全性。
eBPF
另一個令人興奮的趨勢是eBPF，它使云原生開發人員能夠構建安全的網絡、服務網和可觀察性組件。
3、Kubevirt走向主流
Kubevirt是一個開源項目，它使得Kubernetes能夠像容器一樣協調虛擬機。
通過運行虛擬機和容器，我們可以輕松地將傳統的工作負載與基于微服務的應用程序整合起來。
2022年，我們將看到Kubevirt與Kubernetes的應用整合急劇上升。
4、GitOps成為持續部署的標準
GitOps為云原生工作負載的發布管理帶來了熟悉的基于Git的工作流程。通過將Git作為單一可信來源來控制狀態，加上快速回滾的能力，使GitOps成為一個強大的機制。
2022年，GitOps將發展到支持多租戶和多集群部署，使其能夠輕松管理數萬個Kubernetes集群。也許GitOps將成為持續部署的黃金標準。
5、混合云和多云的架構
混合云服務可以將各方的優勢結合在一起。需要快速和頻繁訪問的數據可以保存在公共服務器上，而更敏感的數據可以保存在有監控訪問的私人服務器上。一個良好的整合和平衡的混合云戰略給企業帶來了兩個世界的最佳效果。
而多云模式可以幫助企業選擇最適合其個人應用環境、業務要求和可用性需求的不同云產品。展望未來，更多的企業將需要開發完全云原生的應用程序，幾乎沒有架構上對任何特定云廠商的依賴。
盡管很多大型企業已經采用混合云和多云戰略作為標準，但2022年將見證更多企業認識到這些模式的優勢，并接受它們，以享受云的彈性和敏捷性。
