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

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

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

　　NoOps和DevOps

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

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

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

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

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

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

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

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

　　PaaS和核心原則

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

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

　　獲取應用運行需要的機器或?qū)嵗?/p>

　　加載操作系統(tǒng)

　　設置網(wǎng)絡并做好將它放到目標環(huán)境的準備

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

　　從系統(tǒng)本身獨立自主地構建/設置應用，推薦在開發(fā)機上進行

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

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

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

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

　　把想要使用的域名告訴PaaS

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

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

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

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

　　

 

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

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

　　客戶端和插件提供了UI和命令行能力，能夠通過簡單地將應用部署到PaaS?？蛻舳嗣钚兄挥袔撞?。例如：

　　sudo gem install vmc

　　vmc target api.cloudfoundry.com

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

　　你會看到一些反饋以及一些單擊回車就能繼續(xù)下一步的問題。初始部署時使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

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

　　curl your_app_name.cloudfoundry.com

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

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

　　更新應用無需重啟

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

　　推送應用：

　　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

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

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

　　對于PaaS來說，其關鍵特性之一就是要支持一個或者多個框架。下面是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這樣的服務，我們能夠進一步抽象PaaS，提供許多新的接口和命令。即使AppFog會提供Cloud Foundry的所有功能，AppFog PaaS也將會進一步的擴展Cloud Foundry以提供額外的功能。

　　工作原理

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

　　PaaS內(nèi)部

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

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

　　

 

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

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

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

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

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

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

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

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

　　架構元素——服務

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

　　架構元素——將來

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

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

　　DevOps，進入NoOps

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