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

Business Model Generation - 9 key factor

[Update] 現在博客來有賣中文版了：獲利世代

會看到 Business Model Generation 這本書真的是純屬意外，一開始是看了XDite所寫的文章"The Startup Owner's Manual 讀書心得"，然後就很興奮的去Amazon找，想說也要買一本回來看，結果卻不小心讓我看到如下圖所示，Amazon 的創業三合一推薦套餐，整個眼睛一亮，差點手滑就三本買下去，還好要結帳時理智瞬間恢復 (另外兩本是The Lean Startup 和 The Startup Owner's Manual )

這本書讀起來真的相對輕鬆許多，不像另另外兩本書都是滿滿的字，看起來非常辛苦(其實是我英文太爛...囧rz..)，它大量利用圖像化的方式說明，非常淺顯易懂！目的是讓人簡單的就可以分析，診斷現有的Business model，甚至規劃產出新的Business model，最讓人驚喜的就是這家出版商還出iPad 版 App耶~(不過要價29.99USD...@@)，真的是要達到名符其實的商業模式產生器嘛。


本書的核心就是利用下圖來解釋所有的商業模式 (這讓我想到富爸爸的現金流模型)，後來才知道這章圖叫做 Business Model Canvas 已經行之有年。

簡化的版本如下：

在第一章，作者們先定義 Business model上需要注意的四個大類和九個重要元素：

Infrastructure (基礎建設部分)

• Key Partners
• Key Activities
• Key Resources

 Offering (提供的價值)

• Value Proposition (正如同它所在的位子，算是整個Buseiness Model 的核心)

 Customer (與客戶相關的部份)

• Customer Relationships
• Channel
• Customer Segments

 Finances (財務部份)

• Cost Structure
• Revenue Streams

然後分別說明每個元素的意義，以及每個元素的選項，比如說，Revenue Streams，就有好幾種選項(Asset sale,usage fee,subscription fees...等)。

在使用上，這裡的每一個項目都很重要，缺一不可，因為以前在想Business model 時，可能都會因為個人的專長和所屬領域不同，造成只會著墨在某幾個區塊，然後忘記其他區塊也是要一併納入思考。像我覺得我最常遇到的狀況就是，在選擇Customer Segments 時太過摸棱兩可，然後又自動忽略Finance-Revenue Streams的部份，結果就會是產品是做出來了，但是對著錯誤的客群，用錯誤的收費方式(甚至是不知道該怎麼收費)，所以第一章的功課就是分析現有的Business model ，並且把相對應的選項填在表格上，畫好就會長得像下圖。

如果有好好做功課，到了第二章就會發現，就算每一格也都有放入想好的元素，但是兜起還是會覺得怪怪的，因為放在每一格的選項，搞不好是互相衝突的，這時候就要"重構"，設法調整成 Unbundled Business model，這我放到下一章在來討論。

[Update：2012/5/22] 原來Appwork 用這個已經行之有年，下面其他人的使用心得：

• 5945呼叫師傅：Startup的你需要Business Model Canvas，而不是SWOT 或是 Porter的五力分析!
•  比賽麵：創業實作！使用Business Model Canvas來分析商業模式

[Update：2012/6/5] 原來博客來有賣大陸的簡體翻譯書 "商業模式新生代"

MongoDB Replica Sets Problem

最近忙著要讓產品上線，主要的工作就是在調教Production 的環境，還有做整合測試，但是在MongoDB那邊吃足了苦頭，這幾天都是在跟MongoDB 打渾戰，因為遇到了資料在Replica Sets 不同步的問題，在討論這個問題和解法前，先介紹一下MongoDB的特色，以及為什麼要選用他。(因為偷懶吧...)

MongoDB的特色根據官網自己的描述：

• Document-oriented storage (採用JSON，好改容易理解，但是也容易誤用)
• Full Index Support (但是很肥)
• Replication & High Availability (但是還是遇到一堆問題~囧)
• Mirror across LANs and WANs for scale and peace of mind. (你不會想要讓他cross WAN的...) 
• Auto-Sharding (號稱最強大的祕密武器~~)
• Document based Querying (真的要多Try & Error)
• Fast In-Place Updates
• Map/Reduce (研究中...)
• GridFS (研究中..)

之所以會選MongoDB 最主要就是看上它以Replica Sets 的方式達到HA，以及AutoSharding的能力，一個Replica Sets由若干個mongod instance組成，在這個集合中，所有的instance的資料相同，這使得即使有某一台機子當掉了，其它機子還是可以正常運行，而這部分的控制是由Mongo自動完成的，用意在於減少因當機而產生的錯誤及人工處理的部分。(但是我還是遇到問題啊~~~~~~囧rz...)。

首先我的配置是參考了Foursquare的文章 Fun with mongodb replica sets 以及Mongod 官網教學[Upgrading to Replica Sets]，一開始啟動了三台Mongod instance，一台是Primary，一台是slave，一台是Arbiter (投票者)，設定步驟如下：

1. 分別在三台機器啟動 (/etc/hosts 彼此要看的到對方 ) > mongod --rest --replSet replSetServers
2. 在PRIMARY 那台做以下設定 > rs.initiate()
> rs.add(“replSetServers01”)
> rs.addArb(“replSetServers02”) //(這台是投票用)
3. 移除多餘的Server (Optional) > rs.remove("replSetServers04:27017")
接下來應該就可以正常運作了，一開始的確是用的很開心，但是漸漸的就會遇到一些奇怪的問題，比如說write-concern 的問題，然後我們是用Spring-data來操作mongo，也發現了spring-data的bug，但是這些問題都還算可以解決，最讓我不解的就是同步問題，理論上應該會Eventually Consistency，也就是我們把資料寫入primary，然後mongoDB會自動把資料同步到Slave去，讓其他Client可以讀取。我遇到的問題就是有一筆資料明明在primary已經消失，但是卻一直留在Slave上，然後我等到望眼欲穿，它也不會同步，我也不能手動從slave把它砍掉.......，然後我就在網路上找資料，判斷有可能是以下原因造成資料錯誤：

• 沒有用正常步驟到mongoDB 裡面下 db.shutdownServer()，而是直接kill process，可能因此造成資料損毀或不同不。
• 根據以下圖片來解釋，資料同步的方向應該是單向的，也就是primary write to slave，如果這時候primaryA 掛了，slaveB升格成primaryB，這時資料寫到primaryB，結果primaryA又回復，primaryB又變回slaveB，在那這段期間內產生的資料會發生什麼事呢？是不是就會產生孤兒？

好，我先不管發生的原因，我先想解決的方法 (真是不求甚解...囧) ，就在 mongoDB的官網找有無類似的教學，發現幾個可能有用的：

[Durability and Repair] > db.repairDatabase(); 跑了很久....很久....結果...還是一樣.....

[Resyncing a Very Stale Replica Set Member] ，裡面提供了三種建議：

• Perform a full resync (砍掉重練...)
• Copy data from another member (也是砍掉重練...)
• Find a member with older data (還是砍掉重練...)

所以最後只好使用砍掉重練大法....所以心得是，在使用mongoDB上還是要很小心(廢話...)

與巨人搏鬥或是站在巨人的肩膀上? 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.