基礎設施即代碼還是雲平台，你來定

讓我們比較一下兩種流行的雲基礎設施管理方法。

第一類是基礎設施即代碼（IaC），工程師使用程式設計/腳本語言建構一組腳本，以在雲平台上實作所需的拓撲結構。Terraform、Cloud Formation、Chef、Puppet和Ansible是其中受歡迎的産品。

這項技術包括一種編寫腳本的語言，以及一個可以運作腳本的控制器。一旦對結果感到滿意，使用者就會将腳本儲存在代碼存儲庫中。随後，如果要進行更改，則會對檔案進行編輯，并重複相同的過程。

第二類是雲編排器或平台。這通常是原生雲API上的精簡抽象，它将作為web服務與使用者互動，使用者連接配接到該服務（通過UI或API）并在該web服務本身中建構雲拓撲。

建構的拓撲将由編排器應用，并儲存在其自己的資料庫中。使用者不需要顯式儲存配置。當必須進行更新時，使用者将再次登入到系統并進行更改。

對于較小規模的用例，平台可能太重。但在大規模應用時，IaC方法往往會演變成一個内部平台。在這種情況下，更好的政策是使用現成的平台，當需要定制時，該平台可以通過IaC腳本進行增強。像Facebook和Netflix這樣的大型資料中心是另一回事，在此不考慮。

“長期運作的上下文”

基于平台的方法提供的基本價值是我們所說的“長期運作的上下文”。人們也可以稱之為“項目”或“租戶”。上下文可以映射到應用程式或環境，如示範、測試、産品或開發人員沙盒。當對拓撲進行更新時，使用者總是在這種上下文中進行操作。在将更新應用于雲之前，該平台将在此上下文中将更新儲存在自己的資料庫中。簡而言之：總是可以保證這個資料庫中存在的内容就是應用于雲的内容。

在IaC方法中，這樣的上下文不是原生提供的，而是留給使用者。通常，這會轉化為類似“需要為哪個上下文運作哪些腳本？”的内容，或者可能轉化為代碼庫中代表給定租戶或項目配置的檔案夾。将上下文定義為代碼集合比較困難，因為許多腳本可能在租戶之間是通用的。是以，最有可能歸結為開發人員對代碼庫的了解。

平台是解決這個問題的一種更具聲明性的方法，因為它隻需要很少或根本不需要編碼，因為系統将根據意圖生成代碼，而不需要了解低級實作細節。同時，在IaC的情況下，任何更改都需要對代碼庫有很好的了解，尤其是在大規模操作時。在平台方法中，使用者可以在幾天後傳回并登入到同一上下文，然後繼續之前停止的地方，而不必深入研究代碼來了解以前做了什麼。

代碼庫和應用到雲之間的差異

兩者之間的第二個根本差別是，IaC是一個多步驟的過程（編寫腳本、運作腳本并在存儲庫中合并），而平台是一個一步的過程（登入上下文并進行更改）。使用IaC，使用者可能會更新腳本，但也可能會忘記或推遲将其儲存在存儲庫中。與此同時，另一位工程師本可以為他們自己的拓撲對代碼庫進行更改并将其合并。現在，由于這兩個用例共享了許多代碼，第一位開發人員可能會發現自己陷入了沖突，即使通過合并代碼來解決，也會使他們陷入雲中運作的内容與存儲庫中的内容不同的境地。開發人員必須重新運作合并後的代碼進行驗證，盡管可能會導緻回歸。為了避免這種風險，需要在QA環境中測試腳本。

其他

IaC工具将支援部署，但運作雲軟體的基礎設施還有很多。需要一種應用程式供應機制，一種收集和隔離每個應用程式的日志和名額、監控運作狀況和發出警報、建立審計跟蹤以及管理使用者對基礎設施的通路的身份驗證系統的方法。有幾種工具可以解決這些單獨的問題，但它們需要縫合在一起并內建到應用程式上下文中。Kubernetes、Splunk、CloudWatch、Signalfx、Sentry、Elk和Oauth提供商都是這些工具的示例。但如果開發者想以合理的規模營運，需要一個連貫的“平台”來将所有這些結合在一起。

IaC的大部分基本上是一個本土的雲平台

在與許多工程師交談時，我們聽到這樣的觀點，即基礎設施即代碼與Go、Java和Python等正常程式設計語言的BASH腳本相結合，提供了克服上述挑戰所需的所有鈎子。有了這種代碼，可以建構任何東西。然而，可能正在建構與現有平台相同的平台。為什麼不從現有的平台開始，通過腳本添加自定義？

筆者聽到的第二個論點是，“基礎設施即代碼”更靈活，允許深度定制，而在平台中，可能需要等待供應商提供相同的支援。筆者認為，随着技術上的進步，平台比人們所認為的要先進得多，并且具有出色的機器生成技術，即使不是全部，也能滿足大多數用例。此外，一個好的平台不會阻止使用者通過腳本工具自定義超出其範圍的部分。一個設計良好的平台應該提供正确的鈎子來使用在平台之外編寫的腳本。是以，這個論點并不能證明為大多數标準任務建構代碼庫是合理的。

“沒有适合我們需求的平台”

這也是一個常見的論點。筆者同意：一個好的平台應該努力解決這個普遍存在的問題。DuploCloud平台，可以解決大多數用例，同時讓開發人員能夠內建系統外建立和管理的政策。

有一個有點令人驚訝的支援建構本土平台的論點是，對于工程師來說，這隻是一個非常酷的項目，尤其是如果這些工程師來自系統背景的話。筆者住在矽谷，在與該地區的客戶交談時發現了一個非常有趣的趨勢。

當與基礎設施工程師交談時，我們發現他們更強烈地希望在内部建構平台，而且他們非常清楚，他們正在為各自的組織建構一個“平台”，而不是他們認為的“腳本”。對于這些公司來說，定制是反對現成工具的常見論點，而混合雲和内部部署是重要的用例。Kubernetes、Consul等開源元件很常見，是以筆者經常聽到這樣的斷言，即輪子不需要重新發明。然而，團隊的規模和配置設定給解決方案的時間是巨大的。在某些情況下，對建構平台的關注掩蓋了公司應該銷售的核心業務産品。雖然不完全是科學的，但頗有一些公司這麼做。

與此同時，一些公司的工程人才正在建構純軟體即服務的應用程式。這些應用程式使用了太多的原生雲軟體——S3、Dynamo、亞馬遜簡單隊列服務（SQS）、亞馬遜簡單通知服務（SNS）——很難混合使用。他們很樂意通過API或UI将容器交給亞馬遜彈性容器服務（Amazon Elastic container Service，Amazon ECS）進行部署。他們對部署或學習Kubernetes并不感興趣。是以，内部定制的趨勢和深度要少得多。

多少次，多少人會編寫相同的代碼來實作相同的用途？上市時間最終決定了一切。