企業(yè)架構(gòu)真的準(zhǔn)備好接受云計(jì)算了嗎?那么云計(jì)算也真的適合企業(yè)的架構(gòu)嗎?云計(jì)算的出現(xiàn)確實(shí)帶來了一些不同的思考方式，但實(shí)際上這些“新”思路，并不是那么新。

來自IT及云計(jì)算咨詢服務(wù)供應(yīng)商Appirio公司的Chris Bruzzi和Nick Hamm曾發(fā)表過一篇文章，其中兩人與CIO們分享了一些關(guān)于云應(yīng)用開發(fā)的個(gè)人經(jīng)驗(yàn)。他們?cè)谖闹兄赋?，?yīng)用的開發(fā)和部署過程中，執(zhí)行者應(yīng)該注意在五個(gè)方面改變自己的固有習(xí)慣，以便更好地為企業(yè)實(shí)現(xiàn)云計(jì)算?，F(xiàn)在，這些思路依舊適用。

對(duì)于擁有SOA(面向服務(wù)架構(gòu))領(lǐng)域工作經(jīng)驗(yàn)的架構(gòu)師和開發(fā)者來說，最成功的那些實(shí)踐案例大多都極為相似。但Bruzzi和Hamm卻認(rèn)為過去的SOA架構(gòu)有很大的局限性，因?yàn)樗偸潜黄髽I(yè)整體架構(gòu)擋在門外。然而隨著越來越多的企業(yè)IT開始轉(zhuǎn)向云計(jì)算，人們真的應(yīng)該重新考慮“面向服務(wù)”式思路了：

1. 利用組件化的方式來設(shè)計(jì)架構(gòu)解決方案：先考慮清楚企業(yè)的需求是什么，然后再設(shè)計(jì)一個(gè)以多個(gè)松散耦合組件構(gòu)成的解決方案，以滿足企業(yè)的總體需求。這樣做確實(shí)會(huì)增加前期的工作量，但后期得到的回報(bào)卻要比付出大得多。

2. 越過應(yīng)用開發(fā)語言來審視API接口：10年前，所謂的IT企業(yè)不是Java商店就是.NET商店。云計(jì)算將問題焦點(diǎn)從應(yīng)用引向了應(yīng)用開發(fā)語言和服務(wù)交付平臺(tái)。這就意味著云計(jì)算架構(gòu)師也需要將目光從技術(shù)或開發(fā)語言上，轉(zhuǎn)移到那些用于使用這些技術(shù)和語言的架構(gòu)服務(wù)及API接口上。

3. 盡可能多地重復(fù)使用組件：這些云計(jì)算規(guī)劃方案中的組件也許已經(jīng)能夠有效地發(fā)揮作用了，無論這些組件是來自企業(yè)自己的程序庫內(nèi)部或是外部的云計(jì)算供應(yīng)商，例如Salesfroce.com和Amazon Web Services(亞馬遜網(wǎng)絡(luò)服務(wù))，都可以重復(fù)使用。

4. 以外包的形式擴(kuò)展團(tuán)隊(duì)：留意開發(fā)者社區(qū)，比如CloudSpokes或是99Designs ，并在那里尋找新的組件。這樣做的好處在于，應(yīng)用的構(gòu)建速度會(huì)大大加快，同時(shí)避免了受限于所在團(tuán)隊(duì)的整體技術(shù)能力。許多頗具創(chuàng)造性的解決方案都是在這種情況下設(shè)計(jì)出來的。

5. 對(duì)企業(yè)內(nèi)部應(yīng)用進(jìn)行評(píng)估：在云計(jì)算解決方案中，有大量關(guān)于企業(yè)內(nèi)部應(yīng)用在配置、編碼、質(zhì)量等方面的可用數(shù)據(jù)以供評(píng)估。某些云計(jì)算解決方案供應(yīng)商也會(huì)收集這些基準(zhǔn)測(cè)試程序數(shù)值，但是他們肯定不會(huì)提供所有的資料，因此架構(gòu)師有必要自己去做些收集工作。