Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 二月 2011

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

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 日 at 22:29:10

談雲端運算企業應該從哪裡開始?

leave a comment »

以企業再造的精神,發揮敏捷理論的務實態度,
從實踐服務導向SOA的方法開始。

 

  • 企業再造“Reengineering”因訊息流程的改變造成企業紛紛重建新的工作流程,是在1990年代初期風靡全世界的重要管理概念(http://en.wikipedia.org/wiki/Reengineering_(software))。
  • Agile 敏捷理論,2001年Agile Manifesto成立,宣布取代傳統瀑布式開發模式而走向迭代式務實的專案開發模式。
  • 服務導向架構(Service-oriented architecture)是構造分散式系統的應用程式的方法。它將應用程式的功能作成為"服務"發送給最終用戶或者其它的服務。自2004年以來IT最大的風潮。

由 1990年至今,年輕的軟體工程讓人清楚的看得到它累積下來的軌跡,成長下來的成效一一浮現了出來,似乎我們只要依循它的路徑,亦步亦趨地走下去就能到達下一個山峰,但接下來呢?! 還是得努力開創自己的山頭的!

※ 下面是幾個有趣的議題,正確答案也是隨著時間在變動的,大家在陰雨綿綿的二月天裡一起來欣賞一下吧。

【如何面對新的技術、新名詞 ?】

字典一定是越變越大,內容也越來越多的。一堆新興的名詞有如浪潮般地逐一的被收納入新編的字典中,然後很快的成為陳年往事,接著;又有另一批新的名詞迅速的成為下一批的候選者,等待著被定義;然後被放入字典中。這樣的浪潮;尤其在資訊發達的今天特別的快速,不論哪一種行業,都有著層出不窮的新詞,關於這一點;在生活的層面上,大家好像都能處之泰然,但一旦與自己的工作有著息息相關的時候,這又另當別論了。這裡我要談的是資訊界的新興名詞、新技術。那種比軟體 1.0 或 2.0 的更新更可怕的東西,那是一種看似全面性軟體改革的浪潮,這類的;讓我們經常不知所措的新技術新詞彙(例如: web 2.0 這類摸不到邊的東西)。雖然很多IT從業人員,對這些酷炫的新技術所帶來的吸引力,往往會過度的喧染,認為它遠遠超過那些舊有的平實的基本技能的表現,但其實還是應該平心靜氣的透過測試來評估它的效能好壞,而不是一意的求新。

我們應該如何來面對呢? 我想大家應該都已經有一套能說服自己的習慣性的理論了,但我是這麼做的,提供給大家做參考。

記下來

這個時候,我不見得有時間或有多餘的精力來K懂它到底是何方的神聖,但養成一種習慣 ”記下來”,或是記在筆記本、手機 … 日記裡,反正就是記下來。在不久的將來;只要有機會再碰到時,這就是有緣了! 又是練習自己強力搜尋能力的時候,立刻開始Google了。

為此;我往往會興奮的坐不下來,有一種尼可拉斯凱吉在《國家地理寶藏》那部戲裡的瘋狂尋寶態度,好像弄懂這個東東對我的一生就會有重大改變一般(才怪~),盡快的搜尋、努力的查訪,就是想盡辦法來弄懂它,然後假設要在課堂上講給眾多學員聽一般,一次再一次的思考,想想看如何才能做好最佳的展示,最好的說明。

哈! 這就是我對待新名詞之道! 你呢…

【那些個雲端服務免付費的services,到底是怎麼回事?】

天下不是沒有白吃的午餐嗎? 有ㄟ! 網際網路上就有一堆…。
像 Mail、Map、Sky drive …,都很像國家的公共服務一般,都是不用收費的,它往往是世界級的資源服務,是這個時代的產物,當然要立刻拿來享用啊,絲毫不用客氣。但是使用之際,我常常會有這樣的思維:
 

我應該做贈與的人還是受惠的人呢?

記得有一回帶著小鬼去參觀資訊展的時候,剛好有廠商在發放贈品,圍觀的人很多很多,孩子就問我該不該擠過去跟他們一起搶呢? 做父親的人當然要擺出一副有著良好教育涵養的姿態,不假思考的說道:『孩子,你要立志成為給人東西的人,而不是跟別人要東西的人, …』。我不曉得當下孩子們是怎麼想的,但面對網路上那些個可以白吃的服務,我多麼希望自己也能創造出這樣的東西,撒在網路上讓大眾一起享用,但事後回想起來就懂了,那不就是Open Source 開放源碼的精神嗎?!

軟體人應該追求Open Source的精神,但是付費嘛!會得到更好的 Service.

 

【個人雲端運算的時代】

在今年【CES現場】華碩 施崇棠 先生說:個人雲端運算是下一個30年的機會。

【雲端運算】的定義???
美國國家標準與技術研究院 (NIST)從2008年開始發佈它的定義,一直到今天為止,已經有15個版本了,Why? 原因是因為雲端運算的定義隨著時間的遷移、人的思考和市場的發展而變化。所以未來它還會繼續演進的。話是這樣說沒錯,但每當它一有趨於穩定的狀態出現,我們還是會再試著為它在下一個變化的到來之前作好定義的。

那! 個人雲端運算又怎麼定義呢?!  很有趣的是,這一點每個人好像都不會有太多的迷惑,因為我身上要帶幾顆 CPU這是我自己可以決定的,跟別人都沒有太多的關係,只要經濟上許可,多帶幾隻手機、iPad又何妨。而這其中最在意的恐怕是管理者了,那就是國家的管理者、公司組織的管理者。原因是個人的雲端素養除了個人以外,影響最大的恐怕是他對雲端服務的經營管理的觀念了,這一點尤其對IT部門來說更是如此,真是有趣的很。針對幾個實施雲端運算的要素: 資料(information) 、服務(service)、流程(process)、治理(management)。個人運算恐怕對【治理】這一環影響最大了(想要有效率的治理IT的雲端化,人仍然是最棘手的一環了)。

因此;組織企業絕對不能不重視個人雲端運算的重要性,這一點和教育對未來的影響息息相關。家長們應該開始擔心的不只是孩子們眼睛度數會再一直加深下去或是手機的電磁波會對身體健康產生多大的損傷,而應該正視的是如何教育孩子們正確的吸收多得不能再多的資訊。請注意: 資料的搜尋、收集及有效率的運用,將是決定他未來人生的一大因素。回過頭來想一想,還真是可怕,說它是一場沒有流血的資訊革命,還真不為過。

個人雲端運算應該如何呢?

追求卓越,善用資料, 並盡力提升個人的效率。

 

【企業該從哪裡進入雲端運算?】

回顧2005 年微軟開始推行"服務導向架構" SOA以來,每一步幾乎都指向構建雲端運算而來,WCF web service 用來處理有安全性考量的資料傳輸,Odata 用來處理有效率的傳輸,

我們拿一張SOA meta-model(The Linthicum Group, 2007)的 架構圖示來看,較之雲端上總是只畫上幾朵雲是不是要明確而容易理解多了。(參考: http://en.wikipedia.org/wiki/Service-oriented_architecture )

因此,建議企業應以企業再造的精神,配合敏捷理論 agile 的務實態度,從實踐服務導向SOA的方法開始做起。



Written by ruddyllee

2011 年 02 月 18 日 at 16:02:50

張貼於未分類

Tagged with ,

談如何看名片? 名片學?

with one comment

這是我經常被問到的一個擾人話題,只是因為手頭剛好有一些相關的資料,所以每回被問到時,
都要影印一份或是在電話上或Email裡談上好久,久而久之在別人的眼裡,
就樹立了自己對【看名片】或應該說是詮釋名片的佈局,好像很懂的樣子,其實這一切都是僅供參考的…
(我想那些問問題的人士,大部分人也都是這麼認為的吧),
但在這裡我還是把資料整理了一下,以類似OpenSource的方式公佈出來,
只是希望提供給大家多一個茶餘飯後的話題(千萬不要太把它當一回事了…)。

每一個人都有姓名,因而孕育了『姓名學』,而在職場裡每一個人都有名片,用來代表他在公司裡所負責的職務,
甚至對外代表公司進行交涉談判的事務。因此我們是不是能夠從名片中再多獲得一些相關的資訊就成了有趣的議題了。
.

───────────────────

我慣用的鑑定技巧:

───────────────────
名片加了外框: 表示行動受阻礙,思考不靈活,財務守不住,銷售難開展, 容易有先入為主的觀念,容易陷入困境。

名片加了線條: 表示健康易起變,信用易受懷疑,業績無起色,收入跟著低,
升遷不易,無法聚財,財留不住,心境空虛。 (對大公司而言這一點比較沒關係)

名片加了相片: 表示意志力不佳,財富較守不住,家庭事務多,宜廣結善緣。

有底文背景型: 運勢易遭滯,財運易變弱,名氣揚不大,人事紛爭多且不易擺平。 加背景可以,但要和工作有關才好。

汙損易不潔型: 信用被破壞,計畫形不成,運氣不順利,口舌之禍多。

再加工型: 人際關係大,人員流動大,信心被削減,聲名被人欺,好比在名片上打了個洞。例如:橫向與縱向同時都有。

編排不一型: 錢財占下風,向上空間少,格局無開展,能力不易顯。 例如:橫向與縱向同時都有。

資料不全型: 缺少貴人幫忙,名聲遭人損,事倍功半累,錢財辛苦賺。

頭銜過多型: 打拚力量少,人情世故多,財況易借貸,朋友虛假多, 若財務多,易沉淪聲色中。

有二人以上姓名: 雙人意見多,計畫執行差,個人魅力少,錢財不復多, 行銷不如預期。

當簽約單行: 做事意被動,作業意疏失,財源意流失,感情根基少, 不易接受委託。

加護貝型: 能力被限制,財源不廣進,運勢被封鎖,貴人少又少, 一團死氣。

退色不清晰: 健康無起色,錢財不出現,個性變急躁,運勢受阻礙。

加色塊型: 授信遭懷疑,處事失信心,業務滯礙多,管理難又難。

雙折或多折型: 個性易虛榮,錢財節枝多,工作動力簡,信用部看好。

電腦輸出型: 銷售不順暢,人際關係難,處事態度差,錢財運勢短。
.
───────────────────

幾個重要的地方:

姓名不要在正中間點: 代表工作非常繁重。
.
姓名不要在公司名稱的上面: 代表天地人格位置不正,易遭老闆猜忌。
.
名片中若有橫線是為挫折線,盡量不要用。若有直線則為貴人線,可用。
.
名片要有 天(公司名),人(人名),地(地址)
.
───────────────────

. 如果還需要更深入的話,就要透過姓名的筆畫及生辰八字,
. 來判斷吉凶的方位 然後再看格局了。

Written by ruddyllee

2011 年 02 月 03 日 at 13:54:17

張貼於未分類

Tagged with