PaaS的未來會是什么樣的呢?NoOps和DevOps又如何融入其中呢?PaaS將會讓開發者生活的更加輕松。

　　實際上，PaaS是一些事物的混合體，它關注更快的部署用時、更低的準入門檻、更高的擴展性、高可用性和地理上分散的系統等。那么，如何為PaaS做好準備呢?首先，需要理解一些關鍵概念，而我們首先就會介紹這些概念。

　　本文將會深入介紹NoOps和DevOps以及它們和Paas之間的關系。然后會簡短的描述導致PaaS技術產生的原因，同時會介紹第一個開源的解決方案Cloud Foundry。我們會深入介紹它產生的原因、架構以及一個應用的簡單部署。本文還將會介紹PaaS的核心概念。

　　NoOps和DevOps

　　首先，我們快速給它們下一個定義：

　　NoOps - 除了部署基于PaaS的應用(通常是一個SaaS應用)之外，不需要任何運維。這是具有獨立開發和產品團隊的小型、初創以及中大型企業的主要需求，它們需要能快速地部署原型或應用而不必為基礎設施及其他系統相關的問題而操心。

　　DevOps - 開發者和運維人員的結合，形成滿足雙方需要的職業形象。DevOps通常維護網絡、基礎設施、平臺及實際的代碼庫和應用部署。DevOps很少見、高度集中而且內涵豐富。

　　在NoOps成為開發者的選擇之前，DevOps試圖通過為開發者提供運維接口來解決問題。NoOps的前提是開發者在無需操心運維的情況下即可完成工作。這并不意味著運維的消失。幕后的運維人員會微調一切，保持它的運行。這是他們所擅長的，他們也不會消失。我們僅需確保開發者為了完成工作需要“無需運維”。

　　開發者不必關心網絡，因為沒有必要;他們不必處理路由問題、保持實例在線、崩潰或者如何存儲，因為他們不需要。他們唯一的責任和工作就是要關注應用及其業務價值。

　　源自何處?傳統開發

　　傳統開發通常包含很多乏味的任務，包括機器配置、資源分配、機器的規格、說明以及相關的溝通，有的還需要預估未來的負載，并預留相應的資金來采購機器。然后是安裝、配置、將機器資源放置在數據中心、主機托管中心或者在某些情況下放在公司大樓里。即使在最好的情況下，這些方法都是有挑戰的，而在最壞的情況下，則需要經過嘗試和錯誤的考驗。PaaS和未來的NoOps，甚至某種程度的DevOps都消除了這種傳統軟件開發的噩夢。

　　所有這些傳統的環境問題多年來耗費了軟件產業數十億美元。但是，變革正在發生，并且已經改變了軟件開發的模式。這種進步就像從匯編到C/C++再到更高層次的Java、C#或Ruby等抽象語言的進步一樣巨大。移植到PaaS，相應地消除了操作系統的障礙，極大地改善了軟件開發方式。

　　PaaS和核心原則

　　PaaS的核心原則就是簡化應用的生命周期管理，即應用的啟動、停止和部署。

　　讓我們對傳統的部署過程和PaaS做一個比較。首先，深入了解一下傳統的開發過程。

　　獲取應用運行需要的機器或實例

　　加載操作系統

　　設置網絡并做好將它放到目標環境的準備

　　設置托管的Web服務器或準備部署的服務文件及文件夾

　　從系統本身獨立自主地構建/設置應用，推薦在開發機上進行

　　驗證部署配置能夠遷移到不同的環境

　　將代碼塊和應用依賴性加入源代碼控制系統

　　在某些方式下，從源代碼控制系統中獲取應用，部署到之前創建的服務器，方法有move、x-copy、使用msi安裝、bash腳本或者配置。

　　好了，一共需要八步。其中有些步驟很耗時，也很痛苦。接下來我們看看將同樣的應用部署到Paas解決方案(在這里我們使用AppFog)中必須要做哪些事情?

　　把想要使用的域名告訴PaaS

