Cloud Computing Strategy 雲端運算策略

雲端運算(Cloud Computing)在2009年是一個熱門的話題，但對於我或是一些人來說，真的實在無法清楚明確定義何謂「雲端運算」，今天介紹這本書「雲端策略：雲端運算與虛擬化技術(Cloud Computing Strategy)」，作者們是：陳瀅、王慶波、金涬(ㄒㄧㄥˋ)、趙陽、何樂、鄒志樂、吳玉會、楊林。

陳瀅著，雲端策略，台北：天下文化，2010。

這本書的內容正如其名，前半部分(1~4章)介紹雲端運算，後半部分(5~7章)介紹虛擬化技術，雲端運算仰賴虛擬化、自動化、標準化三項核心技術的技術基礎是虛擬化(virtualization)，沒有虛擬化可說是很難實現雲端運算的目標(可以不需要虛擬化技術)。書籍架構如下：

• 第一章 雲端運算概論
• 第二章 迎向智慧新生活──雲端產業創新
• 第三章 雲端架構
• 第四章 雲端運算的關鍵技術與挑戰
• 第五章 虛擬化概論
• 第六章 虛擬化的關鍵技術
• 第七章 虛擬化的業界動態
• 第八章 業界動態

雲端運算的理念是將計算與儲存簡化成像公共水電一樣便利的資源，用戶只要藉由網路就可以方便使用，依據用量付費。雲端運算的最大意義在於商業模式的創新，提供運算服務如水電一般讓用戶使用，不同於其他運算模式(Cluster Computing、Distributed Computing、Grid Computing)。

雲端運算的特徵此書中提出四點：

1. 硬體和軟體都是資源(在雲端)，透過網路以服務的方式提供給使用者。
2. 資源可以根據需要進行動態擴展和配置。
3. 資源(軟硬體)以分散式的共用方式存在，最後以單一整體的形式呈現(給使用者)。
4. 用戶依照需求使用雲中的資源，按照實際使用量付費，不需要負擔管理的責任。

我們從不同觀點看雲端運算，依據服務類型則分成三種：

1. 基礎設施雲(Infrastructure Cloud)：以Amazon EC2為代表，靈活度最高，需要開發應用程式服務，使用者運用操作較困難。
2. 平台雲(Platform Cloud)：以Google App Engine為代表。
3. 應用雲(Application Cloud)：以Salesforce.com為代表，靈活度最低，直接提供特定服務，使用者運用操作最簡單。

再從另一個觀點來看，依據服務方式則分成三種：

1. 公有雲：「雲端的服務」是由雲端供應商提供。
2. 私有雲：企業或組織獨立建置使用的雲端運算環境。
3. 混合雲：公有雲和私有雲的混合。

敘述了這們多資訊，這也只是「第一章 雲端運算概論」的內容而已，若各位想清楚瞭解何謂「雲端運算」，這本書的確說得夠清楚有系統！

最後談談，雲端運算的優勢有哪些？書上提到這五點：優化產業布局、推進專業分工、提升資源利用率、減少初期投資、降低管理開銷。

###

Karajan Forever

趁著前些日子累積下來的購物金，買了一張卡拉揚的CD，這張是「永遠的卡拉揚(Karajan Forever: The Greatest Classical Hits)」，價格是NTS429包含2CD共29首，可說是低價版的入門選擇，CD是歐洲製造(Made in the E.U.)，內容細節請看CD專屬網站。

雖然錄音是1970至1980年代的產物，但是聽起來卻有高質感(或許經過處理)，有點像是影片FullHD的感受。封面個人認為是Herbert von Karajan很帥的一張相片！

###

Zend Framework 禪 框架

最近開始使用「Zend Framework」開發一個系統，起初搜尋Zend Framework關鍵字時發現：它的架構非常複雜...，看到這不免令人擔憂，爾後我更進一步研究認為這問題應該還好，因為官方文件寫的頗為詳盡！缺點是中文參考書籍與資料較為匱乏(問題不大)。

目前學習「Zend Framework」的心得是不困難，前提是你必須擁有Django或是Ruby on Rail的開發經驗，大致上這類Web Application框架的使用觀念相同，我認為「Zend Framework」設計非常詳盡，元件數量相當多但權責劃分清楚，推薦大家放心用來開發(有前提啊)。

「Zend Framework」的元件分成8類：

