現在終於開始炒Hybrid Cloud的梗了

圖片來源：Hybrid Cloud Tips and Best Practices

最近Gmail 常常收到DIGITIMES寄來的一堆研討會資料，發現一個有趣的現象，業界終於開始炒Hybrid Cloud (混和雲) 的梗了，前一陣子DIGITIMES中文網舉辦了 DAF 2013 邁向混合雲之路論壇，然後這幾天陸續把文章上架，下面是DIGITIMES 的文章：

• 邁向混合雲 展現雲端效益
• 開放的混合雲／社群雲平台
• 活用IaaS、Saas　混合雲之路並不遠
• 公私雲各有缺憾 混合雲成理想選項
• 大企業vs.中小企業　誰適合混合雲？

但是老實說我覺得講的議題離我心目中(或是國外真的在討論)的Hybrid Cloud還是差很遠，首先所謂的Hybrid Cloud也許應該正名為Hybrid IaaS? 再者在台灣我覺得發展混和雲的選擇不多局限性很大，因為Public Cloud除了AWS 外就沒有其他選擇了(Hicloud? 請先Open API再說吧)，至於私有雲目前也都還僅止於虛擬化的解決方案，也都還沒聽說有太多企業真的開始導入CloudStack 或是 OpenStack，大都處於觀望的態度....更遑論要混搭使用~


不過最近實在太忙碌了，不然應該靜下來好好想想 Hybrid Cloud 還有什麼梗是適合玩的?

cloudstack 與 openstack 目前的發展趨勢

圖片來源：Kiwi He (殊途同歸)

最近參加許多研討會，或是在網路上的論壇，最常聽到的就是在詢問Openstack 與 CloudStack的比較與差異，網路上也有許多文章從各種角度去比較各個Open Source IaaS平台之間得差異，有的從功能面，有的從參與的廠商數，有的從社群的活躍度(Mail list 討論量，Bug Report量，Release 的速度，甚至活動的參與人數)，舉例圖片如下：

 圖片來源：婉兮清扬 [3]

就我的觀察，目前Open Source IaaS 的兩大陣營 CloudStack 與 OpenStack，是分別從不同的設計理念出發，但是最終的目標就是希望能迎頭趕上Amazon ，成為像AWS一樣的Public Cloud。目前這兩個IaaS的所處位置就如圖下圖所示：

圖片來源：opennebula

OpenStack

從社群面來說：

OpenStack 去年呈現爆炸性的成長(參與人數)，有許多大廠都跳進來搖旗吶喊，從正面的角度來看社群欣欣向榮，有這麼多大廠人力和財力的支持，發展起來一定很威，但是從反面角度思考，畢竟各家廠商都還是有商業利益考量，所以針對規格和發展方向就會進行拉扯與角力，這一點讓人隱憂。

從架構面來說：

此外OpenStack 的設計理念從一開始就是為了超大型的IaaS 架構在設計，所以所有的元件(Service) 一開始就是以分散式的架構在開發，每個Service 都可以獨立運作，也是由個社群團隊獨立開發，優點是如果整合的好的話，對於將來Scale out 整個系統會非常方便，但是目前的狀況卻似乎不是這樣，每個Service 的開發與整合感覺沒有那麼同步，所以不管在安裝上與整合上都有一定的門檻。不過隨著時間的演進這個問題應該會慢慢的解決。

從語言面來說：

OpenStack 主要是以Python 來開發，這部份我就不多評論，因為我跟pythone不熟~:P


CloudStack 

從社群面來說：

CloudStack 最早其實是Cloud.com所以開發的軟體，後來被Cirtix 所併購，所以這個產品一開始就算是一個成熟的產品，直到2012年Citrix 把 CloudStack 以Apache 的License 的方式捐獻出去，整個社群就開始蓬勃發展，這次去參加ApacheCon 2013 就有超過11個Session 就是跟CloudStack有關。

從架構面來說：