　　將代碼塊和應用依賴性加入源代碼控制Github一直都是一個好地方。

　　點擊Create按鈕或者使用簡單的命令行工具，如af push，讓代碼上線(如圖所示)

　　然后代碼庫會自動被推到PaaS提供商，自動地構建并部署到系統中。

　　這就是整個過程。只有三步，很簡單。

　　

 

　　此屏幕截圖是一個非常好的例子，它包含了通過UI或者命令行開始所需要的所有內容。這是一個AppFog PaaS的預展，其核心利用了Cloud Foundry。

　　架構元素——客戶端和插件

　　客戶端和插件提供了UI和命令行能力，能夠通過簡單地將應用部署到PaaS。客戶端命令行只有幾步。例如：

　　sudo gem install vmc

　　vmc target api.cloudfoundry.com

　　現在，以創建了一個node.js應用為例，添加一個包含以下內容的app.js文件：

　　var vmc_port = (process.env.VMC_APP_PORT || 3000);

　　var vmc_host = (process.env.VCAP_APP_HOST || 'localhost');

　　var vmc_http = require('http');

　　http.createServer(function (req, res) {

　　res.writeHead(200, {'Content-Type': 'text/plain'});

　　res.end('Foo, I'm Alive!!\n');

　　}).listen(port, host);

　　然后在該文件所在的目錄下使用如下命令：

　　vmc push

　　你會看到一些反饋以及一些單擊回車就能繼續下一步的問題。初始部署時使ga用默認值就可以。我只有一處沒有使用默認值，僅僅為了顯示一些簡單的應用到服務的綁定，這一處輸入1，即選擇mongodb服務。

　　Would you like to deploy from the current directory? [Yn]: Y

　　Application Name: some_app_name

　　Application Deployed URL: 'you_test_subdomain.cloudfoundry.com'?

　　Detected a Node.js Application, is this correct? [Yn]: Y

　　Memory Reservation [Default:64M] (64M, 128M, 256M, 512M, 1G or 2G)

　　Creating Application: OK

　　Would you like to bind any services to 'gvp_node_test'? [yN]: y

　　The following system services are available::

　　mongodb

　　mysql

　　redis

　　Please select one you wish to provision: 1

　　Specify the name of the service [mongodb-55666]:

　　Creating Service: OK

　　Binding Service: OK

　　Uploading Application:

　　Checking for available resources: OK

　　Packing application: OK

　　Uploading (0K): OK

　　Push Status: OK

　　Staging Application: OK

　　Starting Application: OK

　　即使實際上不需要安裝數據庫，我這樣做的目的是為了說明安裝一個服務是多么容易的一件事。此時，我們已經有了一個運行中的應用，可以使用curl證明它已經運行：

　　curl your_app_name.cloudfoundry.com

　　上面的命令會獲得響應：“Foo,I’m alive!!”。就這樣，應用部署完成了。一共只有安裝、選擇目標、推送這三步。

　　現在，讓我們看看可以對應用程序做哪些事情以及Cloud Foundry 環境。

　　更新應用無需重啟

　　有一些事情需要定期去做，如更新、重啟和推送應用。具體工作包括：

　　推送應用：

　　vmc push blaghApp-v1 --url blaghApp-v1.cloudfoundry.com

　　檢出實例：

　　vmc instances blaghApp-v1 1

　　取消映射應用實例：

　　vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com

　　通過下面的命令組合進行回滾：

　　vmc map blaghApp-v1 blaghApp-v1.cloudfoundry.com

　　vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com

　　停止同一已映射的應用程序：

　　vmc stop blaghApp-v1

　　還有很多其他的命令和選項。更多內容請訪問： http://cloudfoundry.org.

　　與框架和服務相關的更多材料

　　對于PaaS來說，其關鍵特性之一就是要支持一個或者多個框架。下面是Cloud Foundry和Iron Foundry聯合之后為用戶提供的主要選擇。

　　Node.js

　　GettingStartedwithVMwareCloudFoundry, MongoDB, andNode.js

　　Node.jsandCloudFoundry

　　CloudFoundryintrotoNode.js

　　Sinatra + Rails

　　SettingupRakeforSinatraw/ CloudFoundry

　　AddingRSpecw/ CloudFoundry & CloudFoundry

　　Sinatra, CloudFoundry, andTheDirtyDetails

　　PHP

　　SamplePHPSiteSetupw/ GithubRepo & CloudFoundry

　　Drupalw/ CloudFoundry

　　Java

　　GettingStartedw/ Sprint & RabbitMQ

　　Java + Spring + More

　　ASP.NET

　　IronFoundry + CloudFoundry

　　使用像AppFog這樣的服務，我們能夠進一步抽象PaaS，提供許多新的接口和命令。即使AppFog會提供Cloud Foundry的所有功能，AppFog PaaS也將會進一步的擴展Cloud Foundry以提供額外的功能。

　　工作原理

　　到目前為止，我們已經介紹了基礎內容，概括了PaaS為那些準備使用它的公司真正提供的功能。下面我們深入介紹是什么造就了如此巨大的飛躍。

　　PaaS內部

　　作為服務提供者的平臺內部含有很多底層的內容，這通常會讓它變得非常復雜。它需要有自恢復能力，能夠啟動和停止服務器實例及相關的功能。所有的這些事情都需自動化，盡可能少的人工參與。.

　　下面是AppFog、Stackato等提供平臺服務的公司所使用的Cloud Foundry和Iron Foundry軟件的一個簡單的圖表。

　　

 

　　架構元素——Cloud Foundry核心系統架構

　　Cloud Foundry系統的核心和Iron Foundry的附加功能都圍繞著控制器。通常我們將其稱之為“控制器的概念”，使之與其他十幾個使用相似術語的模式區分開。控制器是自恢復的，能夠在一個平臺架構中多次使用。

　　圍繞控制器有很多控制輔助技術，例如Resque和Stager。NATS提供的pub/sub功能可以充當這些組件之間的粘合劑，并賦予它在這樣的系統中所需要的彈性。

　　架構元素——Droplet執行引擎

　　Droplet執行引擎(DEA)是一個程序，它能夠簡化部署并啟動Apache或其他服務器上的代碼。它們的工作是執行最終用戶的代碼。

　　DEA是跨平臺運行整體架構的一部分。它可能包含Node.js、Java，Iron Foundry是為.NET擴展的DEA。DEA可以有很多，配置也不同，這樣就能根據它們原定的用途完美地為特定的實例分配大小。

　　架構元素——路由和健康管理器

　　路由好比系統中的事件守護進程，其責任是監聽將要激活的新應用。而健康管理器的作用是識別任何可能產生的問題，并通過告知控制器或者其他機制來解決這些問題。

　　架構元素——服務

　　在Cloud Foundry中服務是最好的擴展點之一。在這個領域內有很多擴展，例如MySQL、Redis、SQL Server等。

　　架構元素——將來

　　盡管Cloud Foundry是經過深思熟慮的，但是它依然有許多最終特性需要實現。例如，許多企業的用例依然需要諸如審計、認證和編排之類的功能。毫無疑問，有其團隊在背后的支持，Cloud Foundry在不久的將來將會新增很多特性和功能。

　　如果想要更深入的了解架構，可以查看Derek Collison的描述"Cloud Foundry-技術內幕"。

　　DevOps，進入NoOps

　　從架構設計中我們能夠發現，仍然有大量的需求，要求PaaS供應商提供強大的DevOps方面的支持。但是，隨著這種形勢的鞏固，它會驅動DevOps轉向PaaS提供商所提供的更加精密和集中的價值。但是在小企業、中型或者任何PaaS用戶的外部和內部，它能夠提供一個條件使DevOps角色轉變成提供商，使業務的核心競爭力聚焦于應用和需求。隨著這種轉變，最終會進入NoOps的時代，更加專注于業務、干凈的應用開發、更短的周期以及始終難以捉摸的敏捷性提升。