2009 年，我發現了谷歌 App Engine，并很快愛上了這一服務。這一服務承諾，任何軟件開發者都能開發面向任何用戶，在任何時間、任何地點都可以使用的應用，同時不必擔心服務器配置、數據庫設置、操作系統版本、信息安全漏洞、負載平衡，或是規模如何擴大的問題。這意味著，應用將可以自動擴大規模！我們所要做的只是撰寫代碼，而 App Engine 將為我們完成其余一切工作。

[[131911]]

在 2009 年時我就已經看到，到 2015 年，很大一部分互聯網代碼將運行在類似的平臺上。誰會想要糾結配置和運營問題？系統管理員將可以從復雜的工作中被解放出來。最終，我們將可以自由編寫代碼，而不必擔心如何去執行，以及通過什么平臺去執行。我們不必再關注規模，并可以從復雜的運營工作中被解放出來。我們的未來一片光明，不必再關注如何配置等細節。

然而，事情與我們想象中并不完全一樣。

為什么會這樣？

目前的現實并不是“一次開發，在任何地方運行”。AppEngine 仍在履行，并將繼續履行最初的承諾。（這是我仍在業余項目中使用 App Engine 的原因。）然而在這一過程中，你會遇到種種問題，例如難以解釋的內存泄漏，或是漫長的等待時間。正如一名來自谷歌的朋友所說：“App Engine 非常有趣。該服務面向所有用戶的運行速度都是同樣的緩慢，而無論用戶有多少。”

市面上還有許多其他平臺即服務（PaaS）提供商。例如，云計算市場領先者亞馬遜也提供了 PaaS 產品，即 Elastic Beanstalk。我也曾頻繁使用 Heroku，但這款產品同樣非常糟糕。在處理異步任務和自動負載平衡等方面，Heroku 不如 App Engine，不過在部署和 PostgreSQL 數據庫等方面要好。然而，Heroku 并未提供廣泛的應用程序接口（API）。通過谷歌，你實際上能獲得比其他地方更好的 API。這就是你通過谷歌平臺去運行代碼的優勢和劣勢。

不過目前，谷歌自身也不像 2009 年時一樣重視這一領域。2012 年時，由于對 App Engine 狀況的不滿，谷歌推出谷歌 Compute Engine，即亞馬遜 AWS 服務的直接競爭對手。毫無疑問，相對于采購設備并搭建自己的服務，利用這樣的服務將更方便。不過，從易用性、靈活性和部署時間來看，這些服務相對于 PaaS 服務似乎是一種倒退。那么，為何 PaaS 服務未能征服所有市場？

PaaS 服務取得過成功。例如，Snapchat就運行在 App Engine 之上，可汗學院也是如此。Genius和ProductHunt則基于 Heroku。這兩大平臺也為其他許多創業公司和大公司提供了服務。不過，如果 PaaS 能取得更大的成功，那么谷歌原本沒有必要推出 Compute Engine，Docker 就不會成為新的熱點，而 DevOps 也不會像現在一樣知名。

那么，為何仍有許多人放棄 PaaS，轉而開發自己的 AWS 和 Compute Engine 實例？為何 App Engine、Heroku 和 Elastic Beanstalk 未能征服世界？良好的控制性是否真的很重要？

我猜測，原因包括 3 個方面：成本、對開發者的鎖定，以及文化。

App Engine 的價格會經常性下調，但這樣的調價過于頻繁，令人迷惑。單一的實例，即一個簡單的虛擬機，成本要超過每天 1 美元，這還不計算存儲或帶寬成本。Heroku的情況也是類似。通過購買及運行自己的服務器，你能獲得更好的性價比。盡管這時你會遇到更多的麻煩，導致開發時間被延長，但轉而使用 PaaS 帶來的好處對許多人來說并沒有足夠的價值。

隨后是被鎖定的問題。一旦你在 App Engine 的訂制 API 之上開發了應用，你將需要專注于這一平臺。你沒有一種較好的方式回退，并轉而使用另一家公司的平臺。這種對開發者的鎖定在其他 PaaS 服務中并不是很明顯，但仍然存在。基礎設施即服務（IaaS）領域有著OpenStack和Docker等通用標準，而 PaaS 領域沒有這樣的事實標準。

第三個原因，也是被認為最重要的一點原因在于文化。企業并不希望放棄對自主系統的控制，即使這樣的控制權將導致很嚴重的復雜性。可以理解，系統管理員不希望丟掉自己的工作。

不過，這 3 點原因都是暫時性的。成本正在持續下降，文化在不斷改變。有跡象表明，可互操作的 PaaS 服務和相應標準正在緩慢發展。（你可以認為，Docker 就是這一趨勢下的產物。）

在電力剛剛出現的時代，所有工廠都使用自己的發電機，但隨后都轉向了公共的電網。IaaS 相當于所有公司都從電網中獲得電力，但隨后通過自主的變壓器將電力轉換為自己所需的形式。我認為，PaaS 服務仍將繼續發展。在這樣的世界里，在代碼運行過程中，開發者不必了解或關注服務器的問題。這樣的趨勢只是比我想象中略微緩慢。