PaaS的未來(lái)會(huì)是什么樣的呢?NoOps和DevOps又如何融入其中呢?PaaS將會(huì)讓開(kāi)發(fā)者生活的更加輕松。

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

　　本文將會(huì)深入介紹NoOps和DevOps以及它們和Paas之間的關(guān)系。然后會(huì)簡(jiǎn)短的描述導(dǎo)致PaaS技術(shù)產(chǎn)生的原因，同時(shí)會(huì)介紹第一個(gè)開(kāi)源的解決方案Cloud Foundry。我們會(huì)深入介紹它產(chǎn)生的原因、架構(gòu)以及一個(gè)應(yīng)用的簡(jiǎn)單部署。本文還將會(huì)介紹PaaS的核心概念。

　　NoOps和DevOps

　　首先，我們快速給它們下一個(gè)定義：

　　NoOps - 除了部署基于PaaS的應(yīng)用(通常是一個(gè)SaaS應(yīng)用)之外，不需要任何運(yùn)維。這是具有獨(dú)立開(kāi)發(fā)和產(chǎn)品團(tuán)隊(duì)的小型、初創(chuàng)以及中大型企業(yè)的主要需求，它們需要能快速地部署原型或應(yīng)用而不必為基礎(chǔ)設(shè)施及其他系統(tǒng)相關(guān)的問(wèn)題而操心。

　　DevOps - 開(kāi)發(fā)者和運(yùn)維人員的結(jié)合，形成滿足雙方需要的職業(yè)形象。DevOps通常維護(hù)網(wǎng)絡(luò)、基礎(chǔ)設(shè)施、平臺(tái)及實(shí)際的代碼庫(kù)和應(yīng)用部署。DevOps很少見(jiàn)、高度集中而且內(nèi)涵豐富。

　　在NoOps成為開(kāi)發(fā)者的選擇之前，DevOps試圖通過(guò)為開(kāi)發(fā)者提供運(yùn)維接口來(lái)解決問(wèn)題。NoOps的前提是開(kāi)發(fā)者在無(wú)需操心運(yùn)維的情況下即可完成工作。這并不意味著運(yùn)維的消失。幕后的運(yùn)維人員會(huì)微調(diào)一切，保持它的運(yùn)行。這是他們所擅長(zhǎng)的，他們也不會(huì)消失。我們僅需確保開(kāi)發(fā)者為了完成工作需要“無(wú)需運(yùn)維”。

　　開(kāi)發(fā)者不必關(guān)心網(wǎng)絡(luò)，因?yàn)闆](méi)有必要;他們不必處理路由問(wèn)題、保持實(shí)例在線、崩潰或者如何存儲(chǔ)，因?yàn)樗麄儾恍枰Ｋ麄兾ㄒ坏呢?zé)任和工作就是要關(guān)注應(yīng)用及其業(yè)務(wù)價(jià)值。

　　源自何處?傳統(tǒng)開(kāi)發(fā)

　　傳統(tǒng)開(kāi)發(fā)通常包含很多乏味的任務(wù)，包括機(jī)器配置、資源分配、機(jī)器的規(guī)格、說(shuō)明以及相關(guān)的溝通，有的還需要預(yù)估未來(lái)的負(fù)載，并預(yù)留相應(yīng)的資金來(lái)采購(gòu)機(jī)器。然后是安裝、配置、將機(jī)器資源放置在數(shù)據(jù)中心、主機(jī)托管中心或者在某些情況下放在公司大樓里。即使在最好的情況下，這些方法都是有挑戰(zhàn)的，而在最壞的情況下，則需要經(jīng)過(guò)嘗試和錯(cuò)誤的考驗(yàn)。PaaS和未來(lái)的NoOps，甚至某種程度的DevOps都消除了這種傳統(tǒng)軟件開(kāi)發(fā)的噩夢(mèng)。

　　所有這些傳統(tǒng)的環(huán)境問(wèn)題多年來(lái)耗費(fèi)了軟件產(chǎn)業(yè)數(shù)十億美元。但是，變革正在發(fā)生，并且已經(jīng)改變了軟件開(kāi)發(fā)的模式。這種進(jìn)步就像從匯編到C/C++再到更高層次的Java、C#或Ruby等抽象語(yǔ)言的進(jìn)步一樣巨大。移植到PaaS，相應(yīng)地消除了操作系統(tǒng)的障礙，極大地改善了軟件開(kāi)發(fā)方式。

