【前言】
PaaS并不是一個陌生的話題，在新興的容器世界里，我們如何看待運維和PaaS的關系呢? 又如何重新思考Dev與Ops的定位呢? 本文作者就此分享了自己的一些獨特見解。比如作者說：Docker 最棒的一點在于它為開發和運維劃分了一個清晰的界線：任何在容器內部的都是開發所關注的，而外部則是運維的天下。
是否還記得PaaS何時興起?
五六年前PaaS的概念才剛剛興起，當時有很多人(包括我自己)都認為運維這個職業將會因此走向衰亡。因為你可以把運維的工作交給PaaS平臺，然后去專注于自己所擅長的事情，所以應該不會再有人愿意去干那些和機器打交道的基礎服務方面的雜活吧?
現在，六年過去了，我們最終看到的是PaaS大量失敗的案例，我開始意識到我錯了，PaaS 并不是我想要的未來，它并不能夠完全解決基礎服務方面的一些難題，而僅僅只是讓這些問題稍有緩和罷了。
在一開始，PaaS服務提供商每個月投入數百到數千美金的經費和資源培養客戶，而最后只能眼睜睜看著他們離開，然后投入到云服務提供商的懷抱。
眼下的現實情況是公共的PaaS服務已經淪為一些菜鳥入門學習的平臺，而那些游戲的勝利者們已經拋棄了PaaS，而選擇在眾多的云服務平臺上搭建自己的服務器來承載他們的服務。
我之前曾經寫過一篇文章，講述了我為什么認為如此創新和流行的公共PaaS服務不能完全征服世界的一些見解，所以在這邊便不再贅述。但是這里有一個論點我想再深入強調一下，就是我個人認為我們也許又犯了一個同樣的錯誤，那就是“運維這個職業即將消亡”的這個預測。
相信從公共PaaS服務到開發者們所做的每件需要運維(我能稱之為DevOps嗎?)參與的事情里我們看到的和解讀到的，你可以感覺到“運維”其實離我們并不是很遙遠，然而它始終處在一個即將消亡的風口浪尖。我想這種“運維即將消亡”的思想多數來自于我們之中那些幸運的沒有去到一個大型或者老牌企業工作過的朋友，或者是單純以技術角度去看待這個問題而非企業的角度的朋友。
任何企業都依然需要運維的工作。如果他們并非如此的話，那么他們一定是把這些事情重新定義了一下(就比如開發穿上了運維的帽子，然后干起了搬機器的活)或者是臨時的把這些事情外包給了一些公共PaaS服務提供商，就像現在很多企業實際所做的那樣。
這并不是簡單的技術架構問題，也和業務結構有一定關系。在業務邏輯里，對于創新(Dev)和保持穩定收益(Ops)有各自不同的生命周期，而我們有充分的理由告訴那些想用所研發的技術在大的方向上使得企業騰飛的開發者們大可不必承擔所有的事情，而他們也必須認識到這一點。
在這里，就我個人來說，我覺得公共PaaS沒能真正興盛的最大原因在于：隨著業務規模的增長，企業們需要規范和簡化他們的運維，而這就造成了運維人員重新從外部PaaS服務提供商接管過來本就屬于運維的工作(或者，更恰當的說，是這些企業會將開發者們安排到不同的業務周期)。反之，這也就是為什么像Cloudfoundry這樣的私有PaaS服務比他們的公共服務兄弟做的更出彩的原因之所在：他們是運維人員的工具，也同樣迎合開發人員的需求。他們之所以如此成功是因為他們認識到了運維真正的存在價值：他們充當的是一個為運維人員提供服務的資源管理工具集而不是一個發明出來用以替代“運維”的工具。
讓我們不要再忘了運維
然而，我感覺我們在這個新興的容器世界也許又會再次犯下我們之前在公共PaaS所犯過的同樣的錯誤。大多數用于在生產環境運行和管理容器的解決方案顯得過于以開發為中心了。他們并沒有一個清晰的界限指明應用應該如何規范的停止服務，基礎服務的一些需求應該怎樣去實現。
類似Docker Swarm這樣的工具是在概念的層次上指明開發和運維如何在最初從各自的角度去使用這些工具集的很好的例子，然而在應用規范方面我們仍然有大量的工作需要去做：怎樣去定義服務的概念，他們如何去跟其他的實體交互，在與其它實體交互時他們應該使用什么樣的協議，等等。這些都是應用層面規范的問題。
接下來我們需要面對的是一系列的運維方面的問題：怎樣把資源裝載到我們的基礎架構，如何構建我們所需要的實體，如何約束每個服務的服務范疇以及他們如何定位其它反映基礎服務配置的實體(譯者注：比如說定位到同一個IDC或網絡通信質量高的服務實體，而不是隨機選擇)，等等。
當我關注到類似Swarm和Compose這樣從不同的功能清晰劃分的工具集時內心備受鼓舞。然而它們并沒有在API中對開發和運維做很大的區分。舉個例子，Compose(持續工作中的)傾向于支持所有的Docker CLI命令行選項參數，而大部分(也許不是全部)的Docker CLI 命令行參數是純粹的以開發為中心設計的。
Docker 最棒的一點在于它為開發和運維劃分了一個清晰的界線：任何在容器內部的都是開發所關注的，而外部則是運維的天下。當前版本的Compose API以及開發的 Swarm 在某種程度上來說反而是模糊了這個劃分的邊界。
我們正在努力試圖讓這個劃分變得更清晰并且體現到實際的企業生產業務中。manifest.yml和services.yml的劃分或是我們UI的構建方式都是一些我們試圖推動這一愿景的最初的嘗試。關于這些，我們非常歡迎得到您的一些想法和反饋。
京公網安備 11010502049343號