• Model-View-Controller (MVC)
• Tooling and Rapid Application Development (RAD)
• Database
• Internationalization (i18n) and Localization (l10n)
• Authentication, Authorization, and Session management
• Web and Web Services
• Mail, Formats, and Search
• Core Infrastructure

學習上建議先從QuickStart文件開始閱讀，你將可以瞭解MVC架構和熟悉命令工具的操作(zf Command Line Tool)。

###

PHP Debug

記錄PHP除錯心得，通常使用PHP開發網頁應用程式(Web Application)時，為了看到變數的值，我們會使用echo和print(陣列用print_r)把值丟到網頁上查看，這是一個爛方法！

使用PHP這麼久，最近為了開發更複雜大型的應用程式，開始尋找有沒有好的除錯方式，最好像是Visual Studio的方式，可以單步執行、設定中斷點的方法。

方法是必須安裝Xdebug或是Zend Debugger(Studio Web Debugger)，並且需要設定php.ini組態檔，爾後還需要Eclipse(外掛PDT)設定Debug Configuration，稍微複雜但可以正常運作喔！Eclipse的設定沒有什麼大問題，倒是debug元件安裝比較有疑問(安裝說明不清楚)，以下為安裝步驟記錄。

Xdebug的安裝是：

1. 下載php_xdebug-2.1.0-5.3-vc6.dll複製到php\ext之下
2. php.ini設定檔加入下列指令，絕對路徑才可以動。指令請參考http://www.php.net/manual/en/ini.list.php

zend_extension="C:\php\ext\php_xdebug-2.1.0-5.3-vc6.dll"
xdebug.remote_enable=true
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_enable=1

Zend Debugger的安裝是：

1. 下載ZendDebugger.dll複製到php\ext之下
2. 複製 dummy.php到網站根目錄下(document root directory)
3. php.ini設定檔加入下列指令，絕對路徑才可以動。

zend_extension_ts="C:\php\ext\ZendDebugger.dll"
zend_debugger.allow_hosts=127.0.0.1
zend_debugger.expose_remotely=always

記得最後重新啟動Apache網頁伺服器，重新載入PHP直譯器，接著去設定Eclipse玩玩吧！
###

View

2011年2月25日重新配了一副新的眼鏡，今天配戴後有一些心得。鏡架我一直選擇 Dr. Swan這個牌子，而鏡片的部分則改用ASAHI-LITE(朝日光學)的非球面鏡片，全部加起來讓我花了不少小朋友。我對眼鏡有更進一步的了解來自於「韋在兄」，他是一位特別的人！他對於眼鏡可以說出一連串的故事，例如鏡架是什麼人所設計和背後的故事、鏡片的差異有哪些...等，此外，對於古典樂、文學、品酒等等的一些「趣事(對我而有是相當有趣的事情)」他都很了解。

眼鏡，對我而言，就像是敲門磚，把我推向另一扇窗，讓我有機會看到窗外的世界，認識到各種人生的可能性。我相信任何人對於一件事情，如果可以深入瞭解，這就會是一個敲門磚。

眼鏡是消耗品。這次想換眼鏡是鏡片發生脫膜(多層膜鍍膜掉落)，加上鏡片用久三年已經變黃(為什麼會變黃)，看起東西來清晰度、舒適度不佳，變成不得不替換鏡片。如果依照這個情形下去，每三年左右就必須更換鏡片，那麼眼鏡就會是消耗品！靜下來看看四周，每個人使用的東西都是一種消耗品，手機、房子、車子、知識...等，差別只在於時間消耗的長短，不是嗎？

在我開始瞭解眼鏡之後，我才真正開始研究球面、非球面、雙非球面的結構差異，而且材質有折射率1.5、1.6、1.67...等的區別，折射率也影響厚度，鏡片的製造商也有他們各自的強項特點，不過可惜這方面的資訊(書籍)不多。

換了眼鏡之後，物體的顏色和清晰度明顯提高，豁然開朗。從另一個角度來說，假設我的眼睛沒有變差，隨時間增加我看東西的品質越來越差，只因為我戴的眼鏡的關係，這會不會讓我誤以為某些東西品質不好？好比區分不出Full HD的螢幕與一般CRT螢幕的差異，太可怕了！只因為自己慢慢習慣鏡片的磨損與老化。

如果你是戴眼鏡的一群，適時的替換有其必要性！
###

Solve