　　PaaS和核心原則

　　PaaS的核心原則就是簡(jiǎn)化應(yīng)用的生命周期管理，即應(yīng)用的啟動(dòng)、停止和部署。

　　讓我們對(duì)傳統(tǒng)的部署過(guò)程和PaaS做一個(gè)比較。首先，深入了解一下傳統(tǒng)的開(kāi)發(fā)過(guò)程。

　　獲取應(yīng)用運(yùn)行需要的機(jī)器或?qū)嵗?/p>

　　加載操作系統(tǒng)

　　設(shè)置網(wǎng)絡(luò)并做好將它放到目標(biāo)環(huán)境的準(zhǔn)備

　　設(shè)置托管的Web服務(wù)器或準(zhǔn)備部署的服務(wù)文件及文件夾

　　從系統(tǒng)本身獨(dú)立自主地構(gòu)建/設(shè)置應(yīng)用，推薦在開(kāi)發(fā)機(jī)上進(jìn)行

　　驗(yàn)證部署配置能夠遷移到不同的環(huán)境

　　將代碼塊和應(yīng)用依賴性加入源代碼控制系統(tǒng)

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

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

　　把想要使用的域名告訴PaaS

　　將代碼塊和應(yīng)用依賴性加入源代碼控制Github一直都是一個(gè)好地方。

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

　　然后代碼庫(kù)會(huì)自動(dòng)被推到PaaS提供商，自動(dòng)地構(gòu)建并部署到系統(tǒng)中。

　　這就是整個(gè)過(guò)程。只有三步，很簡(jiǎn)單。

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

　　架構(gòu)元素——客戶端和插件

　　客戶端和插件提供了UI和命令行能力，能夠通過(guò)簡(jiǎn)單地將應(yīng)用部署到PaaS。客戶端命令行只有幾步。例如：

　　sudo gem install vmc

　　vmc target api.cloudfoundry.com

　　現(xiàn)在，以創(chuàng)建了一個(gè)node.js應(yīng)用為例，添加一個(gè)包含以下內(nèi)容的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

　　你會(huì)看到一些反饋以及一些單擊回車就能繼續(xù)下一步的問(wèn)題。初始部署時(shí)使ga用默認(rèn)值就可以。我只有一處沒(méi)有使用默認(rèn)值，僅僅為了顯示一些簡(jiǎn)單的應(yīng)用到服務(wù)的綁定，這一處輸入1，即選擇mongodb服務(wù)。

　　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

　　即使實(shí)際上不需要安裝數(shù)據(jù)庫(kù)，我這樣做的目的是為了說(shuō)明安裝一個(gè)服務(wù)是多么容易的一件事。此時(shí)，我們已經(jīng)有了一個(gè)運(yùn)行中的應(yīng)用，可以使用curl證明它已經(jīng)運(yùn)行：

　　curl your_app_name.cloudfoundry.com

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

　　現(xiàn)在，讓我們看看可以對(duì)應(yīng)用程序做哪些事情以及Cloud Foundry 環(huán)境。

　　更新應(yīng)用無(wú)需重啟

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

　　推送應(yīng)用：

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

　　檢出實(shí)例：

　　vmc instances blaghApp-v1 1

　　取消映射應(yīng)用實(shí)例：

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

　　通過(guò)下面的命令組合進(jìn)行回滾：

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

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

　　停止同一已映射的應(yīng)用程序：

　　vmc stop blaghApp-v1

　　還有很多其他的命令和選項(xiàng)。更多內(nèi)容請(qǐng)?jiān)L問(wèn)： http://cloudfoundry.org.

　　與框架和服務(wù)相關(guān)的更多材料

　　對(duì)于PaaS來(lái)說(shuō)，其關(guān)鍵特性之一就是要支持一個(gè)或者多個(gè)框架。下面是Cloud Foundry和Iron Foundry聯(lián)合之后為用戶提供的主要選擇。

　　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這樣的服務(wù)，我們能夠進(jìn)一步抽象PaaS，提供許多新的接口和命令。即使AppFog會(huì)提供Cloud Foundry的所有功能，AppFog PaaS也將會(huì)進(jìn)一步的擴(kuò)展Cloud Foundry以提供額外的功能。

