馬堤的剪報筆記

天下雜誌  2010/03

林百里說：「我不去藍海，我上雲端。」 這是一場將改變10億人電腦使用習慣的資訊革命，也將影響企業的商業模式！

本週「名人讀書會」推薦天下雜誌出版的新書《雲端策略》，告訴你不可不瞭解的雲端運算科技！

其實， 收發電郵、網路購物、分享影片、線上遊戲……都已是普遍可見的雲端服務應用，除此之外，政府更在2010年初宣佈將『雲端運算』列為四大「新興智慧型產 業」中發展重點。無論你的角色是執行長、財務長、亦或是技術長，面對企業永續營運的課題，你千萬不能輕忽這股「雲端海嘯」。

雲端運算的概念

相較於「分散式運算」或「網格運算」這類技術導向的名詞，「雲端運算」顯得浪漫多了，卻也讓人不易從中推斷它所涵蓋的範疇。許多工程師乍聽到「雲端運算」這四個字時，會感到不知所云，專家和精英們也很難為雲端運算定下一個準確的定義，每個人都有不同的解釋。

以下，試舉出雲端運算的四個代表案例，以此為脈絡，期盼能帶領讀者領略雲中的真實世界。

【案例一】

二○○八年三月十九日上午十點，美國國家檔案館公開了一九九三～二○○一年前第一夫人希拉蕊在白宮的日誌檔案。這些檔案是由新聞記者團體和獨立調查機構，根據美國「資訊自由法案」向國會多次請願才得以公開的，極受社會關注。當時，這些檔案全是無法被檢索、且品質不夠精美的PDF檔，若要轉換成可以檢索、易於瀏覽的文件格式，需要再被處理。

《華盛頓郵報》希望將這些檔案在第一時間上傳到網路，以便公眾查詢，但以報社現有的電腦運算能力， 單頁的操作就費時三十分鐘。於是，《華盛頓郵報》將這個檔案的轉換工程交給Amazon EC2（Elastic Compute Cloud）。Amazon EC2同時使用兩百個虛擬伺服器，每個伺服器的單頁平均處理時間都縮短為一分鐘，在九小時內將所有的檔案轉換完畢，讓《華盛頓郵報》能以最快速度將第一手 資料呈現給讀者。

【案例二】

Giftag是一款在Firefox和IE瀏覽器上的外掛程式。網路用戶在瀏覽網頁，尤其是購物網站時，可以利用該程式將中意的商品加入商品清單中，並與好友分享。這個應用程式一推出，便大受歡迎，每天都要回應數以百萬計使用者的造訪，以及大量資訊的存取。沒多久，伺服器就不堪負荷。後來，Giftag將伺服器遷移到 Google App Engine（GAE）平台，透過開放的API介面，Giftag可以回應尖峰時段的使用者請求，利用Google的分散式資料庫來儲存使用者資料，甚至 以Gmail信箱和Google的搜尋功能來增強用戶體驗。

【案例三】

知名的冰淇淋供應商哈根達斯（Haagen-Dazs），加盟店遍布全球。為此，公司需要一個CRM（客戶關係管理）系統管理所有加盟店。原本，哈根達斯使用Excel表單來管理旗下的加盟店，並以Access資料庫儲存加盟店資料，然而透過虛擬私人網路（VPN）造訪資料庫的效能表現總是不太好，公司急需一個能讓員工協同合作、根據不同的需求進行靈活配置的解決方案。

最後，哈根達斯公司選擇了Salesforce CRM企業版，在不到六個月的時間就上線了。此外，該系統能將Microsoft Outlook和Salesforce CRM相連，使員工能夠輕鬆造訪Outlook中的連絡人列表、日誌和電子郵件。Salesforce.com還為哈根達斯的解決方案提供了員工培訓模組、加盟店追蹤模組，以及新店選址模組。哈根達斯公司用更少的成本獲得了超乎預期的效果。

【案例四】

做為資訊整合的大型跨國企業，IBM在全球擁有八所研究院，彙聚了三千多位頂尖科學家和研究員。每天，都有不計其數的科學實驗在進行，其中有些需要大量的運算資源和儲資支援。雖然每所研究院都配備了先進的IT設備，但仍然滿足不了某些實驗的需求。由於這些研究院分布世界各地，處於不同的時區，使得共同合作科學專案有著執行上的困難。

為了提供研究部門源源不斷的支援，提高各研究院間協同作業的效率，IBM建構了Research Compute Cloud（RC2）將分散在各研究院的資源系統（如伺服器、儲存）整合，供內部使用。該系統為研究人員提供了共用運算、儲存資源的平台，通過任務調度和 安排，為每項科學實驗提供有保障的動態資源。研究人員不需要自己來管理這些資源，隨時可以進行入平台系統查詢和交換資訊。不論是實驗過程中的流程或者最終 的研究結果，都能在該系統中完成和保存，有效確保資料的安全，大大提高了協同科學研究的效率。

在案例一中， 如果沒有Amazon EC2提供的運算能力，《華盛頓郵報》需要花費超過一年的時間才能完成檔案格式的轉換。顯然，這樣的效率不足以滿足公眾對資訊的期盼。透過Amazon EC2平台分散式的運算處理能力，使報社在第一時間完成了檔案的轉換，而僅需支付一百四十四‧六二美元的費用。

在案例二中，Giftag和其他公司一樣，面臨昂貴的資訊基礎建置費用，例如購置伺服器、租用頻寬等。資訊基礎建置的投入往往不易估 量，一旦投入過大而無法達到預期獲利，就會造成投資浪費；反之，如果應用獲得了超乎預期的市場反應，用戶數量大增，可能會給伺服器、頻寬帶來龐大負荷，造 成服務品質下降、客戶流失。再者Web應用需要複雜的軟體配置，包括資料庫、中介軟體、Web伺服器等要素，如果其中一項配置不合理，就會產生連鎖反應， 影響整個軟體程式效能的表現。這些潛在問題都是公司草創時期必須面臨的挑戰。透過GAE平台，Giftag可以把精力集中在開發應用本身，而將伺服器擴 展、資料庫造訪頻繁、負載均衡等問題都交給平台來解決，專注於應用的開發和優化。

在案例三中，哈根達斯要搭建自己的CRM平台，傳統做法是 先聘請一支專業顧問團隊研究公司的業務流程，建模分析並提出諮詢報告，然後再雇用一家IT外包公司進駐進行平台開發。在這段開發期間，需求→設計→實施→ 需求變更→再設計→再實施的模式可能會不斷出現。同時，哈根達斯還需要投資IT設備，例如購買伺服器、交換機、防火牆、各種各樣的軟體，以及租用頻寬等， 為系統上線做準備。在經歷了這些令人筋疲力竭的過程後，系統終於上線了，但是否真的滿足了哈根達斯最初的期望，可能永遠不會有人知道。