2012年5月30日 星期三

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 粉絲頁

2012年5月25日 星期五

MeshCloud Beta 測試邀請


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

怎樣的使用者可能會有興趣參與我們的測試?
  • 還沒有AWS 帳號,但是想要把系統移到IaaS上的使用者 (我們可以協助您申請) 
  • 已經擁有Amazon 帳號的使用者
  • 已經擁有Amazon 帳號,希望能在iPad上操作管理你的IaaS
  • 已經擁有Amazon 帳號,希望能以圖像化更直覺管理和監控你的系統
  • 已經擁有Amazon 帳號,希望系統能提醒你是否有忘了釋放的資源
  • 已經擁有Amazon 帳號,但是更希望可以同時控管其他IaaS帳號 (如Rackspace)
我們誠摯的邀請你來測試,請現在就在連到以下網址:

我們更誠摯的邀請你來到我們公司,坐下來喝杯咖啡,讓我們為你解說該如何操作。
現在就寄信與我們聯絡 Service@meshinnovation.com 

也歡迎加入Facebook 粉絲頁 Cloud Lab

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

2012年5月21日 星期一

Business Model Generation - 9 key factor


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

會看到 Business Model Generation 這本書真的是純屬意外,一開始是看了XDite所寫的文章"The Startup Owner's Manual 讀書心得",然後就很興奮的去Amazon找,想說也要買一本回來看,結果卻不小心讓我看到如下圖所示,Amazon 的創業三合一推薦套餐,整個眼睛一亮,差點手滑就三本買下去,還好要結帳時理智瞬間恢復 (另外兩本是The Lean StartupThe 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 用這個已經行之有年,下面其他人的使用心得:
[Update:2012/6/5] 原來博客來有賣大陸的簡體翻譯書 "商業模式新生代"

2012年5月19日 星期六

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上還是要很小心(廢話...)




2012年5月5日 星期六

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