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

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

基礎設施的歷史經驗

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

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

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

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

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

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

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

(A "Microsoft Linux" USB stick）

轉向云端

今天，我們生活在一個 DevOps 和云端的世界里。我們收獲了開源運動帶來的創新成果。在公司內部采用開源軟件開發實踐的情況下， Tim O'reilly 所稱的 “內部開源” 有了明顯增長。我們為云平臺共享部署配置。像 Terraform 這樣的工具甚至允許我們編寫和分享我們如何部署特定的平臺。

但這些平臺本身呢?

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

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

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

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

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

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

基于私有云