在十年前的典型組織中，開發和運營團隊具有獨立且截然不同的職責。開發人員負責編碼軟件程序，然后在完成后將其移交給運營團隊。IT 運營隨后在整個組織中部署了這些程序。
在上述環境中，開發和運營是相互隔離的。開發處于最前沿，運營處于最后。獨立的孤島意味著兩個團隊之間經常會出現脫節，問題可能會在開發接近尾聲時出現。這兩支球隊之間經常發生摩擦也就不足為奇了。當時的軟件部署并不像它應該的那樣容易。
十年后快進，由于 DevOps 文化在組織中的興起，開發和 IT 運營之間的墻已經倒塌，DevOps 是開發和運營的結合體，旨在簡化軟件部署。促成 DevOps 流行的是它對軟件即服務模型的適用性，該模型已成為近年來流行的軟件開發標準。
DevOps 的興起見證了對 DevOps 工程師或具備使 DevOps 取得成功所需技能的人員的需求增加。典型的 DevOps 工程師要么是已經過渡到獲得所需操作技能的開發人員，要么是已經獲得成功軟件部署所需的必要開發人員技能的操作員。
在本文中，我們介紹了 DevOps 的重要性及其對將軟件部署到云的影響。我們還討論了傳統超大規模提供商和裸機云的優缺點，這兩種競爭技術可滿足您的云需求。最后，我們解決了何時是從傳統超大規模環境轉移到裸機云環境的最佳時機的問題。
DevOps 的現狀
DevOps 代表開發和運營，旨在簡化開發生命周期并使其更能響應業務目標。因此，源源不斷的更新和改進是具有高度發展的 DevOps 文化的組織的主要特征。為了在不斷變化的環境中簡化部署，DevOps 鼓勵協作和重用，使團隊能夠在開發過程的早期發現潛在問題，更頻繁地部署，并減少解決問題的時間。
DevOps 的其他特征包括使用以下內容：
- 源代碼管理——集中的代碼存儲庫對于確保不同團隊在處理一個項目時不會出現沖突至關重要。
- 持續集成和持續交付 (CI/CD) – 通過單一源代碼存儲庫，簡化集成、開發和測試流程，加速移動中的軟件創建
- 配置管理——確保每次都自動和可靠地部署基礎設施
- 基礎設施管理——基礎設施即代碼意味著面對不斷增長的需求更容易編組資源
- 包管理——現代 DevOps 微服務需要允許無限擴展的容器
- 調度和編排——面對不斷變化的工作負載，最大限度地利用資源需要容器化的容錯應用程序
- 監控——需要持續監控，以確保應用程序和工具鏈不會在某個地方崩潰
現在對能夠輕松執行上述功能的工具的需求不斷增長。其中許多工具也是開源的。示例包括 GitLab、Jenkins、Travis、Ansible、Juju、Docker、Kubernetes 和 NetData。許多云提供商也有自己的一套專有工具來執行這些相同的功能。
DevOps 似乎值得成為近年來的流行語。一份關于 DevOps 狀況的 2018 年報告表明，在接受調查的組織總數中，約有 11% 的組織擁有高度發展的 DevOps 文化，這意味著他們大部分時間都遵循最佳 DevOps 實踐。幾乎 80% 的人介于高和低之間，這意味著他們有時會遵循一些最佳 DevOps 實踐。只有 10% 的人認為低，這意味著他們不會在日常工作中使用 DevOps 最佳實踐。根據這一趨勢，預計高度發展的 DevOps 組織的數量將在未來幾年達到頂峰。
DevOps 和傳統云
由于強調簡化開發管道，DevOps 方法似乎非常適合在云中實施，因為它非常適合傳統超大規模提供商提供的敏捷性和快速基礎設施配置。云計算基礎架構非常適合那些過渡到 DevOps 的人。通過云提供商手中的代碼配置，開發團隊可以專注于他們最擅長的事情——編碼和測試他們需要添加到系統中的功能。當需要部署時，他們只是簡單地通過其提供商提供的可用工具自動執行該過程。
但是，使用傳統云進行 DevOps 有一些注意事項。當您的組織變得更大并且越來越多的人開始定期使用您的系統時，您可能會發現您的成本急劇上升，無法控制。這是因為更多的點擊次數意味著更高的價格。如果您一開始發現云提供商的低進入門檻很誘人，那么一旦您開始為不斷增長的用戶群支付更高的費用，這可能就不再是真的了。
此外，如果您不小心，您可能會依賴于使用您的云提供商的專有工具。在某些情況下，您可能需要預先付費以更新工程師的技能并培訓他們使用這些工具。當時間到了，您需要遷移到其他供應商時，這將成為一個真正的負擔。您不僅需要重新構建您的云堆棧，還需要使用一套新的云工具培訓您的工程師。
此外，云提供商在他們的計算基礎架構中添加了一個虛擬化層，并且經常超額預訂硬件資源，以便能夠處理更多的客戶端。分配給多個客戶端使用的資源可能意味著您所占的服務器份額可能無法勝任處理用戶工作負載的任務，從而危及系統的效率和有效性。如果您有付費客戶，這可能會毀了您的聲譽，因此您必須保留額外的計算資源緩沖區，這會增加您的總開支。
最后，安全漏洞可能會影響您的系統，尤其是當與您共享服務器資源的其他組織沒有像您一樣致力于使他們的系統安全時。如果您的“吵鬧鄰居”與安全性差的虛擬機與您自己的物理硬件駐留在同一物理硬件上，那么數據泄露和惡意軟件感染等都是一個非常現實的問題。如果這些相鄰的機器以某種方式受到網絡攻擊，您的機器將陷入交火。
什么是裸機云？
鑒于與傳統云相關的問題，一旦您的新興業務發展成熟，就必須尋找替代方案。裸機云就是這樣一種選擇。如果您現在只想過渡到云，您還應該記住這個選項。
裸機云服務器取消了傳統云中普遍存在的虛擬化層。您自己的 DevOps 人員對服務器擁有完全的根訪問控制權。通過不受限制地訪問服務器，就好像您擁有一個可以完全使用的本地服務器，這與傳統超大規模中的僅管理程序訪問不同。也沒有與其他組織共享資源。相反，您可以完全控制硬件。您可以在需要時配置、克隆、升級、降級或遷移服務器。
同時，在裸機云中仍然可以實現快速配置和按小時計費的便利性。因此，如果您發現您的服務器沒有達到標準，您可以快速配置更多資源來擴展您的系統。
裸機云也不會將您束縛于專有技術。相反，您可以在您自己的裸機云服務器上使用您的員工已經熟悉的開源 DevOps 工具。無需培訓任何其他內容，而且所需的技能可以在您的團隊中轉移。DevOps 工程師可以通過API將您選擇的開源云原生堆棧與裸機云無縫集成。
裸機云何時成為可行的 DevOps 選項？
裸機云在以下情況下特別可行：
- 當您不缺乏具有所需技能的 DevOps 人才并希望有選擇時。雖然傳統的超大規模云提供商，如 AWS、Azure 和谷歌，抽象出一些服務管理的麻煩，但裸機云的優勢在于它讓您完全自由地選擇和利用您選擇的云原生軟件堆棧。雖然這需要額外的人力來處理軟件管理和維護任務，但您可以完全自由地創建與供應商無關的 IT 基礎架構。
- 當您的技術堆棧已經基于開源并且您希望進行快速無縫遷移時。如果您的工程師已經在使用Ansible?、Docker 和 Kubernetes等開源 DevOps 工具方面經驗豐富，那么您的組織會發現向裸機云的過渡比大多數人都容易。
- 當您從一開始就預計需要增加計算資源時。裸機云服務器通常具有很高的計算能力，您在啟動時可能不一定需要。另一方面，如果您希望在項目的早期階段有高端工作負載，裸機服務器將為您提供更高的每美元計算能力。由于超大規模供應商傾向于鎖定他們的客戶，因此值得考慮在業務的早期階段投資裸機云從長遠來看是否具有值得的投資回報。
- 當您需要擁有完全專用和完全自動化的基礎架構時。單租戶基礎設施在超大規模提供商中非常有限，而且通常包含大量成本。雖然超大規模供應商在虛擬機上提供單租戶基礎設施，但裸機云沒有虛擬化層。這允許超大規模提供商在一分鐘內啟動新服務器，而裸機云計算機通常在 10 分鐘內部署完畢。然而，對于那些需要完全專用基礎架構的人來說，沒有虛擬化開銷和硬件級別控制通常更為重要。
結論
DevOps 從 2009 年這個術語被創造出來時開始得到廣泛使用。在隨后的幾年中，許多組織已經采用 DevOps 來改進他們的系統開發流程。未來幾年，具有高度發展的 DevOps 文化的組織數量預計會增加更多。
在 DevOps 成為流行語的同時，傳統云因其便利性和低進入門檻而吸引了越來越多的組織使用。由于強調快速周轉時間，DevOps 似乎是為傳統超大規模提供商所特有的快速配置量身定制的。
然而，傳統的云確實有它的問題。一方面，它因缺乏隱私和安全性而受到批評，因為您與其他組織共享相同的硬件，而這些組織可能不像您那樣癡迷于安全最佳實踐。可靠性是另一個潛在問題，因為位于傳統云之上的虛擬機及其資源在您的組織和同一計算基礎設施上的其他組織之間進行了劃分。如果性能不佳，您將被迫以更高的成本獲得更多的資源。
此外，您可能會受限于使用傳統超大規模提供商提供的專有軟件。你不希望這種情況發生，因為有大量開源工具可用于處理 DevOps 任務。從長遠來看，依附于專有技術可能會讓您付出高昂的代價。
獲得裸機云服務器可以避免與傳統云相關的問題。可靠性不會成為問題，因為您的組織不會與任何其他組織共享服務器資源。同樣，您的隱私和安全問題也會得到處理。由于您的員工可以自由使用裸機云服務器作為他們自己的服務器，他們還可以使用他們認為合適的任何 DevOps 工具。最重要的是，裸機云保留了傳統云的主要優勢：快速配置和按小時計費。
總而言之，選擇使用傳統云還是裸機云歸結為您的 DevOps 工程師是否可以管理您自己的云計算基礎設施的問題。如果您的員工具備所需的 DevOps 技能，您可能會發現 Bare Metal Cloud 是兩者中更好的選擇。