記錄有關於解決問題的方法，這是三年前教導別人的心得。

生活中常常會遇到很多新問題(解答不在自己既有的經驗中)，這些問題對於青年學生(引用李開復先生常說的青年學生)而言往往不知所措，可是沒有人告訴(或教育)他們應該怎麼辦，好似出生就應該會的本領！

我一直認為，一定要告訴青年學生如何解決問題，這個問題就像如何讀書、如何考試一樣重要。中國的文化長久以來就是要求青年學生讀書考試，可是卻沒有去教育他們，讀書考試是有方法的、有技巧的、有策略的。再把層次往上提高，讀書可說是解決問題的一個方法之一，這個解決問題的方法非常重要，足以影響一個人的一生，可是(我的記憶中)卻沒有人告訴教導我們。

解決問題的方法的方法大概有下列幾個：

1.「問人」，這大概是每個人出生就會的，而且使用最頻繁的方法。但要問什麼人？小時後問父母長輩，學生時期問老師，青年時問同伴，出社會後什麼人都問了！這個方法需要良好的人際關係技巧，也就是人脈的重要性。

2.「找資料」，找了資料就是要看懂才有用，讀書大概就屬於這方面的技巧。要如何看懂又是另一個問題，我們可以利用前一個「問人」的方法來解決，或是找更多資料，資料中總會有比較容易看懂得部分，我們要從這一點切入。那麼，要去哪找資料？以前大概只能從書籍紙本上著手，現在可以從網際網路上搜尋，所以搜尋的技巧很重要，資料如同人脈一樣廣度必須要夠廣，換句話說，我們不能侷限於單一語言的限制！

3.「自己嘗試」，如果前述第一、二方法無效要怎麼辦，研究生大概會遇到這類問題，做沒有人做過的研究，新的領域沒有參考資料，這時候就屬「嘗試中學習」可以找出解答了，我不太想用Try & Error(Trial by error)這個字眼，因為Try & Error需要知道哪裡錯誤，爾後才有可能將利用刪除法找出解答，可是有數人多半是亂Try...。我認為需要自我對話的能力，否則無法「自我嘗試」。

4.「花錢」，花錢也是方法之一，重點在於口袋要夠帶夠深，俗話說：花錢可以解決的問題都不是問題。

5.「創新解決」，像是牛頓被蘋果打到的方法，榨乾腦袋想出任何可能的辦法，如Post上網、請求中研院協助、等待奇蹟、冥想...等。

希望此文可以幫助青年學生
###

Start

看看自己的Confession這篇文章，我到底想寫什麼呢？唯一的意義在於自己高興，花了近60分鐘左右，寫了958個字(使用Microsoft Word計算)，越看越不知道我的文章有什麼結論！

似乎寫部落格就是在抒發一種心情、記錄當下的感覺。當時，只感覺到很多想法在腦中一閃而過，閱讀的記憶與當下的念頭就馬上交織成為Confession這篇文章，算是抒情與記述文吧！

對於未來撰寫部落格的方向，我決定採取下列行動：

1.
字數限制在560字左右，自認為大概可以撰寫一篇短文的字數。千字以上太花時間培養，目前能力不及。微博的140字(這類的微網誌)又稍嫌過短，不足以心中醞釀的情感如實記錄。560個字能夠以四個140字的段落組成起承轉合的作文，我想也是不錯的方式！

2.
內容會依舊限制在一些閱讀書籍的心得感想，不過，不會以整本書的方式為主題撰寫文章，看書看到哪裡就寫什麼，有什麼想法和感想，我會趁著還很新鮮的時候就馬上撰寫，期望可以封存最初的原汁原味。

目前我會持續朝向這個方向改進。

繼續
###

Confession

經過2009、2010兩年撰寫部落格的經驗，最近，我想從這些回憶中對自己坦白一些事情。主要是近幾個月寫文章的數量越來越少，自己也越來越提不起勁，反省起來發現自己事情太多了，所謂「少則得，多則惑」的道理吧！

2009、2010兩年的期間，買書讀書的數量每個月比每個月多，2010一年平均每個月買書2000元的額度是有達成的！一年花費至少2萬4千元買書。藏書的數目增加近一倍，粗估有三四百本，這個月買的書下個月已經讀不完，確實是該檢討自己。