就我的觀察CloudStack的設計理念反而是從Private Cloud走向Public Cloud 架構，也就是CloudStack 在一開始開發時，主要是以管理較小的機房架構(Private Cloud)為主，所以不管在安裝的容易度上，和產品的整合度上都非常成熟，在這邊分別把我覺得不錯的優點和特色一一舉出：

1. 出色直覺化的UI

 最讓我覺得驚訝的就是建立Virtual Machine 的畫面，跟我之前開發MechCloud的想法一模一樣，利用圖像化直覺的設計，讓使用者很清楚他現在在做什麼，以及到哪個步驟了，下面第一張圖是當初MechCloud一開始的設計，第二張圖示Cloudstack的設計，是不是很像。

再來談談Architecute，下圖是Cloudstack的Architecture階層圖，管理階層是從Zone，Pod，Cluster，Host，到VM。直接看到這張架構圖應該是很好理解，但是如果在安裝與設定時要怎麼對應成這張圖呢？

Cloudstack 直接把上面階層的概念做成UI，讓你由圖片可以很清楚的了解整個Deploy 架構和網路設定

 2.支援多種網路架構(主要由Basic Mode and Advanced Mode去組合變化)

IaaS裡面最複雜的一部分就是網路規劃，以及Vlan的設定，CloudStack 同樣也是透過圖形化的方式讓管理者很容易去設定和了解網路的架構，下圖分別是Basic mode 和 Advanced Mode的畫面。

 詳情請參考：

• CloudStack Advanced Mode Step by Step
• Understanding Cloudstack's physical network architecture

3.歡迎各家廠商加入的Plugin-in 架構

這部份算是CloudStack最受歡迎的部份，這次參加ApacheCon 2013 裡面就有人提到OpenStack和CloudStack在這方便最大的差別：

Open source Community Leadership Drives Enterprise Grade innovation.Cloudstack's plug-in model permit enterprise-grade adapters.

Cloustack的理念是這樣，企業在尋找的是可以更客製化的Iaas環境，但是如果要客製化Iaas，必須先了解整個cloustack或是openstack實在是太困難，所以cloudstack 允許企業可以從 plug-in or adapter的架構切入，讓企業可以直接針對自己的需求與所需要支援的硬體去開發plugin，不用受限於社群的審查和投票流程，因為傳統在社群上要開發新Feature必須經過以下流程：

• 在Maillist 宣布，讓大家都能知道，是否能接受
• 公開Function Spec & Design
• JIRA ticket for feature
• Setup a Dev Environment
• Branch on github use your own (publich) branch
• Submit changes to Review board
• Post-reviw for large package of changes
• Decide on the wiki you want

所以Plugin 的架構可以讓企業在開發上增加彈性，不論是要直接捐獻給社群，或是沒有捐獻給社群直接拿來獲利都是可以。


4. 使用Java 開發

好啦，這其實是我的私心，因為Java比較熟，所以從Cloudstack切入會比較容易，不管是要改寫,patch 或是寫plugin都非常方便。


最後，就如同我說的cloudstack一開始就是從Private cloud的角度去開發，所以之前的架構是把所有servie 都綁在一起 ，如果要比較大規模的佈署時(類似AWS)可能就會遇到Scale 的問題，因此cloudstack社群也有注意到這個問題，在 4.1 已經開始在把系統架構重構(代號Javelin)，目的是要把架構變成Loosely-coupled component oriented distributed architecture。

結論：

青菜蘿蔔個有所愛，所以也不能因為我比較喜歡cloudstack就說openstack不好，一切還是要回歸企業的應用與需求為主，上面所寫的只是希望可以給各位在選擇解決方案時能有所參考。



延伸閱讀：
[1] CloudStack 與 OpenStack 誰將稱王
[2] OpenStack vs CloudStack: The Latest Score
[3] CY12-Q4 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack

視覺化雲端部屬與管理平台 - madeiracloud

