基礎架構和應用部署的發展歷程
關於 「The Developer is the New Kingmaker 」 這本書出版已有近五年，但這句話仍然具有重要意義。您很難反駁這一觀點，因為我們已經看到一些工具和系統興起並在某些情況下佔據了絕對主導地位，這些工具和系統能夠讓開發人員如虎添翼，實現前所未有的工作效率。
今天我們來捋一捋基礎架構和應用部署的發展歷史。
01
消除Bps瓶頸
亞馬遜的公有雲是此成敗決定論的一個典型示例。它可提供相當簡單的API用於執行非常強大的任務，使開發人員或系統管理員只需進行幾次API調用即可請求複雜的基礎架構並且在幾分鐘內便可開始使用。
Google、Microsoft 和數十家規模較小的提供商如法炮製地構建了自己的API驅動式公有雲。與此同時，Rackspace與NASA合作創立了OpenStack項目，我們看到私有雲在各種現有企業供應商中取得了不同程度的成果。雲驅動和API驅動的基礎架構日益普及，即使未投入使用，也肯定是企業夢寐以求的目標。
基礎架構從交付管道中的最大瓶頸變為進展最快的部分。排隊等待、操作系統自定義以及應用部署和配置則成為了新的主要瓶頸。
02
開發結合運維
幸運的是，運維人員一直在關注這些問題。早在2008年，人們就意識到需要開始將敏捷軟體開發實踐應用到運維領域。DevOps應運而生。幾乎在同一時間，John Allspaw 和 Paul Hammond 在 Velocity Conference 期間透露了當時 Flickr 每天進行10多次部署。
敏捷基礎架構需要實現工具化，以便部署和管理基礎架構本身及其上運行的應用。這種需求催生了 Chef 和Puppet 這樣的配置管理工具。很快，Ansible和Saltstack等編排工具也應運而生，再後來是最近的Hashicorp Vagrant和Terraform等工具。
在此期間，第一批「雲原生」工作負載出現了。由於消除了運行自己的基礎架構帶來的高成本和低效率，他們能夠藉助敏捷開發技術專註於快速開發軟體和創新。Netflix等其他公司得以在雲中構建全新服務，這樣一來，他們就能自由進行創新，通過郵寄方式配送DVD轉變為將內容流式傳輸到您的屏幕，讓您可以直接觀看80年代懷舊影片和真實犯罪影片等。
經驗豐富的雲基礎架構提供商意識到為開發人員提供更簡便的應用運行方式可以帶來巨大優勢。於是這些提供商開始構建工具，用於代替開發人員自動運行應用，他們甚至無需了解或關注底層基礎架構。Microsoft和Google早期的雲產品專註於應用，但可能有點過於超前。這些雲產品並未得到廣泛採用，兩家公司都像亞馬遜一樣採用了IaaS模型。
03
12要素的到來
一些規模較小的初創公司開始真正了解現代開發工作流程，並開始構建讓部署應用與將代碼推送至GitHub一樣簡單的平台，GitHub是一項集中式Git服務，已成為運行和共享軟體的首選平台。
Heroku、Pivotal Cloud Foundry (PCF)、dotCloud和Engine Yard 迅速成為部署和運行專為雲設計的應用的首選平台。dotCloud 和 Engine Yard 是規模較小的利基型企業，而 Heroku 和 Pivotal Cloud Foundry 都成為了大規模服務，通過他們的各個公有平台即服務在兩者之間運行數以萬計的應用。
為了告訴人們如何編寫專門在雲上運行的應用，Heroku發布了一篇標題為「12要素應用」 的宣言，其中列出了使得應用適合在平台上運行的12種要素。該宣言迅速成為數千名崇拜他的開發人員的啟示錄。很久之後，人們創造了「雲原生」一詞來描述這些精心設計的全新應用。
現在一切達到了平衡，因為我們已經實現全面抽象化，可滿足各級開發人員和運維人員的需求（現在我們或許應該稱他們為「全體系開發人員」和「DevOps工程師」）。雲提供商不斷創新，改進各自平台的工具化和自動化，從而提供更好的網路連接、安全和存儲解決方案。
時至今日，面對直接展示了雲帶來的效率和成本節約的數千個非常規項目，大型企業的首席技術官和首席信息官無法再視而不見。企業IT猝不及防，不得不迅速根據其企業架構制定「雲戰略」。
04
Docker——容器變革的開端
Netflix和其他雲原生公司蓬勃發展，而且企業也開始在採用雲方面取得進展。2013年初，dotCloud的 Solomon Hykes 介紹了一個名為Docker的內部項目，他相信 Docker 將是 dotCloud PaaS 的未來。
Docker是一款易於使用的封裝器，可取代笨拙且難以使用的現有Linux容器工具。Docker提供了一種名為Dockerfile 的簡單構建格式和一個超簡單的用戶界面，從而解決了舊有問題。因此，我們將此看作容器變革的開端。
不到一年，Docker顯然已成為一種有力的催化劑，極大地改進了構建、配置和部署應用的方式。以Docker為中心的大型社區迅速形成，而且早在初期階段就有人報告說自己正在生產環境中運行Docker。
2014年，Docker使用自己的運行時libcontainer（用Go編寫）替換了LXC。該技術不斷完善，開始引起大家的關注。Cloud Foundry等現有平台（PaaS）看到了Docker 運行時的價值並增加了對其的支持，而Dokku和DEIS等新平台則直接從Docker社區內部構建而成。
Docker社區信奉12要素宣言，並且在哪些人應該在容器內部運行哪些內容這個問題上相當激進。但現在，這種態度已經有所緩和，因為Docker引入了新的功能和工具來處理有狀態應用，而且該社區還將工具結合使用，更輕鬆地運行非雲原生應用和容器內的資料庫。
05
Kubernetes GIFEE
與此同時，Google 多年來一直結合使用 Linux 容器和他們內部的群集管理器「Omega」，甚至擁有自己的DevOps 替代品，Site Reliability Engineering（站點可靠性工程，縮寫為SRE）。由Google工程師 Joe Beda、Brendan Burns 和 Craig McLuckie組成的小團隊開始研究一款使用 Docker 作為執行引擎的類似於Borg的平台，該平台於2014年以「Kubernetes」為名正式推出並實現開源，並隨 HBase 和 Zookeeper 等工具一起快速加入了Google Infrastructure For Everyone Else (GIFEE)。
Kubernetes是一種分散式系統，可提供「Google scale」的平台，從而跨主機群實現容器的自動化部署、擴展和運維。此外，通過提供容器生命周期管理，此系統還可以與您的基礎架構交互，以便為容器提供網路連接、存儲和負載均衡。換言之，在對應用進行調配和持續浮動管理方面，可實現完全自動化，消除了對大多數手動 ops-fu 的需求。
Google並不是唯一一家構建容器群集管理平台的企業。Docker 發布了 Docker Swarm，Hashicorp 的 Nomad 和Mesos 等項目也可提供類似的體驗。但在此階段，Kubernetes 似乎佔據了大部分市場。
自初始版本起，Kubernetes 便已內置大量您期望成熟工作負載調度器能夠提供的功能，而且現在它可以跨其控制平面、ReplicaSet 和 StatefulSet（在單元之上構建的資源，有助於提供可靠的方法來擴展單元並在重啟後保留原有狀態和數據）以及IngressControllers（可嚮應用提供第7層路由和負載均衡）提供高可用性。為了解決配置和保密（密碼、密鑰等）問題，Kubernetes 還提供了名為 ConfigMap 和 Secret 的強大功能。
該社區的其他成員提供了軟體包管理器（DEIS的Helm）、服務網格（Lyft/Google/IBM的Istio）、服務目錄（Pivotal的開放服務代理API）以及Operator (CoreOS)。雖然這些功能仍處於初始階段，但它們提供了更加輕鬆地在 Kubernetes 內部運行大多數應用的方法，無論是不是「雲原生」應用都適用。
隨著所有這些新工具和功能的引入，Kubernetes 已準備好成為運行應用的領先平台。但是，Kubernetes 尚未取代IaaS，也沒有取代PaaS，而是可能成為現有的和新的PaaS系統的默認容器調度器和運行時。
06
未來這塊大蛋糕如何切？
在接下來的兩年內，我們將停留在三個層次的基礎架構抽象 - IaaS、Kubernetes和PaaS。
從業者可從中選擇最滿足自身需求的基礎架構：
IaaS將是運維人員的領域，雲提供商將繼續提供虛擬機和存儲等基本的基礎架構服務，以及資料庫等更高級別的服務。那些仍認為需要運行自己的基礎架構的人可以使用 VMWare或OpenStack，也可以直接在裸機上運行Kubernetes。[群集]運維人員將繼續使用其現有的工具（例如Terraform和Chef）來運行自己的私有雲/Kubernetes組合以及現有的傳統基礎架構和應用。
Kubernetes 將是 DevOps 從業者、SRE 和高級開發人員的主要目標。藉助StatefulSet和Operators等工具，我們能夠在 Kubernetes 中運行更多支持服務，例如 Cassandra（ 將作為開放代理API託管的服務目錄的一部分）等資料庫。這一層的工作人員將直接使用Kubernetes manifest或Helm Chart開展工作。高級從業者會採用 CI/CD 實踐進行實際部署。
PaaS 層將與Kubernetes 同時（或在其上）運行，為開發人員提供一種簡單的方法來運行他們的應用。開發人員可以直接與PaaS交互，但很可能是由CI工具（如Jenkins）執行實際的應用部署。從某種程度上講，開發人員不會與PaaS直接交互，更不用說IaaS或Kubernetes了。
儘管Kubernetes和其他類似平台還很年輕，但許多公司已經在使用這些層的技術。Netflix 自產的平台Spinnaker最初旨在將應用部署到亞馬遜平台，但也支持Kubernetes 和 Pivotal Cloud Foundry。Yelp也擁有自己的平台Paasta，該平台是基於Mesos構建的。
更多公司正處於這一發展道路的某一階段，且已通過採用Pivotal Cloud Foundry之類的平台提高了其開發實踐的效率，並期望使用 Kubernetes 為其運維實踐帶來類似的效率。
但是，大多數企業仍處於雲和DevOps旅程的初期，面對公司內部需要進行的大量轉型工作（不僅僅是技術和工具化轉型，還有從組織和文化角度進行的轉型），他們可能正不知所措。
支持雲原生方法的技術體系終於結束了漫長的發展旅程。從2008年到現在，我們實現了飛躍性的發展。我們看到各種大型企業都採用了這些技術並改進了他們開發軟體的方式。技術不再是問題。看起來，現在您面臨的有趣的新挑戰是確定如何重新設計企業架構和重新編排員工。但這是另外一回事了。
TAG:Pivotal |