2010年底曾經覺得必須訂定閱讀計畫！否則如何消化我的藏書？是否為了閱讀計畫又去買書來讀！現在，我讀書的速度與體悟能力絕對有倍增的實力，然而到現在還沒訂定，更別談開始執行。(羞)

2009、2010兩年的期間，往回看看自己的部落格文章，每年大約60篇左右，內容上從一開始亂寫，寫給自己高興的。到後來慢慢針對一本書撰寫心得感想，有些確實是為了撰寫而寫的流水文，希望分享自己閱讀的喜悅與感想，此外，自己也針對技術領域撰寫摘要，記錄自己學習上的心得。

2010年底我卻提不起勁撰寫文章，不是沒有閱讀書籍，也不是沒有研究任何技術。我反省認為需要對自己的習慣與做法有所改善！除了檯面上發布的文章之外，庫藏文章也有30餘篇，多半是寫了一半沒有發佈，因為自己總希望對一個書籍內容或技術領域有完整的瞭解才開始動筆，這個想法好壞參半，好處在於文章可以有架構，循序漸進引人入勝，壞處在於當時收穫的熱度已退，雖有收穫卻不想起步行動。(殘)

光是這篇文章，早在過年初一就想動筆記錄了，我想我必須有所改變！今後只要自己有什麼想法，我就會開始寫下來，也不管有沒有架構，也不在乎完不完整，我告訴自己：「寫就對了！」自己快樂高興就好，不是嗎！

我一直很喜歡伏爾泰(François-Marie Arouet)的這段話：「我做的事情是多麼微不足道，可是我去做的本身，是無比重要。」這是我在閱讀查爾斯‧韓第(Charles Handy)先生的「你拿什麼定義自己」一書中看到的(全文最末段)，隨即觸動我的心底，對阿！個人不就是該如此嗎！

現在，更讓我想起書中的這段(第一章末)：「eBay的創辦人之一史科爾(Jeff Skoll)說，當他父親回家宣布自己被診斷患了末期癌症那天，父親告訴當時十四歲的他，自己並不害怕死亡，卻因為還沒做過這輩子想做的所有事而難過。換句話說，他怕會在親身體驗自己每一個可能面向之前就死去。幸好醫生診斷錯誤，他獲得了另一次機會。我們其他人也許不會這麼幸運。」

開始
###

Component Object Model 元件物件模型

談談元件物件模型(Component Object Model, COM)這個主題吧！前一陣子都在研究 DirectShow，常常看到 COM 這個關鍵字。由於最近才變成 Windows 程式開發人員所以不熟悉 COM，趁此機會好好研究一番吧！

請注意：COM 是一個標準 (Standard，也參照為Binary Standard，定義物件的結構)，不是什麼工匠技藝 (craftsmanship) 的產品，也不是程式語言。COM 標準定義一個物件模型 (Object Model)，使得 COM 物件(也稱為 COM 元件，或簡稱物件)可以和其他的物件互動工作。物件可以位於執行的行程 (process) 中，或其他行程，甚至是遠端電腦。

COM 是一個標準，因此可以使用多種物件導向語言 (Object-Oriented Language) 撰寫開發，通常是用 C++ 撰寫開發比較容易簡單，原因在於 COM 是 Binary Standard ，C++ 撰寫比較可以控制結構。

軟體中的物件包含資料 (data) 和函式 (function) 兩部分，而 COM 僅有(唯一)利用函式的呼叫操作資料(換句話說，沒有資料這部分)，這類函式在 COM 中稱為介面 (interface)，而操作COM介面的函式稱為方法 (method) ，注意這些詞彙很容易讓人混淆，COM 的介面不同於C++的，一定要搞清楚！

更進一步來說，COM 要求這些介面必須是用指標 (pointer) 的方式實現(這是技術上關鍵的地方)，COM 標準也定義一些元件通用的介面(部分介面必須具備，例如 IUnknown 介面)、元件之間的互動與安全性等。總結，COM 標準是定義介面，而介面實現 (interface implementation) 則由程式設計人員編寫。

COM 標準是微軟 OLE(Object Linking and Embedding) 和 ActiveX 技術的基礎，如果要學習這些技術，我們對 COM 的觀念一定要正確建立，以下是我認為 MSDN 上比較重要的觀念(要多讀幾遍)：

• COM Technical Overview
  http://msdn.microsoft.com/en-us/library/ff637359(v=VS.85).aspx