圖片來源：網路

故事是這樣開始的，前幾天突然Twitter寄信通知我有個叫做MederiaCloud的網站帳號要Follow我，話說雖然我有Twitter帳號，但是還真的蠻少在用，也沒有什麼留言，所以怎麼莫名會有人要加我呢？(所以這似乎也是一種反向連結的行銷手法嘛?XD 不過真好奇它是怎麼選定下手目標?:P)

於是我就很好奇的連過去看，不看則以，一看真的馬上就引起我極大的興趣，一開始我還以為只是畫架構圖的設計工具，但是居然遠遠超乎我的期待，因為這個網站把之前MeshCloud最想做的功能做出來了，就是以圖型化的方式來展現軟體架構。當初在設計Group的時候其實就是想要做成類類似的功能，讓使用者可以以System Architecture的方式來部屬與管理系統，而不是用死板的表單和代碼，用頭腦去想像系統架構是怎樣。

不過當初礙於時間以及UI的技術所以一直沒有做出來，但是MederiaCloud解決了這個難題，因為他用Flash/Flex來達到這種圖型化的呈現效果，下圖就是我立馬跑去註冊，開始玩起它的系統。下圖一看就很有fu吧，就是我在前端先設定了一個LoadBalance，然後後面接了兩個Instance，然後每個Instance各掛載一顆硬碟。雖然還有許多的系統架構可能還無法呈現，但是我覺得能做到這樣就要拍拍手鼓勵了！！

在玩過他們的系統之後，我就開始研究他們的團隊，結果更是讓我驚訝！！這是一個大陸團隊，還在大陸參加過創業比賽得獎！！ 看了一下他們團隊介紹除了CEO是英國人外，其他的都是大陸人，而且目前總共才四五個人耶~~更是令人感到敬佩啊!! (話說我們當初也是只有三四個人~Orz...)

而且我還蠻歡它的畫風，和UI設計的，大家有興趣可以去試用看看。

不過最後他們還是會遇到一個問題，就是你會願意花多少錢去使用這樣的服務，去管理你現有的AWS呢?

公有雲？私有雲？爭什麼爭~泡了他做撒尿牛雲吧~XD

延續 "與巨人搏鬥或是站在巨人的肩膀上? Hybrid Cloud"與"先別想私有雲，先試試看公有雲吧！"的議題，其實我最想說的就是"爭什麼爭，泡了他做撒尿牛丸吧，笨!" (想用這個梗很久了XD)。

Public Cloud 和Private Cloud 其實都各有各的市場與優勢，也有都有其適用的情境，如何取其優點混搭使用才是應該關注的焦點，而且老實說除了像是Google、Facebook 那種等級的公司，可以自己蓋DataCenter ，才有資格談所謂的私有雲，不然坊間一般所稱的私有雲充其量就只是一兩個機櫃比較高級的 VPS (Virtual Private Server)罷了，不過光是這樣的改變的確就已經可以幫公司節省許多成本和帶來許多便利性。但是光是這樣也還是有其侷限性在，所以我依舊覺得如何善用公有雲的資源來達到 Hybrid Cloud 才是未來的趨勢。

當然不只我這樣覺得，CIO 雜誌也有許多篇文章有這種看法，讓我節錄其中幾篇：

Forget Public Cloud or Private Cloud, It's All About Hyper-Hybrid

"Speed to solution through rapid, low-risk implementation can be a benefit of cloud computing: get ready to think big, start small, fail fast and scale soon. The path to hyper-hybrid will likely lead to custom extensions of initial cloud services, increased interfaces to core back-office systems and data, and the pursuit of SaaS application capability cloud offerings." 

既然知道了Hybrid Cloud 的好處，那應該要怎麼規劃呢？有興趣的可以參考一下這篇文章How to Plan Now for Hybrid Cloud Management 裡面提供了提供了幾個情境讓大家可以參考：
Scenario 1: Virtualization Platforms Become The Core
Scenario 2: System Management Suites Extend To Cloud
Scenario 3: Third-Party Cloud Tools Excel In Specific Areas.

