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）社群，它定義了常用的協議，標準和介面。工作流程也變得分散，但我認為現在還沒有集中的力量，即一種通用的描述性語言，一套工具和預定義（可插入）的工作流程步驟。

隨著擁抱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認為，這將繼續，“天空是我們所依賴的抽象的極限。 “看看它在未來幾年的發展將會很有趣。”

原文連結：
1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow
https://thenewstack.io/kubernetes-paas-force-developer-experience-workflow/
2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications
https://thenewstack.io/time-kubernetes-may-take-entire-lifecycle-applications/