悉數四代PaaS發展，一文理順基礎設施、平臺和工做流之間的關係

Datawire團隊最近的一次交流，是關於「PaaS」這一術語的真正含義，以及它與開發人員體驗(DevEx)和工做流之間的關係，帶來了許多能夠分享的內部對話。從和客戶一塊兒工做，到會議上與人的聊天中，我感受到，其餘團隊對於部署應用程序時「平臺」和工做流之間的關係也有些不肯定，我但願以建設性的方式，能提供一些清晰的認知，或者至少可以學到一些東西。

基礎設施、平臺、工做流三者缺一不可
Daniel Bryant是一名獨立的技術顧問，專一於經過價值流識別、管道的建立和有效的測試策略實施，來實現組織內的持續交付。Daniel的技術專長在於DevOps工具、雲/容器平臺和微服務實現。他還參與了幾個開源項目，爲InfoQ、O 'Reilly和Voxxed撰稿，並按期出席OSCON、QCon和JavaOne等國際會議。

從基本原則開始提及，全部基於web的軟件開發都涉及到三層：

基礎設施：這一層提供原始計算資源的抽象，如裸金屬、vm、操做系統、網絡、存儲等，這些資源最終將負責處理與應用程序相關的代碼和數據。這裏避免使用「物理」這個術語，由於儘管全部的東西最終都是在硬件上運行的，可是咱們愈來愈多地看到基礎設施的抽象轉移到軟件定義的全部東西(Software-Defined-Everything，SDx)。

平臺：這一層提供了粗粒度的系統級構建塊，它多是運行時特定的，好比一個集成的JVM或CLR的計算實例，還有數據存儲、中間件、IAM、審計等等。值得一提的是，相信你老是將應用程序部署到某種形式的平臺上，即便沒有有意識地組裝它。

工做流：這一層是如何設計、構建、測試、部署、運營應用程序的總和。每一個開發人員都有一個工做流(即便它是隱性的)，從我的的獨立網站構建者，到一個在複雜的企業系統中工做的數千人團隊。

當我和朋友和客戶談論這個模型時，我一般會就概念和結構達成某種形式的協議。當開始討論這些概念之間的耦合時，特別是與PaaS有關時，分歧就開始了。

這些是你正在尋找的平臺
我常常聽到「PaaS有一個內置的工做流程」，或者「若是你正在運行一個PaaS，那麼你不須要知道基礎設施。」我並不特別贊成這些說法，而且在努力創建共同的理解。PaaS經歷了幾代模式的發展：

第一代：Heroku和它的朋友們。這種類型的PaaS隱藏了底層雲基礎設施（經過可部署的slugs和「Dynos」），並提出了很是有見地的工做流程，與平臺耦合。對於簡單的單體Ruby應用程序，這很是棒，能夠在幾分鐘內熟練部署工做流程，而且全部知識均可以轉移到下一個項目複用。

第二代：Cloud Foundry（DEA版）和它的朋友們。這種類型的PaaS能夠部署在企業的基礎設施上，而且帶來企業本身的buildpacks和運行時。工做流仍然集成在一塊兒，可是該平臺開始經過上下文路徑路由（context path routing ）等概念啓用多服務應用程序（和工做流程）。

第三代：Cloud Foundry（Diego版）以及當前版本的Google App Engine和AWS Elastic Beanstalk（二者分別從第一代和第二代PaaS演變而來）。這些PaaS對基礎架構的依賴更低，企業能夠攜帶本身的容器，而且文檔清楚瞭解運行時和計算環境的限制。這裏的工做流程正在轉向支持分佈式系統（微服務），並鼓勵開發人員從目前「推薦的作法」中構建本身的持續交付管道的工做流程，可能使用Concourse或Spinnaker等工具。

第四代：Kubernetes，Docker Swarm，Mesos，HashiCorp Nomad，AWS ECS等等（我明白這些並非真正的PaaS）。這種類型的平臺基礎設施是不可知的。誰沒有參加過會議而且看到Kubernetes在Raspberry Pi集羣上運行？並且老是接觸到構成集羣的底層計算和網絡基礎設施（AWS Fargate例外）。也能夠部署任何類型的容器或流程。這個平臺出現了構建「雲原生」應用的願望，這些應用程序本質上是分佈式的。這裏的「最佳實踐」工做流程還沒有定義，或者更準確地說，目前仍與技術協同發展 - 而且咱們正在對CI / CD進行最新的瞭解並改進。

