為什麼開源應該是雲原生環境的首選

基於 Linux 擊敗了專有軟體一樣的原因，開源應該成為雲原生環境的首選。

讓我們回溯到上世紀 90 年代，當時專有軟體大行其道，而開源才剛開始進入它自己的時代。是什麼導致了這種轉變？更重要的是，而今天我們轉到雲原生環境時，我們能從中學到什麼?

基礎設施的歷史經驗

我將以一個高度武斷的、開源的視角開始，來看看基礎設施過去 30 年的歷史。在上世紀 90 年代，Linux 只是大多數組織視野中一個微不足道的小光點而已——如果他們聽說過它的話。你早早購入股票的那些公司們很快就發現了 Linux 的好處，它主要是作為專有的 Unix 的廉價替代品，而部署伺服器的標準方式是使用專有的 Unix，或者日漸增多的使用 Microsoft Windows NT。

這種模式的專有本性為更專有的軟體提供了一個肥沃的生態系統。軟體被裝在盒子裡面放在商店出售。甚至開源軟體也參與了這種裝盒遊戲；你可以在貨架上買到 Linux，而不是用你的互聯網連接免費下載。去商店和從你的軟體供應商那裡只是你得到軟體的不同方式而已。

Ubuntu 包裝盒出現在百思買的貨架上

我認為，隨著 LAMP 系列（Linux、Apache、MySQL 和 PHP / Perl / Python）的崛起，情況發生了變化。LAMP 系列非常成功。它是穩定的、可伸縮的和相對用戶友好的。與此同時，我開始看到對專有解決方案的不滿。一旦客戶在 LAMP 系列中嘗過了開源的甜頭，他們就會改變他們對軟體的期望，包括：

• 不願被供應商綁架，
• 關注安全，
• 希望自己來修復 bug ，以及
• 孤立開發的軟體意味著創新被扼殺。

在技術方面，我們也看到了各種組織在如何使用軟體上的巨大變化。忽然有一天，網站的宕機變成不可接受的了。這就對擴展性和自動化有了更多的依賴。特別是在過去的十年里，我們看到了基礎設施從傳統的「寵物」模式到「群牛」模式的轉變，在這種模式中，伺服器可以被換下和替換，而不是一直運行和被指定。公司使用大量的數據，更注重數據留存和數據到用戶的處理和返回速度。

開源和開源社區，以及來自大公司的日益增多的投入，為我們改變如何使用軟體提供了基礎。系統管理員的崗位要求開始 要求 Linux 技能和對開源技術和理念的熟悉。通過開源類似 Chef cookbooks 和 Puppet 模塊這樣東西，管理員可以分享他們的模式配置。我們不再單獨配置和調優 MySQL；我們創建了一個掌控基礎部分的系統，我們現在可以專註於更有趣的、可以給我們僱主帶來更高價值的工程作業。

開源現在無處不在，圍繞它的模式也無處不在。曾經仇視這個想法的公司不僅通過協同項目與外界擁抱開源，而且進一步地，還發布了他們自己的開源軟體項目並且圍繞它們構建了社區。

A "Microsoft Linux" USB stick

轉向雲端

今天，我們生活在一個 DevOps 和雲端的世界裡。我們收穫了開源運動帶來的創新成果。在公司內部採用開源軟體開發實踐的情況下， Tim Oreilly 所稱的 「內部開源」 有了明顯增長。我們為雲平台共享部署配置。像 Terraform 這樣的工具甚至允許我們編寫和分享我們如何部署特定的平台。

但這些平台本身呢？

「大多數人想都不想就使用了雲……許多用戶將錢投入到根本不屬於他們的基礎設施中，而對放棄他們的數據和信息毫無顧慮。" —Edward Snowden, OpenStack Summit, May 9, 2017

現在是時候要更多地想想本能地轉移或擴展到雲上的事情了。

