云計算如今改變了企業(yè)構建和運行應用程序的方式。人們需要探索發(fā)生這種情況的原因，并了解采用云計算的企業(yè)對其發(fā)展的期望。

十年前，當亞馬遜公司首次推出其云計算平臺時，在全球技術領域掀起了一場重大變革浪潮，并使IT市場走上了如今已經(jīng)價值1000億美元行業(yè)市場的軌道。

云計算服務已經(jīng)發(fā)展成一個多元化的市場，專注于提供不同類型的虛擬基礎設施、開發(fā)平臺和托管應用程序。VMware公司在多年前就在x86服務器上普及了虛擬機（VM），而按需租用容量的能力成為一項技術和業(yè)務創(chuàng)新。

在這幾年中，很多云計算服務提供商發(fā)布了大量云計算服務，這些服務遠遠超出了定義早期云計算產(chǎn)品的計算、存儲和網(wǎng)絡服務，遠遠超出了應用程序堆棧。僅AWS公司在全球各地的幾十個數(shù)據(jù)中心就提供了將近200種產(chǎn)品，而且這些數(shù)字將會不斷增長。

隨著AWS公司的業(yè)務發(fā)展，它變得更加復雜，甚至影響了架構決策。首先，它影響了計劃云計算部署的基礎設施工程師，后來改變了開發(fā)人員設計應用程序的方式。

與個人電腦和x86服務器的興起引起了一波客戶端服務器企業(yè)應用程序的應用浪潮類似，對云計算的興趣激發(fā)了基于瀏覽器的應用程序的新開發(fā)語言和框架。在過去的十年中，各個領域的開發(fā)人員都基于云服務、容器和自動化工具創(chuàng)建了新的設計模式、開發(fā)平臺和工作流。

集中和分散的周期概述了云計算的每一代應用程序開發(fā)的定義產(chǎn)品。但是，隨著開發(fā)人員適應不同類型的基礎設施和部署范例，他們同時遵循了另一種形式的架構演變。這開始集中于軟件設計，逐步將應用程序分解成更小的組件。

大型機的成本和操作復雜性促進了整體設計，將應用程序代碼打包并作為一個單元運行。分布式客戶端-服務器系統(tǒng)和基于瀏覽器的用戶界面的興起促使應用程序首次分離為模塊化的n層架構，從而將功能劃分為多個元素。

各種各樣的云計算服務（尤其是容器運行時環(huán)境、無服務器功能、托管數(shù)據(jù)庫和分析服務）的可用性加速了更加精細化的趨勢。對云計算起源和意義的回顧表明，云計算是邏輯抽象各個級別上許多服務的組合。這些各種服務以及容器已經(jīng)產(chǎn)生了云原生的概念，這是應用程序架構的下一個發(fā)展。

云原生構建塊

盡管云計算服務已在許多方面影響了開發(fā)和部署實踐，以下的重點是云計算演進的下一階段也就是開發(fā)云原生應用程序。

云原生目前還沒有一個標準的定義，這是專家們不斷爭論的話題。但是，將云原生應用程序描述為在云平臺上開發(fā)的應用程序。最終，云原生應用程序旨在機會性地利用所有可用的云計算服務，以盡可能低的成本實現(xiàn)性能、可擴展性、可靠性、安全性、適應性和可管理性的最大化。

在這種概念下，云計算服務就像一盒樂高積木，每個積木都具有一組定義的功能和標準接口（通常是API），用于功能控制和數(shù)據(jù)I/O，這些功能和標準接口組合在一起以構建應用程序。像樂高積木一樣，可以將一組零件組合成為一個模型或模板，這些模型或模板可以快速復制或重用為功能模塊。經(jīng)過十多年的發(fā)展，云計算服務現(xiàn)在提供了數(shù)量驚人的各種構建塊。

云原生設計需要將這些組件拼接在一起以構建自定義應用程序。精通云計算的設計師更喜歡更高的抽象級別，以很大程度地減少工作量，這使企業(yè)可以更加專注于應用程序的差異化特性。

云原生應用程序開發(fā)與軟件開發(fā)、集成、測試和部署過程緊密相關。它們通常在DevOps組織下統(tǒng)一，或者通過不太正式地采用DevOps原則和方法。

但是不要將兩者混為一談。無需使用DevOps即可進行云原生開發(fā)。并非所有DevOps組織都針對云計算優(yōu)先的應用程序。但是，DevOps流程可以增強云原生開發(fā)。同樣，DevOps流程從可編程的云計算開發(fā)服務中受益匪淺，這些服務將可重復的流程實現(xiàn)系統(tǒng)化和自動化。

例如，與不使用標準化、可重復、自動化流程的組織相比，具有高級DevOps流程和文化的組織往往具有更短的應用程序部署周期（通常每天多次）。

云原生權衡

盡管云計算為應用程序開發(fā)帶來了很多好處，但并非沒有缺點。云原生設計的最大風險是使用高級服務時的供應商鎖定。盡管包裝在API中的云計算服務使用戶與底層實現(xiàn)隔離開來，但API本身的非標準性質(zhì)使在云計算提供商之間遷移應用程序變得困難。

此外，還出現(xiàn)了避免鎖定的工具。值得注意的是，Kubernetes已成為容器管理和容器化應用程序的事實上的標準。確實，避免鎖定通常是許多系統(tǒng)架構師選擇使用基于容器的實施而不是使用云原生服務的主要原因。

數(shù)據(jù)引力也就是將大量數(shù)據(jù)從一個運營環(huán)境移動到另一個運營環(huán)境的困難和費用，是云原生設計的另一個缺點。IT部門通常通過使用混合環(huán)境來減輕這些擔憂。在這種情況下，主數(shù)據(jù)庫和文件存儲庫保留在私有基礎設施上，而云計算基礎設施則包含副本或緩存的數(shù)據(jù)子集。

趨勢與預測

近年來，云計算服務提供商的收入增長顯著。這在很大程度上是由于企業(yè)采用率的增加，而云計算的發(fā)展看起來不會很快停止。事實表明，發(fā)生的冠狀病毒疫情只是加快了這一趨勢的發(fā)展。

很多企業(yè)面臨著巨大的資金壓力，需要降低成本，提高效率。他們開始意識到其IT部門無法與云計算提供商的規(guī)模經(jīng)濟、運營效率和大量研發(fā)工作相匹配，而這些都推動了新服務的不斷涌現(xiàn)。

許多新加入云計算的公司將把現(xiàn)有的應用程序遷移到虛擬基礎設施上，云平臺將成為他們所有新應用程序的運營環(huán)境。那些利用云計算提供商提供一切資源的公司，其中包括更高級別的服務和開發(fā)平臺，將具有競爭優(yōu)勢。這將更加強調(diào)云原生開發(fā)的價值。

人們還可以期望許多企業(yè)向提供商施加壓力，要求他們在不依賴云計算的抽象模型、描述語言和部署工具上進行協(xié)作，以簡化云原生應用程序在環(huán)境之間的遷移。開放應用程序模型（OAM）是一個很有前途的步驟，最初主要關注基于容器的微服務和Kubernetes環(huán)境。

目前尚不清楚開放應用程序模型（OAM）社區(qū)是否急于將這一模型擴展到更高級別的云計算產(chǎn)品，例如無服務器功能、分布式數(shù)據(jù)分析、區(qū)塊鏈或人工智能和機器學習。不過，云計算供應商在這方面的努力可能會帶來更大的應用程序的遷移性。
責編AJX