所以，這是一個有趣的開源和商業工具正在出現的領域：想一下Datawire的Forge和Telepresence 工做流工具，Ambassador的交通轉移/部署，Weaveworks的Flux和Scope，Heptio和Bitnami的ksonnet，微軟的Draft 和 Helm，Containous traefik負載均衡器/ API網關。

我相信平臺與工做流程耦合之間產生了混淆，由於不少企業部署了粗粒度（單體？）風格的應用程序，其中工做流與平臺緊密結合。即第一代和第二代PaaS，或者工做流鬆散耦合，但定義明確，咱們沒有注意到這種摩擦 - 即在傳統基礎架構或第三代PaaS上構建和部署特定語言的組件。

第四代平臺面臨挑戰，技術仍在成熟，架構及相關組織最佳實踐也在共同發展中--分別考慮微服務和無服務器，以及 inverse Conway maneuver。業務對速度，穩定性和可見性的壓力也愈來愈大，這一般是經過將業務流程（造成跨職能業務部門）分解並將決策權下放給一線工做團隊來實現的。這以商業運動爲表明，例如 holacracies 和 Teal organizations。

回顧上面的軟件開發層面，須要指出的一個關鍵點是，基礎設施和平臺正在變得愈來愈分散和分離，但它們是經過集中化的力量實現的 - 例如基礎設施中的AWS，以及平臺中的Kubernetes（Apps SIG）社區，它定義了經常使用的協議，標準和接口。工做流程也變得分散，但我認爲如今尚未集中的力量，即一種通用的描述性語言，一套工具和預約義（可插入）的工做流程步驟。

構建（Snowflake）定製工做流程
隨着擁抱Kubernetes的組織愈來愈多，團隊建立定製的開發者體驗工做流程，一般在單個組織內的團隊中存在差別，致使解決方案很脆弱，以及有限的共享學習。這些團隊試圖將他們的工做流程編寫成最終在Kubernetes之上創建一個平臺。部署到平臺上相當重要，但平臺和工做流的概念應該分開考慮和設計。緊密耦合平臺和工做流程會致使不靈活的開發人員工做流程。

相信Kubernetes的「平臺」在2018年已經變得愈來愈清晰。Kubernetes自己已經很好地成熟了，而Envoy，Conduit和Cilium等公司的服務網格正在填補平臺的一些缺失的部分。可是，圍繞開發人員的體驗還有不少想法須要去作。咱們看到Weaveworks GitOps和Atlassian BDDA（Build-Diff，Deploy-Apply）等方法論中將最佳實踐編纂在內，相信在應用程序開發（AppDev）領域會出現相似的東西。

Kubernetes可能會接管應用程序的整個生命週期
今天造成了Kubernetes無處不在的雲原生景觀。三家主要雲提供商，AWS、Google和微軟Azure都支持Kubernetes，甚至Docker和Cloud Foundry也在使用它。

是什麼使Kubernetes獨一無二？傳統意義上，一般是開源技術創造了商品化的產品替代主流閉源技術。 但Kubernetes一直是個例外。 「Linux是UNIX的競爭者，Apache web服務器是Apache IIS的競爭對手。那麼誰是Kubernetes的競爭對手？並無與之競爭的閉源產品，」CoreOS首席技術官兼聯合創始人Brandon Philips 說。

實質上，Kubernetes在與人們建立的全部腳本進行競爭，以將他們在筆記本電腦上開發的源代碼部署到生產環境中。有成千上萬的方法能夠作到這一點：CI / CD工做流程，bash腳本，配置管理工具等。爲了得到生產所需的全部東西，數週的開發一直是個痛苦的週期。這就是Kubernetes來拯救的地方。它經過建立 API 來縮短這個週期，提供了適用於任何類型的一致性和可重複性。

「這是Kubernetes的重點，」Philips表示，「隨着時間的推移，咱們可能會接管應用程序的整個生命週期，從idea到監控到應用程序工做流程，到最終退出應用程序。咱們已經看到用戶在擴展Kubernetes api。Philips認爲，這將繼續，「天空是咱們所依賴的抽象的極限。 「看看它在將來幾年的發展將會頗有趣。」

原文連接：
一、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow
https://thenewstack.io/kubern...
二、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications
https://thenewstack.io/time-k...