其實關於Hybrid Cloud這點Amazon早就有預留伏筆摟，就是VPC (Virtual Private Cloud)

 圖片來源：自行整理

參考上圖，VPC 其實的用意就是企業可以把一些比較沒有安全考量的系統，放到AWS上面，但是透過VPC的設定，雖然機器放在public cloud，但是外人無法連到也無法觸碰，所以對於企業來說仍然可以視為安全的內網環境，這樣其實就是某種程度的混和雲架構。

有機會的話再另外寫一篇來介紹AWS Virtual Private Cloud。

MeshCloud - Value and Feature

在上一篇文章- Business Model Generation - 9 key factor有提到，在規劃一個Business Model時應該先問自己九個問題，不過在規劃初期，我通常都是以下面這兩點開始切入：

• 作市場區隔，你的目標客戶是誰？ (Customer Segments)
• 你的服務能為你的客戶產生什麼價值？ (Value Propositions)

首先我們先定義我們可能的目標族群：

• 已經在用或是打算導入AWS的公司
• 網路的創業家

再來就是所謂的價值主張，我們的系統能提供怎樣的價值給客戶？
首先我們思考平時在使用AWS時有遇到什麼問題，或覺得不順的地方，有沒有什麼是可以改善的，以能解決自己的問題為出發點來思考，這也是 37signals的準則" Eats its own dog food" ，如果做出來的東西都不能幫助自己，那又怎麼會幫助到客戶呢，下面就是我們發想的情境，以及想要解決的問題。

透過單一的介面讓使用者可以同時操作多家的IaaS Provider

前面幾篇文章有提到，我們最初的目的是要打造自己的IaaS (這是一開始想要提供給客戶的價值)，但是在我們的IaaS開發好前，我們能提供什麼價值呢？於是我們開始思考如何讓MeshCloud這個管理介面本身就是一個能提供價值的產品，後來就演化出Hybrid Cloud的方向，讓客戶同時可以操作多加的IaaS 不管是Amazon、Rackspace、思昉的IaaS...等，客戶不用再各個介面切換，甚至還可以比較各家的花費，作資源調控。

提供行動化的管理介面 

身為一個網站或是系統維護人員，最怕的就是半夜或在外面的時候(甚至身處在機房時)，系統出狀況(流量暴增要加機器、有機器掛掉...等)，如果這時候只要用ipad ，不管我在哪裡只要有網路，我就可以監控與管理我的機器，就像blog一開始貼的那張圖，我可以躺在床上就可以操作，不用再開電腦。那有些人可能會覺得那直接開broswer連到AWS的managment console不就好，但是那個介面對於mobile device 真的不太友善，也不好操作，不過如果要做成App的形式，那就真的是一個大工程，所以折衷的方法就是做成mobile web的方式。

圖型視覺化的Dashboard

Amazon 的使用介面老實說對於一般使用者來說太複雜了，而且我想要一眼就知道我每台主機的資源使用狀況，到底有哪幾台已經接近滿載該要注意，有哪幾台主機使用量一直都很低可以把它暫時關閉 (CloudWatch 只有針對個別Instance設定alarm)。關於這裡可以參考我同事寫的 Into the MeshCloud Part I.。

群組化管理Instance

我們所設計的群組有兩種用意：

1. 方便監控與管理

我們可以依據我們要觀察的面相來設計群組，比如說我想要知道到底系統瓶頸和資源耗費最多的是在Web Server 還是資料庫，那我就可以分別建立Web Server和資料庫群組，然後看看哪個群組的花費最多，或是最常處於滿載的狀況，這樣一來就可以知道應該是要在哪個群組增加資源。以現在最熱門的Line 的系統架構來舉例，要配置這麼多Server ，如果你不用群組的概念來管理，相信一定會看的眼花撩亂，到底問題是出再app Server，還是Storage的部份，還是在Redis cluster的部份呢？到底哪個群組最耗資源，哪個群組已經快要過載了？

