基于 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;我們創建了一個掌控基礎部分的系統，我們現在可以專注于更有趣的、可以給我們雇主帶來更高價值的工程作業。

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

[[202275]]
A "Microsoft Linux" USB stick

轉向云端

今天，我們生活在一個 DevOps 和云端的世界里。我們收獲了開源運動帶來的創新成果。在公司內部采用開源軟件開發實踐的情況下， Tim O'reilly 所稱的 “內部開源” 有了明顯增長。我們為云平臺共享部署配置。像 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 而已，不會立即被鎖定在特定云的工具或平臺上?？梢愿鶕唧w情況來決定是否使用特定的專屬后端，但如果你這樣做，就應該著眼于未來。

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

做一個登月計劃

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

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