就像 Snowden 強調的那樣，現在我們正面臨著對我們的用戶和客戶的數據的失控風險。拋開安全不談，如果我們回顧一下我們轉向開源的原因，箇中原因還包括被廠商綁架的擔憂、創新難以推動、甚至修復 bug 的考慮。

在把你自己和/或你的公司鎖定在一個專有平台之前，考慮以下問題：

• 我使用的服務是遵循開放標準，還是被廠商綁架的？
• 如果服務供應商破產或被競爭對手收購，什麼是我可以依賴的？
• 關於停機、安全等問題，供應商與其客戶溝通中是否有一個明確而真誠的歷史過往？
• 供應商是否響應 bug 和特性請求，即使那是來自小客戶？
• 供應商是否會在我不知情的情況下使用我們的數據（或者更糟，即便我們的客戶協議所不同意）？
• 供應商是否有一個計劃來處理長期的，不斷上升的增長成本，特別是如果最初的成本很低呢？

您可以通過這個問卷，討論每個要點，而仍然決定使用專有的解決方案。這很好，很多公司一直都在這麼做。然而，如果你像我一樣，寧願找到一個更開放的解決方案而仍然受益於雲，你確實有的選擇。

基於私有雲

當您尋找私有雲解決方案時，您的首選是開源，投資一個雲提供商，其核心運行在開源軟體上。 OpenStack 是行業領袖，在其 7 年的歷史中，有 100 多個參與組織和成千上萬的貢獻者（包括我）。 OpenStack 項目已經證明，結合多個基於 OpenStack 雲不僅是可行的，而且相對簡單。雲公司之間的 API 是相似的，所以您不必局限於特定的 OpenStack 供應商。作為一個開放源碼項目，您仍然可以影響該基礎設施的特性、bug 請求和發展方向。

第二種選擇是繼續在基礎層面上使用私有雲，但在一個開源容器編排系統中。無論您選擇 DC/OS（基於Apache Mesos) 、Kubernetes 或 Docker Swarm 模式 ，這些平台都允許您將私有雲系統提供的虛擬機作為獨立的 Linux 機器，並在此之上安裝您的平台。您所需要的只是 Linux 而已，不會立即被鎖定在特定雲的工具或平台上。可以根據具體情況來決定是否使用特定的專屬後端，但如果你這樣做，就應該著眼於未來。

有了這兩種選擇，你也可以選擇完全離開雲服務商。您可以部署自己的 OpenStack 雲，或者將容器平台內部架構移動到您自己的數據中心。

做一個登月計劃

最後，我想談一談開源項目基礎設施。今年 3 月，在召開的 南加州 Linux 展會 上，多個開放源碼項目的參與者討論了為他們的項目運行開源基礎設施。（更多的，請閱讀我的 關於該會議的總結）我認為這些項目正在做的這個工作是基礎設施開源的最後一步。除了我們現在正在做的基本分享之外，我相信公司和組織們可以在不放棄與競爭對手相區分的「獨門秘方」的情況下，進一步充分利用他們的基礎設施開源。

開源了他們的基礎設施的開源項目，已經證明了允許多個公司和組織向他們的基礎設施提交訓練有素的 bug 報告，甚至是補丁和特定論文的價值。突然之間，你可以邀請兼職的貢獻者。你的客戶可以通過了解你的基礎設施，「深入引擎蓋子之下」，從而獲得信心。

想要更多的證據嗎？訪問 開源基礎設施 的網站了解開源基礎設施的項目（以及他們已經發布的大量基礎設施）。

可以在 8 月 26 日在費城舉辦的 FOSSCON 大會上 Elizabeth K. Joseph 的演講「基礎架構開源」上了解更多。

（題圖：Jason Baker. CC BY-SA 4.0. Source: Cloud, Globe. Both CC0.）

via: https://opensource.com/article/17/8/open-sourcing-infrastructure

作者：Elizabeth K. Joseph 譯者：wenzhiyi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出