　　工作原理

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

　　PaaS內(nèi)部

　　作為服務(wù)提供者的平臺(tái)內(nèi)部含有很多底層的內(nèi)容，這通常會(huì)讓它變得非常復(fù)雜。它需要有自恢復(fù)能力，能夠啟動(dòng)和停止服務(wù)器實(shí)例及相關(guān)的功能。所有的這些事情都需自動(dòng)化，盡可能少的人工參與。.

　　下面是AppFog、Stackato等提供平臺(tái)服務(wù)的公司所使用的Cloud Foundry和Iron Foundry軟件的一個(gè)簡(jiǎn)單的圖表。

　　架構(gòu)元素——Cloud Foundry核心系統(tǒng)架構(gòu)

　　Cloud Foundry系統(tǒng)的核心和Iron Foundry的附加功能都圍繞著控制器。通常我們將其稱之為“控制器的概念”，使之與其他十幾個(gè)使用相似術(shù)語(yǔ)的模式區(qū)分開(kāi)?？刂破魇亲曰謴?fù)的，能夠在一個(gè)平臺(tái)架構(gòu)中多次使用。

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

　　架構(gòu)元素——Droplet執(zhí)行引擎

　　Droplet執(zhí)行引擎(DEA)是一個(gè)程序，它能夠簡(jiǎn)化部署并啟動(dòng)Apache或其他服務(wù)器上的代碼。它們的工作是執(zhí)行最終用戶的代碼。

　　DEA是跨平臺(tái)運(yùn)行整體架構(gòu)的一部分。它可能包含Node.js、Java，Iron Foundry是為.NET擴(kuò)展的DEA。DEA可以有很多，配置也不同，這樣就能根據(jù)它們?cè)ǖ挠猛就昝赖貫樘囟ǖ膶?shí)例分配大小。

　　架構(gòu)元素——路由和健康管理器

　　路由好比系統(tǒng)中的事件守護(hù)進(jìn)程，其責(zé)任是監(jiān)聽(tīng)將要激活的新應(yīng)用。而健康管理器的作用是識(shí)別任何可能產(chǎn)生的問(wèn)題，并通過(guò)告知控制器或者其他機(jī)制來(lái)解決這些問(wèn)題。

　　架構(gòu)元素——服務(wù)

　　在Cloud Foundry中服務(wù)是最好的擴(kuò)展點(diǎn)之一。在這個(gè)領(lǐng)域內(nèi)有很多擴(kuò)展，例如MySQL、Redis、SQL Server等。

　　架構(gòu)元素——將來(lái)

　　盡管Cloud Foundry是經(jīng)過(guò)深思熟慮的，但是它依然有許多最終特性需要實(shí)現(xiàn)。例如，許多企業(yè)的用例依然需要諸如審計(jì)、認(rèn)證和編排之類的功能。毫無(wú)疑問(wèn)，有其團(tuán)隊(duì)在背后的支持，Cloud Foundry在不久的將來(lái)將會(huì)新增很多特性和功能。

　　如果想要更深入的了解架構(gòu)，可以查看Derek Collison的描述"Cloud Foundry-技術(shù)內(nèi)幕"。

　　DevOps，進(jìn)入NoOps

　　從架構(gòu)設(shè)計(jì)中我們能夠發(fā)現(xiàn)，仍然有大量的需求，要求PaaS供應(yīng)商提供強(qiáng)大的DevOps方面的支持。但是，隨著這種形勢(shì)的鞏固，它會(huì)驅(qū)動(dòng)DevOps轉(zhuǎn)向PaaS提供商所提供的更加精密和集中的價(jià)值。但是在小企業(yè)、中型或者任何PaaS用戶的外部和內(nèi)部，它能夠提供一個(gè)條件使DevOps角色轉(zhuǎn)變成提供商，使業(yè)務(wù)的核心競(jìng)爭(zhēng)力聚焦于應(yīng)用和需求。隨著這種轉(zhuǎn)變，最終會(huì)進(jìn)入NoOps的時(shí)代，更加專注于業(yè)務(wù)、干凈的應(yīng)用開(kāi)發(fā)、更短的周期以及始終難以捉摸的敏捷性提升。