• Component Object Model (COM)
  http://msdn.microsoft.com/en-us/library/ms680573(v=VS.85).aspx
• The Component Object Model (COM)
  http://msdn.microsoft.com/en-us/library/ms694363(v=VS.85).aspx
• Interface Pointers and Interfaces
  http://msdn.microsoft.com/en-us/library/ms688484(v=VS.85).aspx
• COM Clients and Servers
  http://msdn.microsoft.com/en-us/library/ms683835(v=VS.85).aspx
• Processes, Threads, and Apartments
  http://msdn.microsoft.com/en-us/library/ms693344(v=VS.85).aspx

###

Domain Name System網域名稱系統

今天談談網域名稱系統(Domain Name System, DNS)的觀念，記得當初ycwang授課的時候，我自己以為DNS是個簡單的系統，只不過就是把網址(URL)轉換為網際網路協定位址(Internet Protocol Address)的功能而已。

然而這樣的認知大概懂了一成，從這幾年的經歷看來，我對DNS的理論基礎沒有完全搞清楚，我太小看DNS系統了！沒關係，學習就是不斷發現自己的不足，然後趕緊補足遺漏的知識，最怕的是不知道自己缺了什麼。

從網頁應用程式的技術角度來看，URL(Uniform Resource Locator，)可以分成五個部分，以Google我的帳戶的URL為例：

https://www.google.com/accounts/ManageAccount?hl=zh-tw

1. 通訊協定配置名稱(Scheme Name)：即通訊協定，如https或http
2. 主機名稱(Host Name)：指的是www.google.com
3. 連接埠編號(Port Number)：與通訊協定有關，http是80的埠號
4. 路徑名稱(Path Name)：在主機上的資料路徑，這個範例是accounts/ManageAccount
5. 查詢字串(Query String)：http中指的是GET參數，如hl=zh-tw

從DNS的角度來看，DNS所做的是將URL的主機名稱(Hostname)轉換成IP位址(IP Address)，提供「Hostname-to-IP-Address Translation Service」的功能，那麼大費周章的意義有二：

第一，網路上的主機位置是由IP位置判定識別，這是一個32位元的資料(一般以192.168.1.1之類的四段十進位字串表示)，非常不容易讓使用者記憶與識別，所以我們才會需要主機名稱。

第二，主機名稱雖利於人類記憶與識別，但對於網路系統來說會有實現困難，因為主機名稱千百萬種長度不一，非常不利於網路設備(路由器)判斷，效率也不夠好，這也就是為何IP位置要定義32位元的固定長度。

DNS除了上述功能外，還可以有三個用途：

1. 主機別名(Host Aliasing)：如果主機名稱(網址)不好記憶，可以用另一個做為別名。
2. 郵件伺服器別名(Mail Server Aliasing)：與主機別名用途相同，這指的是對於郵件用途。
3. 負載分配(Load Distribution)；利用DNS將同一個主機名稱分配至不同的IP位置。

從系統面來看，DNS網域名稱系統是一個分散式的(Distributed)大系統，並且是具有階層的(hierarchical)資料庫系統，DNS在網路架構上屬於應用層(Application Layer)，底層傳輸層依賴的是UDP通訊協定，使用Port 53的埠號。

值得注意的一點，雖然說DNS屬於應用層，但是應用層之中的HTTP、FTP、SMTP等等應用服務都是依賴於DNS(都會使用到URL)，我們可以說DNS是應用層的基礎設施(infrastructure)也不為過！

DNS伺服器的階層架構可分成三類：

1. Root DNS servers：最上層，全球共13台，分別標示A至M。
2. Top-Level Domain (TLD) servers：第二層，管理網域如com, org, edu, gov或各國的網域位置。
3. Authoritative DNS servers：被TLD授權的DNS，通常是組織自己建置的DNS，管理自己私人的URL。

另外為了效能上的提升，也有建置Local DNS servers與DNS Caching的功能。

以上是DNS大致上的概念，細節部分還真是多啊！千萬不要小看DNS，當你真正使用DNS做一些事情才知道DNS博大精深。其他比較重要的參考資料有：

• RFC 1034(Domain Names - Concepts and Facilities)
• RFC 1035(Domain Names - Implementation and Specification)
• RFC 2136(Dynamic Updates in the Domain Name System (DNS UPDATE))

等等，還有很多有關DNS的RFC，請參考DNS RFC - Domain Name System RFC's (IETF)。

###