Ruddy Lee 分享空間

Emergent Design 演化設計

如何將既有程式搬移到雲端上執行?

with 2 comments

這是一篇針對,微軟剛離職的總裁Ray ozzie 在他的Blog上談到「憂心企業只知道一窩蜂地將既有程式轉到雲端上去執行,而忽略了應該改寫成雲端的架構之舉所造成的負面效應的隱憂」,所做的回應。然而目前台灣的軟體業者,也是如此。 哪! 應該從哪裡開始呢?

《 由它存在的價值開始; 也就是從它原本所解決的商業問題開始》

將既有程式搬移到雲端上執行,你作對了嗎?!

老闆在想甚麼…
老闆:    把原有產品移植到雲端上面銷售(心思創意飛馳的表情),這是下一個十年的商機,無論如何要盡快做完!
老闆:    一定要盡快做到, 招集一下各部門主管,大家研究一下如何進行。
老闆:    大家努力一下,下星期一定要有個雛形,能先Show出來就可以了。
老闆:    加把勁! 下下星期客戶就要看了,至少要做到一些基本的功能…。
—–
工程師:  我按照Blog上的操作步驟跟說明,一下子就轉上去了,已經可以run起來了。
(記得跟老闆講,好像要改成分散式架構才對喔! 文件沒有! 測試? 還沒完全弄清楚 …? )

我是從2008年開始接觸微軟的雲端運算Windows Azure Platform (其實Windows Azure 只是微軟雲端運算的一個組件而已,還有 Windows Live、SharePoint Online、Office Online …等等),從那時候開始;就一直被問到:

「如何將既有程式搬移到雲端上執行?」
「有甚麼快速的方法,可以讓我們公司的產品很快的搬移到雲端上嗎? 」

接著在2009/2010 在台北講了TechDays,在北京TechEd2010也講了這個議題 ,私下也常被一些老闆們還有業務經理人問到它。這時他們的眼中總是充滿了希望,好像有無限的契機在等他們去發掘一般! 但如果是工程師或是RD的主管問到這個議題時,同樣的問題完全不同的表情,也是急切、也是急著找到答案,但腦後寫著的是救救我吧,老闆明天就要;下星期就要展示給國外的客戶看了!

其實,應該秉持敏捷理論 Agile 的精神:《做對了比做了更重要,因為資源是固定的》

【 將既有程式搬移到雲端上執行 – – 如何面對這個問題! 】

(首先要聲明的是,這裡所談的搬移到雲端上執行的程式,所指的是一般比較 General的 Web Application 。)

我把它區分成三個部分來思考這個問題,分別是:  資料、服務及流程。

【資料】原有的資料儲存的方式為何? 搬到雲端後要存取Windows Azure的 Storage 呢? 還是要申請一顆雲端的資料庫SQL Azure 來放資料,大小是 1/10G或更大?

【服務】原有的邏輯運算的部分,要全部包在以起呢? 還是改寫部分重要的邏輯運算成為獨立的服務呢?  要引用 Software Plus Service的架構嗎?  要考慮 Client 端銜接不同的系統嗎?