2. Service template的概念

今天如果要管理一套系統，簡單的以CRM來說，可能就包含一個Web Server，一個app Server，然後一個Database，由這三個就可以組合成一套CRM 的系統，這三台伺服器所組成的Group就代表是一個"服務"，透過這個群組我們可以直接觀察這一個"服務"的運作狀況，也可以直接複製一套這個"服務"，這就是我所謂Template的概念。

花費預估

畢竟Amazon 沒有開放Billing的API，所以我們只能透過使用量，以及Amazon 提供計費的準則，來幫助使用者更即時的了解目前花費，以及透過上面群組的搭配，可以知道哪些服務可能最花錢。

系統診斷分析

現階段只有顯示目前的系統的異常資訊，以及操作記錄，但是我們的目標是要做到系統診斷與分析，主要會有兩個面相的分析：

1. 系統效益分析

這個功能會幫你監控你的系統並且提醒你是否有資源浪費，比如說你有allocate 一個 Elastic IP卻都沒使用，你有新增了一個volume 卻沒有掛載，或者是一的volume 沒有定期作snapshot 與備份...等問題。

2. 系統安全分析

這個功能簡單來說就是會做一些基本的弱點掃描，比如說你的Instance 是否有設定Security Group，網頁伺服器是否有放在Load balance 後面，一些常見的port 是否有關閉...等問題。



其實真的越作下去，會發現越來越多可以做的東西，但是最後還是要回歸到，這些功能對於使用者來說到底算不算價值，到底使用者願不願意花錢購買這些服務。我們誠摯的希望各位能來試用我們的系統 - MeshCloud，或是針對上面的內容給予我們意見回饋，讓我們可以位各位提供更有價值的功能與服務。

-------------------------
歡迎加入Cloud Lab 粉絲頁

MeshCloud Beta 測試邀請

我在這邊很高興的宣布 MeshCloud Beta 終於可以見人了，接下來我們會進行為期約一個月的封測，有興趣的Amazon使用者，歡迎來申請測試帳號。如果方便的話，我們希望可以邀請您到敝公司來實地操作，我們也有專人為您解說功能和如何操作，我們會聆聽你們的寶貴意見及箴言，再次感謝你們的協助測試。

怎樣的使用者可能會有興趣參與我們的測試？

• 還沒有AWS 帳號，但是想要把系統移到IaaS上的使用者 (我們可以協助您申請) 
• 已經擁有Amazon 帳號的使用者
• 已經擁有Amazon 帳號，希望能在iPad上操作管理你的IaaS
• 已經擁有Amazon 帳號，希望能以圖像化更直覺管理和監控你的系統
• 已經擁有Amazon 帳號，希望系統能提醒你是否有忘了釋放的資源
• 已經擁有Amazon 帳號，但是更希望可以同時控管其他IaaS帳號 (如Rackspace)

我們誠摯的邀請你來測試，請現在就在連到以下網址：

Https://meshcloud.meshmit.com

我們更誠摯的邀請你來到我們公司，坐下來喝杯咖啡，讓我們為你解說該如何操作。

現在就寄信與我們聯絡 Service@meshinnovation.com 

也歡迎加入Facebook 粉絲頁 Cloud Lab

[Update] 公司收起來摟~~~所以服務也收起來摟~XD

與巨人搏鬥或是站在巨人的肩膀上? Hybrid Cloud

要營運一個IaaS 在規劃期間有哪些東西是需要考量與研究的呢？

• 要先決定Data Center 的地點與ISP Provider (價格、穩定度、頻寬...等)
• 要決定所有硬體設備的規格與價性比(Server、Switch、Storage....等)
• 要決定硬體架構，儲存裝置架構(JBOD、RAID、iSCSI、NAS、SAN....等)
• 要決定網路架構 (如何設計一個安全與穩定的網路環境，管理與使用流量分開...等)
• 要決定.....

要決定的事跟要研究的事真的很多(感謝有許多專家顧問的協助~)，但是上面所有的問題都會受到一件事影響，就是公司口袋有多深，有多少資金可以燒？再來就是要思考如何與現有的IaaS大廠匹敵呢? 先不考慮技術問題，單純考量資金，Amazon也是走了好幾年，靠著他們ECommerce賺錢支援和當Reference，才有今天的規模。

不過這不是今天要討論的重點(這都是商業機密?XD)，先撇除掉上面所有的疑慮，既然把Amaozn當做目標和假想敵，所以到底該怎麼挑戰這個巨人呢？戰爭初期(妄想模式...)我們擬定幾個簡單的策略：

• 找出目前Amazon EC2 不足，或是不好操作的地方，並且加以改善
• 為了讓客戶在IPad上就隨時隨地輕易操作，所以做成mobile web的形式
• 降低客戶從Amazon轉移的困難度

為了搶Amazon的客戶，所以必須要建立一個能方便客戶從Amazon移轉過來的環境，所以我們必須提供Amaozn Compatible API，於是我們所有的介面都是Follow Amazon的API，讓使用者可以透過我們的介面，操作Amazon的EC2，也可以操作我們的MeshCloud，於是Hybrid Cloud的概念與雛形就出現了 (這就是傳說中的Pivot 嘛!?) ，其實在這之前我也不知道有Hybrid Cloud這個名詞，是在查資料和研究時偶然發現，原來我們在做的就是Hybrid Cloud。

那到底什麼是Hybrid Cloud呢? 根據IBM的定義[1]，Hybrid Cloud 比較侷限在是私有雲與公有雲的搭配：

A hybrid cloud is the combination of at least one private cloud with at least one public cloud-based infrastructure, producing an environment that provides transparent user access to the hybrid cloud and is capable of dynamic scalability to manage uneven demand.

對我來說，我比較喜歡Wiki的定義，也比較像是我們想要提供的服務架構：

Hybrid cloud is a composition of two or more clouds (private, community or public) that remain unique entities but are bound together, offering the benefits of multiple deployment models.[2]

為什麼會有HybridCloud 的需求呢？就我們的研究與從客戶需求來看就有各種可能的原因：

• 對於企業來說，並不是所有的資料或是Service都適合放到Public cloud，有些東西還是得放在Private Cloud，但是如果有一個統一的管理介面，對於企業來說是最好的。
• Service Provider 想要建立跨區Fail over機制
• 為了速度考量要服務不同地區的客戶要就地設立系統服務
• 不想被單一的IaaS provider綁死

越是深入研究，越是發現Hybrid cloud一定會是將來的趨勢，在國外也有越來越多這類的公司崛起(如 RightScale、Egnyte)，而且與其正面與巨人對決，還不如避其鋒，在初期先利用巨人的力量，在巨人的肩膀上去發展出對客戶有價值，等到有一定的規模和財力在來思考後續的發展。(遠目~)

於是乎我們又重新擬定了我們的Roadmap：

第一階段：

讓使用者，透過一個共通且易用的的使用者介面，可以同時操控多個IaaS 平台

第二階段：

提供智慧型與圖像化的監控分析功能，讓使用者可以有效的管理所擁有的IaaS，並且希望可以幫助客戶省錢，提高使用率。


第三階段：

提供跨IaaS 管理與備援的功能，比如說你想要設定Fail over between AWS  Rackspace，或是要把公司的Private Cloud資料備份到 Public Cloud

以下的影片就是CloudPro 對 Hybrid Cloud的介紹：

References

1. Inside the hybrid cloud. 2012
2. "The NIST Definition of Cloud Computing". National Institute of Science and Technology. Retrieved 24 July 2011.