在上一篇文章中，我們講到了DevOps和持續傳遞的關系。本篇将回顧最先改變運維工作的相關技術 —— 基礎設施即代碼和雲計算，通過技術雷達上相關條目的變動來跟蹤其趨勢變化。
和持續傳遞一樣，基礎設施即代碼（Infrastructure as code）這項技術第一次在技術雷達出現就被納入到了“采納”環。
（2012年10月期技術雷達，blip28: Infrastructure as code, Adopt）
十年前，雲計算的普及程度遠不如當今。很多企業開始采用虛拟化技術（嚴格的說，那時候還不能稱作是雲）來解決資源不足和裝置異構的問題。簡單的說，你可以接虛拟化技術是在異構的裝置上建構了一個通用适配層。使得各種不同的應用程式和裝置能夠通過通用的操作進行統一的管理，那時候面臨這樣問題多是通信、銀行、政府、石油等關鍵領域。即便 IBM，Oracle，EMC 微軟等都有“整體解決方案”，但為了避免供應商綁定風險，政府還是希望能夠“混搭”：通過做大蛋糕來降低風險。當然，這種做法也降低了效率。然而當虛拟化技術解決了異構問題之後，基礎設施資源被抽象為網絡、計算、存儲三類資源。由于業務的異構性，企業級領域遲遲沒有解決方案。畢竟為了讓虛拟化的資源能夠盡快産出價值，往虛拟資源的遷移工作相關的內建工作占據了工作主要内容。
于是運維工程師和網絡工程師慢慢遠離機房，和系統工程師以及資料庫工程師坐在了一起，共同成為了“腳本工程師”。
此時，Linux開始通過Xen和KVM侵蝕傳統 UNIX 廠商的市場佔有率。SCO，AIX 和 HP-UX這些過去按賣 License 獲得售後服務的方式畢竟太貴了。可以說，借由 Linux 虛拟化技術的雲計算技術給商業 UNIX 來了一記補刀，如今你很少能看到這些商業 UNIX 了。
虛拟化技術把所有的空閑資源收集到了一起，這些資源完全可以在不增加基礎設施裝置投入的情況下運作更多的應用程式。拟化技術還可以通過整合小型裝置，得到和大型裝置一樣的表現。
但是，如果你通過虛拟化節約出來的空閑資源你使用不了，但是還要收取電費，這就是很大的浪費。于是有些人則想到了把這些空閑的資源租出去，變成一個單獨的業務。這就是另外一個故事了，我們稍後會提到。随着 VMware，Oracle，Cisco，IBM 推出了各自的解決方案，“腳本工程師”們開始考慮如何管理大量的空閑資源。随着靈活軟體開發逐漸成為主流，基礎設施的變更效率顯然滿足不了靈活的疊代速度。基礎設施的變更帶來的風險和周期遠遠大于應用。如何讓基礎設施靈活起來，成為了靈活軟體開發在傳遞最後一公裡需要迫切解決的問題。
這時候，由于規模和複雜度都很大，腳本工程師們考慮的第一個問題就是：如果規模沒辦法改變，我們就降低複雜度吧。
Puppet 的短暫輝煌
Puppet 是第一個嗅到這個商機的工具，它在第2010年8月的技術雷達上出現在了“試驗”環裡。
（2010年8月期技術雷達，blip29: Puppet, Trial）
Ruby 很适合建構領域特定語言（DSL），繼 Cucumber 在這方面的成功探索後，腳本工程師們希望通過 DSL 縮小 Dev 和 Ops 之間的差距。作為同一時期的競争者，Chef 以對開發人員更加友好的方式出現。Chef 相比 Puppet 更有競争力的一點就是對于 Windows 的支援。
不過，由于缺乏最佳實踐，Puppet 和 Chef 很快就被玩壞了，複雜性的治理難度超過預期。随着治理規模的擴大，Puppet 和 Chef 帶來的負面效應逐漸顯現。曾經有人這樣諷刺 Puppet：
Puppet 就像蟑螂。當你剛開始用了 Puppet，慢慢的你會發現你的代碼庫裡到處都是 Puppet。
此外，事實證明 Ruby 是一個便于開發，但是難于維護的語言。Ruby 及其社群的頻繁釋出和不相容特性使得後期接手維護的腳本工程師們叫苦不疊，加之 Ruby 工程師的招聘成本和教育訓練成本都更高。即便 Ruby 的 Puppet 和 Chef 工具學習曲線比較平緩，但遺留的基礎設施即代碼的學習曲線卻非常陡峭。基礎設施的變更風險很大，且缺乏必要的品質實踐，特别是主從模式的中心化還帶來了單點故障和複雜度，這些都使得基礎設施代碼越來越難以維護。
在靈活團隊中，去中心化、自治的團隊往往是被提倡的。于是 Puppet 推出了 standalone 模式，Chef 出現了 chef-solo 這樣去中心化的特性。技術雷達很快就出現了與之相對的Librarian-puppet and Librarian-Chef 和 Masterless Chef/Puppet這樣去中心化的實踐。
于是，大家把聚光燈從Ruby轉向了Python。從中心化轉向了去中心化。然而，當“無狀态伺服器” 出現在2012年10月的技術雷達的“采納”區域時，新的基礎設施即代碼管理思想也應運而生。
從菜單（Cookbook）到劇本（Playbook）—— Ansible
在 Puppet 和 Chef 的最佳實踐并沒有創造出新的市場佔有率，而是給它們創造了一個新對手——Ansible。Ansible 在 2014 年 1 月首次出現在了技術雷達的 “試驗” 區域，短短半年後就在 2014年 7月的技術雷達中出現在了 “采納” 區域。
（更多詳情可至ThoughtWorks官網檢視）
Ansible采用了Python+Yaml這種Python社群常見的組合。用Yaml作為Playbook的格式來存儲虛拟機的配置。通過把虛拟機抽象成狀态機，在Playbook中版本化儲存狀态的方式使得基礎設施即代碼的“狀态”和“狀态變更”的分離更加徹底，大大減少了代碼量和程式設計量。甚至坊間有人笑稱Ansible把運維工程師從腳本工程師變成了配置管理工程師，基礎設施即代碼變成了基礎設施即配置。
面向雲計算的基礎設施即代碼
基礎設施即代碼的技術最早不是為雲計算設計的。但随着雲計算的廣泛應用，腳本工程師對于“看不見的機房”的管理就隻剩下程式設計了。然而，面向于傳統機房和 IaaS 的基礎設施即代碼技術在PaaS 盛行的今天卻有點捉襟見肘，雲平台自己的 CLI 工具是為管理者設計的，而不是為開發者設計的。此外，盡管 Puppet，Chef 和 Ansible 各自都增添了對雲計算更友好的功能，但本質上是面向虛拟機而非雲計算平台設計的。對雲計算平台的操作仍然需要通過建構一個 Agent 的方式處理。
這些訴求推動了面向雲平台的技術設施即代碼工具的出現。最先為大衆所熟知的就是 Terraform。
“Hashi 出品，必屬精品”，HashiCrop 就像 DevOps 界的暴雪娛樂。在雲計算和 DevOps 的領域裡，HashiCrop的每一款産品都進入了技術雷達，并引領了接下來幾年 DevOps 技術的發展。
在虛拟化技術剛剛成熟的時候，HashiCrop 就推出了 Vagrant。Vagrant于2011年1月出現在技術雷達的 “評估” 區域，2012年進入了 “試驗” 區域。
随之在技術雷達上就出現了對開發工作站的基礎設施自動化的實踐。随着Packer在2014年6月進入技術雷達“采納”區域的同時，鏡像建構流水線也出現在了技術雷達上。
Vagrant 和 Packer 這樣的組合深深影響了 Docker，這個我們後面再說。我們還是回過頭來說說 Terraform。2015 年，Terraform 出現在了技術雷達的 “評估” 區域上。技術雷達是這麼描述的：
使用 terraform, 可以通過編寫聲明性定義來管理雲基礎架構。由 terraform 執行個體化的伺服器的配置通常留給 Puppet, Chef 或 Ansible 等工具。我們喜歡 terraform, 因為它的檔案的文法可讀性比較高, 它支援多個雲提供商, 同時不試圖在這些提供商之間提供人為的抽象。在這個階段, terraform 是新的, 并不是所有的東西都得到了實施。我們還發現它的狀态管理是脆弱的, 往往需要尴尬的體力工作來解決。
雖然 Terraform 有一些問題，但瑕不掩瑜。HashiCrop 改進了 Terraform。一年之後，在 2016 年 11 月的技術雷達中，Terraform 進入了 “試驗” 區域。這些改進也被技術雷達敏銳的捕捉到：
在我們近兩年前首次更謹慎地提到 terraform 之後, 它得到了持續的發展, 并已發展成為一個穩定的産品, 已經證明了它在我們項目中的價值。現在, 通過使用 terraform 所說的 "遠端狀态後端", 可以回避狀态檔案管理的問題。
為了避免重蹈 Puppet 和 Chef 被玩壞的覆轍，Terraform 總結了最佳實踐并釋出了 Terraform: Up and Running 一書。随之推出了與之對應的工具Terragrunt，Terragrunt 于 2018 年 11 月出現在了技術雷達，它包含了之前介紹過的“基礎設施流水線”的思想。
（2018年11月期技術雷達，blip72: Terragrunt, Assess）
基礎設施即代碼的自動化測試
可測試性和自動化測試永遠是技術雷達不可缺少的話題，基礎設施即代碼也是一樣。在提出基礎設施的可測試性訴求後，Provisioning Testing應運而生，它的目的在于對伺服器初始化正确性的驗證，被納入到了 2014 年 1 月技術雷達的 “試驗” 區域。Puppet 和 Chef 分别有了 rspec-puppet 和 kitchen 作為各自的測試架構來支援這種實踐。
但當基礎設施即代碼采用不止一種工具的時候，采用各自的測試套件就比較困難了。是以，尋找與基礎設施即代碼無關的測試工具就非常必要，畢竟Chef，Puppet和Ansible都隻是一種實作方式，而不是結果。
采用 Ruby 編寫的 Serverspec 出現在了 2016 年 11 月技術雷達的 “試驗” 區域。半年後，采用 Python 寫的Testinfra也出現在了 2017 年 6 月技術雷達的 “試驗” 區域。它們都可以通過工具無關的描述方式來驗證基礎設施的正确性。
有了自動化測試工具，我們就可以采用 TDD 的方式開發基礎設施。先用代碼來描述伺服器的規格，然後通過本地或遠端的方式進行驗證。此外，這樣的自動化測試可以被當做一種監控，內建在流水線中定時運作。
下面是基礎設施即代碼相關條目的發展曆程一覽圖。實線為同一條目變動，虛線為相關不同條目變動：
相關條目：Puppet，Librarian-puppet and Librarian-Chef，Masterless Chef/Puppet，Provisioning Testing，Testinfra，Serverspec，Terraform，Terragrunt。
揭開雲計算的大幕
咱們接着說“有人想把虛拟化後的空閑資源變成一個獨立的業務”這件事。彼時，網格計算和雲計算的口水戰愈演愈烈，大家似乎沒有看出來IDC（Internet Data Center）機房裡托管虛拟機和雲計算之間太多的差别，雲計算聽起來隻是一個營銷上的噱頭。
2010 年第一期的技術雷達上，雲計算就處在了 “采納” 區域，技術雷達是這麼描述雲計算的：
Google Cloud Platform Amazon EC2 和 salesforce. com 都聲稱自己是雲提供商, 但他們的每個産品都有所不同。雲适用于服務産品的廣泛分類, 分為基礎架構即服務 (例如 Amazon EC2 和 Rackspace)、平台即服務 (如Google App Engine) 和軟體即服務 (如 salesforce. com)。在某些情況下, 提供商可能跨越多個服務類别, 進一步稀釋雲作為标簽。無論如何, 雲中基礎設施、平台和軟體的價值是毋庸置疑的, 盡管許多産品在路上遇到了坎坷, 但他們肯定已經赢得了自己在雷達上的地位。
那時的 IaaS、PaaS 和 SaaS 都可以被稱之為雲計算，隻不過每個供應商的能力不同。而它們的共同點都是通過 API 提供服務。
到了2010年4月的第二期技術雷達，技術雷達則把 SaaS 看作是雲計算的最進階成熟度。而 IaaS 和 PaaS 是不同階段的成熟度。并把原先的雲計算拆分成了三個條目：EC2&S3 （來自 AWS），Google Cloud Platform，Azure。并且分别放在 “試驗”、“評估”、“暫緩” 象限。也就是說，在 2010年，ThoughtWorks 一定會用 AWS，有些情況下會考慮 GCP，基本不會考慮使用 Azure。
而公有雲計算供應商的三國演義就此展開。
AWS 一馬當先
多年以來 AWS 上的服務一直引領者雲計算的發展，成為衆多雲計算供應商的效仿對象，也成為了多數企業雲計算供應商的首選。雖然 AWS 正式出現在技術雷達是在 2011 年 7 月，然而 EC2 & S3 的組合在第二期就出現在技術雷達的 “試驗” 區域了。在 Docker 出現的第二年，AWS 就出現了托管的彈性容器服務 ECS (Elastic Container Service)，也是第一家在雲計算平台上內建 Docker 的供應商。為了解決大量不同品牌移動裝置測試的問題推出了 AWS Device Farm，使得可以通過線上的方式模拟數千種移動裝置。在微服務架構流行的年代，不光推出了第二代容器基礎設施 AWS Fargate 和 7層負載均衡 Application LoadBalancer。更是先聲奪人，率先提供了基于 Lambda 的函數即服務（Function As A Service）無伺服器（Serverless）計算架構，使得開發和部署應用變得更加靈活、穩定和高效。
然而，随着成熟的雲平台的選擇增多。AWS 不再是預設的選擇，在2018 年 11 月的技術雷達中， AWS 從 “采納” 落到了第 “試驗” 區域。但這并不是說明 AWS 不行了，而是其它的公有雲供應商的技術能力在不斷追趕中提升了。這就意味從 2018 年開始， AWS 并不一定是最佳選擇。Google Cloud Platform 和 Azure 可能會根據場景不同，成為不同場景的首選。
GCP 緊随其後
開發人員最不想面對的就是基礎設施的細節。它們希望應用程式經過簡單的配置可以直接在網際網路上運作。而無需關注網絡、作業系統、虛拟機等實作細節——這些細節對開發者應該是透明的。
Google App Engine 最早就以雲計算的概念出現在技術雷達上的 “評估” 象限，存在了兩期後便消失不見。在那個時代，人們對于無法控制基礎設施細節的雲計算平台還是心存懷疑。更重要的是，按照新的程式設計模型修改現有應用架構的成本遠遠大于基于 IaaS 平台的平行移動成本。前者需要重構整個應用，後者幾乎可以無縫對接。
然而，新時代的容器技術和 SaaS 應用讓 Google 笑到了最後。基于 Kubernetes 的容器編排技術幾乎成為了行業标準。Google Cloud Platform 适時推出了自己的 Kubernetes 平台服務GKE - Google Kubernetes Engine，使得 Google Cloud Platform 重回技術雷達的視野，在 2017 年 11 月的技術雷達，Google Cloud Platform 進入了 “嘗試” 象限。技術雷達是這麼描述的：
随着GOOGLE CLOUD PLATFORM(GCP)在可用地理區域和服務成熟度方面的擴充，全球的客戶在規劃雲技術政策時可以認真考慮這個平台了。與其主要競争對手Amazon Web Services相比，在某些領域， GCP 所具備的功能已經能與之相媲美。而在其他領域又不失特色——尤其是在可通路的機器學習平台、資料工程工具和可行的 “Kubernetes 即服務解決方案”(GKE)這些方面。在實踐中，我們的團隊對GCP工具和API良好的開發者體驗也贊賞有嘉。
即便AWS也推出了對應的Kubernetes服務EKS (Amazon Elastic Container Service for Kubernetes，别問我為什麼不是ECSK，官方網站上就這麼寫的)，但也無法撼動其領先位置。随着更多的企業已經接受容器化技術，并通過 Kubernetes 在私有雲中進行編排以實作 DevOps。通過 GKE 實作雲遷移成本降低了很多。
Azure 後來居上
Azure 在 2010 年的第二期技術雷達被放到了"暫緩"區域。意思就是在考慮雲計算平台的時候，就不要考慮用 Azure 了。盡管如此，Azure并沒有因為被邊緣化就逡巡不前。經過了 7 年， Azure 伴随着一系列激動人心的新産品重回人們的視野。然而，從 2017 年底開始，Azure 的服務開始進入技術雷達的 “評估” 區域。首先進入技術雷達的是 Azure Service Fabric：
AZURE SERVICE FABRIC是為微服務和容器打造的分布式系統平台。它不僅可以與諸如Kubernetes之類的容器編排工具相媲美，還可以支援老式的服務。它的使用方式花樣繁多，既可以支援用指定程式設計語言編寫的簡單服務，也可以支援 Docker 容器，還可以支援基于 SDK 開發的各種服務。自幾年之前釋出以來，它不斷增加更多功能，包括提供對Linux 容器的支援。盡管 Kubernetes 已成為容器編排工具的主角，但 Service Fabric 可以作為 .NET 應用程式的首選。
而後到了 2018 年，Azure 的後發優勢不斷在技術雷達中湧現出來，除了 Azure 進入了 “試驗” 以外，就是 Azure Stack 和 Azure DevOps 兩個産品了。技術雷達在 2018 年 5月是這麼描述 Azure Stack 的：
通過 AZURE STACK，微軟在全功能的公有雲和簡單的本地虛拟化之間提供了一個有意思的産品:一個運作Microsoft Azure Global雲的精簡版本軟體。該軟體可以安裝在諸如惠普和聯想這樣的預配置通用商品硬體上，進而讓企業在本地獲得核心的 Azure 體驗。預設情況下，Microsoft 和硬體供應商所提供的技術支援是彼此分離的(他們承諾要互相合作)，但系統內建商也能提供完整的 Azure Stack 解決方案。
在我看來，Azure Stack就是雲時代的Windows。相較于以前硬體廠商受制于Windows的各種裝置而言，未來的虛拟裝置廠商也會受制于Azure Stack。這時候Azure Stack不單單是一套私有雲了，它更是未來硬體廠商的管道。雖然在私有雲領域中有很多的選擇，但在使用體驗上，微軟的産品正在超過其它競争者。
另外一個強烈推薦的服務就是Azure DevOps。DevOps運動發展以來，不斷有公司在開發 DevOps 平台這樣的産品，希望能夠通過産品鞏固自己在 DevOps 領域的話語權。也有很多做 DevOps 的企業通過內建不同的工具來建構自己的 DevOps 平台。目的是将計算資源和開發流程采用工具整合起來，形成一套由工具建構的工作流程和制度。并采用逆康威定律——用系統結構反向改變組織結構，進而達到 DevOps 技術和管理的雙轉型。
但很少有産品能夠跨越足夠長的流程來做到管理，這也導緻了 DevOps 平台由于範圍的限制引起的不充分的轉型。而Azure DevOps 提供了完整的産品端到端解決方案，Azure DevOps 的前身是微軟 VSTS，也有基于企業的 TFS 産品可供選擇。它涵蓋了産品管理，任務看闆，持續傳遞流水線等服務，這些服務也同時可以和 Azure 其它服務有機結合。并且可以和 Visual Studio 完美內建。真正解決從需求編寫到上線釋出中間每一個活動的管理。你還可以建構儀表盤，用各個活動中的資料來自動化度量 DevOps 的效果。
私有雲——從 IaaS，PaaS 到 CaaS
公有雲和私有雲似乎是在兩個世界。很久以來，私有雲算不算"雲"也存在争議。甚至有人把私有雲稱之為"企業虛拟化 2.0"。但直到多個公有雲上的實踐和工具同時能夠相容企業的私有虛拟化平台，私有雲的概念才真正建立起來。這就是為什麼私有雲在技術雷達上出現的時間要比 OpenStack 這樣的虛拟化工具更晚。OpenStack 在 2010 年第二期技術雷達就出現了，而私有雲要到 2 年後，也就是 2012 年，才出現在技術雷達上。
OpenStack是由NASA（美國國家航空航天局）和Rackspace合作研發并發起的，以Apache許可證授權的自由軟體和開放源代碼項目。OpenStack是一個開源的雲計算管理平台項目，由幾個主要的元件組合起來完成具體工作。OpenStack支援幾乎所有類型的雲環境，項目目标是提供實施簡單、可大規模擴充、豐富、标準統一的雲計算管理平台。OpenStack通過各種互補的服務提供了基礎設施即服務（IaaS）的解決方案，每個服務提供API以進行內建。
雖然 OpenStack 出現在技術雷達上比較早，但直到2013年5月，也就是 3年後，才進入到 “試驗” 區域。即便有很多企業用于生産環境，技術雷達的編寫者仍然很慎重的選擇這樣的開源産品。畢竟，可能造成的影響越大，就越要小心。
在衆多大型廠商的私有雲和虛拟化平台中，OpenStack 因為其開源的免費，并且有 NASA 和 Rackspace 做背書。成為了很多企業建構私有雲的首選。然而，建構一套基于 OpenStack 的 IaaS 基礎設施到真正能夠幫助開發人員提升效率是需要花費很大成本的。随着 OpenStack 的影響力不斷擴大，使用者需要的技術支援服務也慢慢成為了一個新興的市場。甚至于有企業将基于 OpenStack 開發自己的私有雲産品以提供對外服務。
然而，彼時的 OpenStack 在開發者體驗上并沒有什麼優勢。不過由于 OpenStack 是基于 Python 開發的，OpenStack 的流行可以說是促進了 Python 的大規模推廣。( Python 的第二次大規模推廣是大資料和人工智能，如果想問的話。)這使得一批基于 DevOps 理念的 PaaS 平台崛起，最先為人所知首當其沖的就是 Pivotal 的 CloudFoundry。由于 Pivotal 是一個商業組織，他更關心客戶的痛點，為此建構了很多解決方案。甚至将 CloudFoundry 自身部署在 OpenStack 上，使得 OpenStack 看起來不是那麼的難用。
自2012年我們上次提及 CloudFoundry 以來, PaaS 空間發生了許多變化。雖然開源核心有各種分布, 但作為 Pivotal Cloud Foundry公司組裝的産品和生态系統給我們留下了深刻的印象。雖然我們期望非結構化方法 (Docker、Mesos、Kubernetes 等) 與 Cloud Foundry 和其他公司提供的結構更結構化、更固執己見的建構包樣式之間繼續保持趨同, 但我們認為, 對于願意這樣做的組織來說, 我們看到了真正的好處。接受采用 PaaS 的限制和演化速度。特别令人感興趣的是開發團隊和平台操作之間互動的簡化和标準化所帶來的開發速度。
不過，正在 IaaS 和 PaaS 正在讨論誰更适合做 SaaS 平台的時候。Docker 的出現成為了雲計算市場和 DevOps 領域的另一個标志性事件。使得無論是公有雲産品還是私有雲産品，IaaS 産品還是 PaaS 産品。都不約而同的開始了對 Docker 的支援。并且有人認為 Docker 會是雲計算的下一個裡程碑和戰場。正如上文介紹的那樣，AWS 推出了 ECS，Google 推出了 GKS，Azure 也推出了自己的容器服務。同時也有不少的創業公司提出了 "容器即服務"(Container as a Service)的概念，企圖從雲計算市場上分得一杯羹。關于 Docker 和容器平台，我們會放在下一篇詳細講。
混合雲（HybirdCloud）
和私有雲同時出現在了 2012 年 4 月的技術雷達上，但是是在 “評估” 區域。彼時，混合雲隻是為了在資源不足時對私有雲進行臨時擴充：
混合雲描述了一組結合公共雲和私有資料中心的最佳功能的模式。它們允許應用程式在正常時段在私有資料中心運作, 然後在公有雲中使用租用的空間, 以便在交通高峰期實作溢出容量。以靈活的方式組合公共雲和私有雲的另一種方法是使用公共雲的彈性和可塑性來開發和了解應用程式的生産特征, 然後将其移動到私有資料中的永久基礎結構中中心時, 它是穩定的。
在體會了公有雲"真香"之後，大多數企業都回不去了。然而，種種限制還是阻礙了企業從私有雲向公有雲遷移的進度。不過，這種情況下促生了混合雲的生意。不光公有雲供應商提供了自己的服務，很多創業公司也加入進來。于是技術雷達在半年後更新了混合雲：
混合雲結合了公有雲和私有資料中心的最佳功能。它們允許應用程式在正常時段在私人資料中心運作, 然後在公共雲中使用租用的空間, 以便在交通高峰期實作溢出容量。現在有許多基礎架構解決方案允許跨混合雲 (如 Palette 和 Rrightscale) 進行自動和一緻的部署。借助來自亞馬遜、Rackspace 和其他公司的強大産品, 我們正在将混合雲轉移到此版本的雷達上的 "“嘗試”" 區域。
從另外一個角度說，公有雲的技術發展速度和成本是遠高于私有雲的。這也是集中化投資的優勢，減少研發和協調上的浪費。當企業開始結合公有雲和私有雲之後，就會慢慢發現公有雲帶來的成本和技術優勢。私有雲和資料中心就會被公有雲逐漸取代。
多雲（PolyCloud）共用時代
多雲不同于混合雲，混合雲指的是私有雲和公有雲之間的混合使用。多雲指的是不同的公有雲供應商之間的混合使用。在三大公有雲供應商共同相聚在 2018 年 11 月的 “試驗” 之前。多雲的趨勢就在 1 年之前進入了技術雷達的 “評估” 區域：
主要的雲提供商 (亞馬遜、微軟和谷歌) 陷入了一場激烈的競争, 以保持核心功能的平價, 而他們的産品隻受到輕微的區分。這導緻少數組織采用 Polycloud 戰略, 而不是與一個提供商 "All-in", 而是以最佳的方式将不同類型的工作負載傳遞給不同的提供商。例如, 這可能涉及将标準服務放在 AWS 上, 但使用 Google 進行機器學習, 将 Azure 用于使用 SQLServer 的. net 應用程式, 或者可能使用 Ethereum 聯盟區塊鍊解決方案。這不同于以供應商之間的可移植性為目标的雲無關政策, 這種政策成本高昂, 并迫使人們采取最小公約數思維。而多雲則專注于使用每個雲提供的最佳産品。
然而，短短半年，多雲就進入了 “試驗” 區域。與其說技術雷達推薦，倒不如說是兩方面大勢所趨：一方面，企業在采用混合雲之後會想要跟多的雲服務。另一方面，公有雲供應商之間的産品同質性迫使它們要發揮自己的特色。此外，如果其中一個雲供應商出了問題，我們還有其它的供應商可用。這就引發了一個新問題：企業不想自己被供應商綁定。于是就有了 "泛化雲用法"（Generic cloud usage，我自己的翻譯）這樣不推薦的實踐。它和多雲一起出現在了 2017年的技術雷達和 “暫緩” 區域:
主要雲提供商繼續以快速的速度向其雲添加新功能, 在 Polycloud 的旗幟下, 我們建議并行使用多個雲, 以便根據每個提供商的産品優勢混合和比對服務。我們越來越多地看到組織準備使用多個雲--不過, 不是從個别供應商的優勢中獲益, 而是不惜一切代價避免供應商 "鎖定"。當然, 這導緻了泛化雲用法, 隻使用所有提供商都有的功能, 這讓我們想起了10年前我們看到的最低公分母場景, 當時公司努力避免了關系資料庫中的許多進階功能以保持供應商中立。鎖定的問題是真實存在的。但是, 我們建議不要使用大錘方法來處理此問題, 而是從退出成本的角度看待此問題, 并将這些問題與使用特定于雲的功能的好處相關聯。
然而，這種警告确實在早期很難引起注意。因為大規模的"通用雲用法"導緻的不良後果不會來的那麼快。
主要的雲提供商在定價和釋出新功能的快速速度方面的競争力越來越強。這使得消費者在選擇并承諾向提供者承諾時處于困難境地。越來越多的人看到, 我們看到組織準備使用 "任何雲", 并不惜一切代價避免供應商鎖定。當然, 這會導緻泛化雲用法。我們看到組織将其對雲的使用限制在所有雲提供商中共有的功能, 進而忽略了提供商的獨特優勢。我們看到組織對自制的抽象層進行了大量投資, 這些抽象層過于複雜, 無法建構, 維護成本也太高, 無法保持雲不可知論。鎖定的問題是真實存在的。我們建議使用多雲政策來解決此問題, 該政策根據使用特定于雲的功能的好處, 評估從一個雲到另一個雲的遷移成本和功能的工作量。我們建議通過将應用程式作為廣泛采用的 Docker 容器運輸來提高工作負載的可移植性: 使用開源安全和身份協定輕松遷移工作負載的辨別, 這是一種與風險相稱的供應商政策, 以隻有在必要的時候才能保持雲的獨立性, Polycloud 才能在有意義的情況下混合和比對來自不同提供商的服務。簡而言之, 請将您的方法從通用雲使用轉向明智的多雲戰略。
下面是雲計算相關條目的發展曆程一覽圖。實線為同一條目變動，虛線為相關不同條目變動：
當大規模的基礎設施能夠通過開發的方式管理起來以後。似乎運維工程師也變成了一類開發者——基礎設施開發者。而和一般應用程式開發者的差別就是面向的領域和使用的工具不同。而基礎設施即代碼技術和雲計算的結合使用可以大大降低基礎設施的複雜度。于是我們就可以駕馭更加複雜的應用程式了，特别是微服務。請期待下一篇：從技術雷達看DevOps十年——容器和微服務。