【流程】實際考量原有的「商業案例」若移植到雲端後的實用流程為何?老實說,對銷售行為而言, 第一個要考慮的是「如何擬定收費的方式」,雖是銷售行為但與技術卻有著極重要的關係,因為這一點可能對產品後續的發展有著全盤的改變。(想好好規劃一下,可以參考: http://www.amazon.com/Cloud-Computing-Convergence-Enterprise-Step/dp/0136009220)

從哪裡開始分析起呢?

因為是既有程式,所以就更容易做分析了,由資料的位置、商業案例的流程以及使用那些個服務可以用來解決問題的方式做分工, 然後由它存在的價值開始; 也就是從它原本所解決的商業問題開始。由既有的功能做分析起一直到它在雲端上執行時所要遭遇到的問題或缺點為止,那些個可以改善的地方正是我們的著眼點,有了可以動手的問題點,接著再用「服務」來彌補它,這就是SOA架構的優點,也是S+S鬆散式解決問題的迷人之處,它可以不用大動干戈就輕易的融入了原有的架構中,並且新增了功能也解決了既有的問題。(說穿了;就是透過分析把不好或有問題的地方以服務的方式改寫它)

移植轉換的功能分類

單就移植轉換的技術面來看這個問題,可以大概的區分成三個階段:
第一階段、是把程式需要的環境Namespaces 通通包起來,一起上傳到雲端的環境,只要沒有遺漏,按道理這樣做就能執行起來了。但例外還真不少,你可能呼叫到雲端尚未支援的功能(例如一些驅動程式或呼叫到 COM的服務等,這時候就沒這麼幸運了),只能退而求其次,將環境以 VM 的方式一整個上傳了。

這一階段只是讓自己公司的程式,能夠在微軟的Data Center裡頭執行起來,這樣的做法是無法享用到雲端運算所號稱的許多功能的,例如: 資源無限擴充的能力 …。但不管怎麼說,程式是在雲端跑起來了,只是沒享受到雲端運算應該擁有的能力罷了!

第二階段、是將原本的web 應用程式運用到IIS 伺服器的 狀態管理功能 改寫成指向雲端的provider(可以選擇要存在Azure 的Table內或是 存於SQL Azure內均可,二者都可,選擇那一種方式,則只有效能跟價格需要考量,請參考: http://msdn.microsoft.com/zh-tw/windowsazure/gg442342)。
完成這個階段轉換的程式,已經可以享用到雲端複製多個執行個體的功能了,而且可以做到動態的增減可複製的執行個體數。但話說回來,他還是一個完整的package,對Windows Azure platform 在架構上所提供的各種便利資源,並沒有特別去運用到,因此在效能上也比較難有顯著的表現。

第三階段、作成分散式的架構設計,運用雲端的角色功能(將顯示UI的展示層放到 Web Role,將邏輯層放到 Worker內),並將應用程式的架構調整成可以真正發揮雲端效益的形式(例如:充分運用Queue來聯繫各種角色之間的訊息傳遞,用來維繫架構鬆散的特性)。也就是當展示層的使用者介面登入率太高,不足以應付時可以動態的調整網站的數目來應付突然激增的網路要求。或是在邏輯層需要較多運算資源時,可以動態視需求作不定時的調整角色的數量來迅速提升效能,這一點在 IT部門每月遇到週期性運算負載時特別有用。
這一個階段應該是未來企業在挑選雲端產品時的基本考量吧!

請問,你目前做到哪一個階段呢?

Ray Ozzie 的憂心?

這篇感想是被微軟剛離職的總裁ray ozzie 在他的Blog上談到憂心企業只知道一窩蜂地將既有程式轉到雲端上去執行,而忽略了應該改寫成雲端的架構之舉所造成的負面效應的隱憂的 一個回應。因為同樣的現象也發生在台灣,老闆總愛誇口說我們公司的 RD,只花了幾天的時間就把原有的程式搬移到雲端上去執行了,卻完全忽略掉工程師憂心忡忡於程式移植到雲端上去執行的架構是對與錯的掛慮!  真糟糕…
其實;將既有程式搬移到雲端上執行,正可以考驗到這個「既有程式」的架構,是否符合服務導向架構SOA的規範。你可以姑且不考慮是否改成 Web Role 或Worker Role 的雲端角色效益,因為畢竟不是大家都有橫向延展資源的需求,但倒是應該以網際網路的觀點來看應用程式應該設計成怎麼樣的分散式架構,才是達成充分雲端資源的最基本的要求,而不是轉上去之後,只要可以跑起來了,就算擁有雲端上的產品了!(請參考企業將SOA 運用在雲端平台上的基本階層圖示)
將SOA 運用在雲端平台上的基本階層圖示

Written by ruddyllee

2011 年 02 月 22 日 於 22:29:10

2 回應

Subscribe to comments with RSS.

  1. http://www.plurk.com/amsen1/invite
    認真.大家為你加油!!!

    amsen1

    1999 年 11 月 30 日 at 08:00:00


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

你正使用 WordPress.com 帳號留言。 登出 / 變更 )

Twitter picture

你正使用 Twitter 帳號留言。 登出 / 變更 )

Facebook照片

你正使用 Facebook 帳號留言。 登出 / 變更 )

Google+ photo

你正使用 Google+ 帳號留言。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: