2012年11月29日 星期四

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

圖片來源:網路


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

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

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


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

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

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




2012年11月24日 星期六

閒聊技術趨勢與產業觀察

圖片來源:photopin


每隔一陣子這句話都會浮上我的心頭
吾生也有涯,而知也無涯。以有涯隨無涯,殆已!已而為知者,殆而已矣!為善無近名,為惡無近刑,緣督以為經,可以保身,可以全生,可以養親,可以盡年。
《莊子‧養生主》
雖然知道這個道理,但是為了求生存混口飯吃(好像講的太消極了?XD),膚淺的我就只能想辦法加緊腳步跟的上時代,不斷的吸收新知,想辦法消化,其實說穿了目的,就只是想知道這個世界到底在發生什麼變化?趨勢在哪裡?下一個機會再哪?此時的我扮演的是一個觀察者


觀察者


身為一個觀察者,但面對的資料量是如此的龐大,資訊來源是如此的多,如果沒有一個系統化的方式去閱讀與整理資訊,只是一味的趕流行,很容易就會迷失在資訊洪流裡面,所以常常會便常以下的狀況(整理自個人辛酸血淚史):
  • 漫無目標的在網路上"看"資料,看完就忘掉。
  • 當個熱血粉絲,訂閱許多網路大大的bloger或是粉絲頁,看完後大大還是大大,而自己還是一樣的小白。
  • 每天的工作就是打開Google Reader 快速掃描有興趣的文章,然後勾選全部以閱讀。
  • 每次看到新的名詞,新的玩意就一直追下去,然後又會連結到其他新玩意,最後就無限發散下去。
因為沒有辦法看從宏觀的角度去看清楚趨勢的全貌,到頭來就如同瞎子摸象般,看似有觀察到什麼,但往往只是個片面現象罷了,稱不上是趨勢。

 瞎子摸象  (圖片來源:網路)

不過如果摸久了,而且肯移動腳步由不同的面相亂摸,也許哪天就能真的給我們拼出個全貌出來!!好啦其實講了那麼多的廢話,只是為了我最近瞎子摸象的不負責任心得鋪梗~XD


趨勢:Social Mobile Big Data Cloud





軟體服務業的發展四大趨勢 (圖片來源:自行整理)

上圖是我由許多談論IT趨勢的文章(有興趣的可以看延伸閱讀),以及在這個產業混了好一陣子,經過摸索與消化所觀察整理出來的,分別是Soical Network,Mobile,Cloud Computing 以及Big Data。

其實這四大塊的議題與應用都是一直存在的,但是回到幾年前單獨拿這幾個領域來看,每個領域都會因為缺乏其他領域技術的幫助,各個都成不了氣候。直到幾年這四個領域的技術都有突破性的發展,突然間這四個領域碰撞在一起,互相成為彼此的幫助,讓這整個產業開始產生一個正向且加速的循環。
  • Social Network 得力於Mobile的普及,以及Cloud Computing 的助益才得以壯大。
  • Mobile 如果沒有Social Network 產生大量運用,以及 Cloud 的基礎建設幫助,也很難發展茁壯。
  • Big Data 也是因為Social Network 與 Mobile 的碰撞加速的產生大量的資料,才凸顯這個議題的重要性,與相關技術的蓬勃發展。

 開發者/技術人員


身為一個觀察者也許可以看清楚趨勢,可以了解每一個領域的關係與內容,已經足夠針對每個議題做個鍵盤評論家或是嘴砲,但是身為一個開發者或是技術人員這樣是遠遠不夠的,因為每一個領域在往下鑽,個個都是得下一萬小時苦心的硬功夫

The 10000 Hour Rule is just that. This is the idea that it takes approximately 10000 hours of deliberate practice to master a skill.  

於是我把上面那張產業的圖,轉換成下面這張技術相依性的拆解圖,因為對技術角度來說,我覺得Social Network比較像是一種應用,而Mobile、Cloud Computing 和BigData 則是圍繞著它在發展。轉換成技術角度的用意是提醒自己,身為技術人員,要有所取捨,雖然彼此都互相有關係,也都是未來的趨勢,但是不能太貪心全部都想摸,全部都想玩,順便也可以檢視一下自己這一路走下來到底跑到哪去了?身處何方?

所以由下圖的顏色可以知道,我自己對於Mobile 和 Social 這領塊領域真的墨真不深,短期間內應該也沒時間和沒精力去碰觸。(我不熟啊不要問我啊~~但是我有很多這領域的強者我朋友。)



四大發展方向的技術拆解圖  (圖片來源:自行整理)

所以講了那麼多今天要聊的還是雲端運算 ╮(╯▽╰)╭

話說雲端運算這個名詞剛開始流行的時候,Big Data 和 Cloud Computing 其實常被當做同一件事在討論,所以出去人家問你搞啥的,只要回答"我是搞雲的~(  ̄ 3 ̄)y▂ξ "就好,反正我自己也搞不清楚,別人也搞不清楚,但是好像很炫。


但是這幾年下來,我覺得市場上已經慢慢了解何謂雲端運算,以及可以分辨出各自的領域屬性,以及分別所要解決的問題,所以Cloud Computing 和 Big Data 這兩塊慢慢可以區別開來,畢竟所用到的技術看似相近,但是本質上還是很大的差別。

所以回歸到我最近到底在搞啥?可以說Big Data 和 Cloud Computing 這兩塊都有些著墨,但是再拆解下去,應該說我比較墨在於Cloud Computing 的 IaaS 這塊(真的是莫名跳入這個領域),以及Big Data 的 NoSQL這塊。不過這樣說還是太籠統了,因為光IaaS又可以再被分為幾個領域:
  • Network 
    • Traditional Data center Network  / Architecture
    • Network Virtualization / Software Define Network (SDN)
  • Storage 
    • Distribute Network file system
    • Network Storage
  • Computing
    •  Virtualization (CPU、Memory)
  • Management
    • Virtualization Management
    • Provision
    • Monitor
    • Hybrid
    • Backup
而Big Data 也被分為好幾個面相去討論:
  • Storage
    • Distribute file system ( HDFS)
    • Object Storage
  • Analytic
    • BI
    • Visualization
    • Machine Learning
    • Recommendation 
  • Computing
    • NoSQL
      • Hbase
      • MongoDB
      • Cassandra
    • Map-Reduce
      • Hadoop
      • MongoDB
      • MapR
    • Streaming Event Process
    • Complex Event Process
光是看Facebook 上的社團發展就可以知道,從一開始BigData Taiwan又細分成NoSQL Taiwan,後來又個別產生MongoDB、Hadoop..等社團,這樣一路拆解下去。越拆解下去我越是膽顫心驚啊,因為一定要選邊站啊,有所取捨啊!

如果現在人家問我懂不懂雲端,我只能說略懂,人家問我在做啥,我只能說打雜的....這正是樣樣通樣樣鬆的寫照吧...Orz...

 很奇怪的結尾和結論...(〒﹏〒)


延伸閱讀:
[1] Timing Your Adoption of Disruptive Tech like Cloud, Big Data
[2] Gartner: How big trends in security, mobile, big data and cloud computing will change IT
[3] Gartner Top 10 Strategic Technology Trends for 2013: Big Data, Cloud, Analytics and Mobile
[3] The "Big Five" IT trends of the next half decade: Mobile, social, cloud, consumerization, and big data
[4] Core digital world issue in 2012
[5] Mobile, social and big data drive cloud computing boom: studies

2012年11月19日 星期一

資料收集 - 到底什麼是Bitcoin?

圖片來源:Bitcoin Heist Edition


這個神奇的玩意- Bitcoin 是某一天在看某個大大Blog 無意間發現的,想說這是什麼神奇的玩意:虛擬貨幣、P2P技術、分散式運算、無法追蹤的網路神祕貨幣....

於是我就開始上網收集資料,才發現乖乖..這玩意已經存在好一陣子,而且還有某個程度的市場機制耶,而且就跟股票和外匯一樣,價錢是有起伏波動的,下面是我收集一些比較重要的網站和這個貨幣的解說資訊。

資料收集:

簡單來說,就像以前很熱門的搜尋外星人計畫,有一堆資料,然後讓大家下載部分片段回去電腦分析,這個貨幣用類似的原理,但是更複雜的演算法,讓大家的電腦透過類似Bt P2P的技術去計算這個演算法的某些答案 (他們稱之為挖礦),但是這個運算需要大量的電腦運算,而且隨著時間能抓到的答案會越來越少,所以這個貨幣最終會有固定的數量,之後就是看市場機制去決定它在真實世界的價值。

不過我比較好奇的是,網路上說這個運算,要用高效能的顯示卡也就是GPU來運算才比較有效率,我比較不懂的是GPU 和 CPU 到底差別在哪裡,以至於GPU在做運算會比較有效率?之前也有聽過叫做cuda 的電腦,就是全部由GPU打造用來作科學運算的,那到底GPU和CPU的差異在哪裡呢?

答案在這裡: Why a GPU mines faster than a CPU

但是我還是不太懂...XD 簡單來說CPU擅長執行,GPU擅長運算?


2012年11月18日 星期日

[書摘] 好價錢讓你賺翻天

圖片來源:網路


今天在整理書架,順手又把好價錢讓你賺翻天 (The art of Pricing)這本書拿起來翻,發現...都忘了差不多了...囧rz....這也提醒我人的記憶力是非常有限的,所以我應該鞭策自己每看完一本書至少要把重點或是書摘記下來,至少下次要回來翻的時候,可以知道重點在哪裡該從哪裡複習....

不過這本書真的翻譯名稱真的很俗,新版的翻成定價思考術我覺得比較好一點,當初會買這本書就是想要了解所謂的定價策略,與價格該如何制定。尤其在現在雲端服務的時代,動不動就是XXX as Service,很多的產品都是以非常抽象的服務為導向,很難再像硬體的時代由製造成本的角度去思考定價策略。這也是我覺得Lean startup 裡面比較少提到的就是這一塊,所以請搭配服用~XD

這本書提供了幾裝方法與模型:

價值解碼器

用來判斷產品價值的基本架構,讓你分析構成價值的成份,再告訴你如何將這項分析,轉換成正確的產品價格。
這個價值解碼器主要是透過五個分析的步驟,不斷循環去產生出最適合的定價策略與產品價格,這五個步驟分別是:

1. 替代品的價格和取得方便性

你的價格,要看實力相近的競爭對手怎麼索價,他們所多少價,如果他們改變價格,你會如何因應?如果你改變你的價格,競爭者會如何反應

2. 相較競爭對手的特點

列出產品的全部對手,你的產品,在以下特點:
  • 品牌
  • 方便性
  • 品質
  • 功能屬性
  • 服務
  • 風格
這六個特點上,相較對手的特點如何?將這些特點的差異列入考慮,你的價格應該比競爭者多多少,或是少多少?

3. 所得(客戶/顧客)

你的顧客賺多少錢?他們的所得,對他們意願位你的產品花多少錢,由多少影響?

4. 相關產品的價格/需求強度

其他產品對你產品的價值有和影響?這些產品,對你產品的價值產生什麼效應(例如:他們產品降價,你的產品價會如何改變?)

5. 市場環境

市場環境的哪些改變(一時風潮、新資訊、無預期的事件、時機),會影響產品的價值?這些市場環境的改變,有哪些可以預測的?而有哪些市場環境的改變,是很有可能會發生的?

差別定價技術

 發掘不同客戶對產品和服務的評價,並採取因應之道。多重定價心態策略的組成分子,使你得以用不同的價格,把相同產品賣給不同顧客。

1. 顧客的特點:

利用年齡、性別、隸屬於哪個組織,以及靠近某個管光景點等特點,可找出不同評價的顧客,並針對他們訂不同的價格。 (感覺就是Big Data 分析可以出動的地方~)

2. 門檻

折價券、特賣、會員資格、規模和刻意的舉動等,幫你找出不同評價的顧客,並且賣東西給他們。

3. 時間

將時間因素融入定價中,使你同時從願意多花錢趕快拿到產品的顧客,以及對產品評價較低,願意等降價在買的顧客身上賺到前。

4. 數量

價格越低,越能吸引顧客購買較大的量。

5. 分配

根據顧客在何處購買,可以訂不同的價格。

6. 合購

用單品和合購優惠的方式銷售,針對不同顧客訂不同價格。

7. 交涉

與個別客戶交涉,讓你訂定不同的產品價格。

設定不同版本

設定不同版本也符合成本效益,最棒的在於,與策略相關的成本大多早就發生。

1. 按菜單點菜

能不能提供顧客一份有各種選項的菜單,位產品設定不同版本 (就像我之前提在"免費只是吸引的手段,如何提高使用者付費轉換意願?"這篇裡面有引用的文章 Freemium Pricing for SaaS: Optimizing Paid Conversion Upgrades)

2. 多及是好

能否提供擁有"更多"的產品,來製造更高的利潤和新顧客?(例如:更多的數量、更高品質、更多支援或體驗)

3. 少可能有賺頭

你能不能提供較少的產品,來吸引新(且通常極具價值意識)的顧客?(例如:較少的數量、較低品質、較少的服務或體驗) 有點MVP的fu~

4. 加減特點

你能不能改變產品的功能屬性,以及吸引新的顧客?

5. 加速服務

你能不能位顧客提供更快速的服務? (天下武功無堅不摧為快不破~XD)

6. 避免等待

你能不能提供免於排隊等待的選項

7. 不確定性

不同程度的不確定性(亦即:降低消費者或你的風險),能不能作為產品的不同版本?

最後一點舉了紅酒的期貨,以及時間店價的概念,其實就是有種期貨分散風險的概念

2012年11月16日 星期五

centos6.3 + openvswitch 1.4.3 安裝筆記

圖片來源:openvswitch 官網


換了新環境,首要任務就是重新建立開發與測試環境,但是發現好一陣子沒當黑手,東西又忘光光了,只好回去翻一下筆記,卻發現之前寫的安裝Xen 4.x 和 OpenvSwitch for centos 6.1~6.2,已經不夠用了,主要的原因如下:
  • 這次懶得裝Xen了,反正開發環境用KVM擋著應該夠了
  • CentOS 也已經升級到6.3 了
  • 然後之前openvswitch 是直接從source code build ,這次應該可以直接產出rpm檔
於是上網找找看有沒有新的教學,找到了一篇"These are my notes for installing KVM on Centos 6.3 minimal"的文章,但是我覺得在Build的部分應該可以用rpmbuild 可以簡化許多步驟,將來也比較好維護管理,所以我在這邊只有紀錄build rpm 的步驟,其他的還是可以參考上面的連結。

安裝


#
# 一開始先準備 for rpm build 的套件
#
sudo yum -y install rpm-build gcc openssl-devel make kernel-devel module-init-tools autoconf redhat-rpm-config

接下來就是簡化的安裝步驟
#
# 利用rpmbuild 去產生rpm檔
#
rpmbuild -bb rhel/openvswitch.spec
cd ~/rpmbuild/RPMS/x86_64/
sudo yum install kmod-openvswitch-1.4.3-1.el6.x86_64.rpm
sudo yum install openvswitch-1.4.3-1.x86_64.rpm


用rpm的好處就是許多設定檔它都幫你設定好,程式和kernel module也都已經幫你裝好了,剩下來的你只需要再確認一下就ok,不過這邊另外要注意的是,centos內建的libvirt 是比較舊的版本,libvirt 從0.9.11開始才有支援openvswitch,如果沒有自己去更新,就會發現在virt-manger 怎麼去新增vm都沒有辦法加入網卡,所以下面就繼續記錄如何更新libvirt,我是拿fedora 17的版本的SRPM來rebuild



安裝 Extra Packages for Enterprise Linux repository configuration

wget http://mirror.chpc.utah.edu/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
sudo yum install epel-release-6-7.noarch.rpm

#
# 抓fedora 17 的 source rpm 回來重build
#
wget http://libvirt.org/sources/libvirt-0.10.0-1.fc17.src.rpm
sudo rpm -ivh libvirt-0.10.0-1.fc17.src.rpm

#
# 在重build之前,要把這套件相依的套件都要一起裝起來
#
sudo yum install avahi libxml2-devel gnutls-devel device-mapper-devel \
python-devel libnl-devel dejavu-lgc-sans-fonts openssl-devel yajl-devel \
avahi-devel libssh2-devel libcurl-devel xhtml1-dtds readline-devel \
ncurses-devel libtasn1-devel augeas libpciaccess-devel sanlock-devel \
libpcap-devel cyrus-sasl-devel parted-devel numactl-devel libcap-ng-devel \
netcf-devel audit-libs-devel systemtap-sdt-devel scrub numad libblkid-devel\
ibuuid-devel.x86_64 sanlock-lib.x86_64

sudo yum install ftp://rpmfind.net/linux/centos/6.3/os/x86_64/Packages/numad-0.5-4.20120522git.el6.x86_64.rpm

#
#開始重build
#
rpmbuild -bb ~/rpmbuild/SPECS/libvirt.spec

#
# build 好之後先把舊的套件移除
#
sudo yum remove libvirt-client


#
# 然後再安裝新的套件
#
cd ~/rpmbuild/RPMS/x86_64/
sudo yum install libvirt-*
sudo yum install virt-manager

#
# 最後再把libvirt重新啓動
#
sudo service libvirtd start
sudo chkconfig libvirtd on

設定

整個在openvswitch 在使用的經驗中,最讓我不解的就是到底br0 需不需要設ip,如果以傳統硬體機器來說,bridge本身應該不需要設定ip啊? (除非是我想錯了...),以架構來說應該長得像下圖一樣。


            +--------------------------------------------+
            |                    host                    |
            |--------------------------------------------|
            | +----------+                 +----------+  |
            | |   VM1    |   .......       |   VMn    |  |
            | +----+-----+                 +-----+----+  |
            +------|-----------------------------|-------+
            |  +---+----+                  +-----+----+  |
            |  |  tap0  |    .......       |  tapn    |  |
            | ++---+----+------------------+-----+----++ |
            | |    |             ovs             |     | |
            | |    +-------------++--------------+     | |
            | |             +----+-----+               | |
            | |             |   br0    |               | |
            | |             +----+-----+               | |
            | +------------------|---------------------+ |
            |                    |                       |
            |        +-----------+                       |
            |        |                                   |
            |  +-----+-----+          +----------------+ |
            |  |           |          |                | |
            |  |  eth0     |          |    eth1        | |
            +--+-----------+----------+----------------+-+


但是在openvswitch 上面的FAQ 開宗明義就說要把ip設定在br0 上...

Q: I created a bridge and added my Ethernet port to it, using commands
   like these:

       ovs-vsctl add-br br0
       ovs-vsctl add-port br0 eth0

   and as soon as I ran the "add-port" command I lost all connectivity
   through eth0.  Help!

A: A physical Ethernet device that is part of an Open vSwitch bridge
   should not have an IP address.  If one does, then that IP address
   will not be fully functional.

   You can restore functionality by moving the IP address to an Open
   vSwitch "internal" device, such as the network device named after
   the bridge itself.  For example, assuming that eth0's IP address is
   192.168.128.5, you could run the commands below to fix up the
   situation:

       ifconfig eth0 0.0.0.0
       ifconfig br0 192.168.128.5

   (If your only connection to the machine running OVS is through the
   IP address in question, then you would want to run all of these
   commands on a single command line, or put them into a script.)  If
   there were any additional routes assigned to eth0, then you would
   also want to use commands to adjust these routes to go through br0.

   If you use DHCP to obtain an IP address, then you should kill the
   DHCP client that was listening on the physical Ethernet interface
   (e.g. eth0) and start one listening on the internal interface
   (e.g. br0).  You might still need to manually clear the IP address
   from the physical interface (e.g. with "ifconfig eth0 0.0.0.0").

   There is no compelling reason why Open vSwitch must work this way.
   However, this is the way that the Linux kernel bridge module has
   always worked, so it's a model that those accustomed to Linux
   bridging are already used to.  Also, the model that most people
   expect is not implementable without kernel changes on all the
   versions of Linux that Open vSwitch supports.

   By the way, this issue is not specific to physical Ethernet
   devices.  It applies to all network devices except Open vswitch
   "internal" devices.


但是我設定好之後,從virt-manager 去啓動vm 又遇到這幾個問題:
當遇到這種問題代表Linux 的brctl 無法操控ovs,所以記得要安裝 brcompat.ko


後來我又遇到一個笨問題,就是因為參考最上面的圖的架構,所以我一直沒有把eth1加入br0,造成我的vm一直無法連到外面,後來參考這篇文章"why vm can't ping host eth1",才讓我茅塞頓開解決這個問題。

目前看起來openvswitch 是可以正常運作了....

2012年11月12日 星期一

減肥!!找出讓C槽爆滿的元兇 - 砍掉 Chrome 保留的舊版資訊

圖片來源:網路


有用Windows 的應該都常常覺得 C槽的剩餘空間一直默默的在減少,不管怎麼努力去清理垃圾桶,刪除tmp檔案,努力榨出空間出來,但是隨著時間,剩餘空間就是不留情面的持續減少,明明最近都沒灌什麼軟體,資料性質的檔案都放到D槽,到底是什麼東西一直在吃資源!?

通常兇手都是放在AppData裡面,(話說上一次發現的兇手是itune幫ipad備份的檔案),於是我只好又一個資料夾一個資料夾檢查,這次被我發現兇手之一就是Chrome!!

大家都知道Chrome 更新的速度非常快,幾乎每隔幾個星期似乎就會出一版要你升級,Google 也號稱每次的更新都會讓改善Chrome的效能,根據Google 黑板報的資料,從地15版到24版效能已經提昇了26.3%!!

 
 圖片來源:Google 黑板報

升級很好啊,變快也很好啊,但是為什麼升級後還要把舊的版本都留著呢!?平均每個資料夾都有100~200MB,而且所謂的加快應該也適用空間換取時間,chrome的AppData資料夾裡面存了堆Cache、DB、File-system...等資料,加起來也是好幾G。


我這因為重灌過,所以留的版本還算少,看看下面這位仁兄,舊的版本資訊佔掉他2.9G



到底為什麼要把舊的版本都保存呢?身為強大的Google大神,為什麼在升級的時候不會順便把舊版的砍掉呢?真是百思不得其解....

不過後來經過測試,把舊版的檔案砍掉後,Chrome還是正常的運作,那就努力的把它砍光光吧~~~







2012年11月6日 星期二

公有雲?私有雲?爭什麼爭~泡了他做撒尿牛雲吧~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。

2012年11月4日 星期日

在Agile裡關於 SQA 這個角色


QA ? Tester ? 傻傻分不清


故事是這樣開始的,話說最近換了工作重新當起了新鮮人,但是對於新公司的職稱角色一直感到很疑惑,在公司裡面工程師通常被分為兩種角色RD和QA or SQA (Software Quality Assurance ),但是這幾天觀察下來發現QA的角色定位和在做的事跟我之前所認知與遇到的有很大的差異(就像我前公司的SA跟我原本認知的SA也不一樣~XD)。

跟其他待在公司比較久的朋友討論後,發現這邊的QA 工作內容是:
  • test tool development
  • test case design
  • code coverage examination
  • automation script/framework
  • prepare release package
  • 部分test execution
除了Test case design 和 test execution比較像是傳統我認知的QA工作外,其他比較像是 DevOps 的 Ops,又有點 Release engineer 的味道,這讓我對於這邊 QA 的工作內容更加好奇了(沒辦法以前呆小公司幾乎是全包,哪知道還有這麼多專業分工~:P )

上網查了一下,原來我我之前的認知算是狹隘的QA 也就是 - Tester (測試工程師),工作內容的確就是包含寫Test plan(測試計畫),Test case(測試案例),要會設計測試情境,系統測試,然後遇到bug就開Ticket, follow up 後續修改進度 (然後定死RD~XD)

但是廣義的QA 或是SQA 其實是所謂的品質保證工程師,需要從設計階段就要參與,從架構是否有問題,邏輯設計是否有錯誤,系統分析是否正確,是否有架設建構管理,版本控管,甚至要負責跟SA、RD、PM、Tester之間做溝通協調?看到這個描述感覺已經有點Architect 的fu 了?

我想描述最清楚的大概就是Tester vs. SQA - 3/5Tester vs. SQA - 4/5 關係與差異  這系列文章,裡面列出來SQA的工作內容與傳統Tester 的差異。這也難怪在國外通常是比較Senior 的 RD才會轉QA?

參考一下國外 SQA Architect 的職務內容應該可以更進一步了解吧~:P

Responsibilities:
  • Design and develop automation harnesses, testing extensions, and automation libraries
  • Review needs and specifications for scenarios requiring automation and tools to improve test coverage  (我也很好奇test tool 還有 test "test tool" 的 tool ..無窮迴圈XD)
  • Review current test plans, test cases, and test procedures and provide automation wherever possible
  • Maintain existing automation scripts and potentially rewrite the scripts using other automation tools
  • Design and develop new performance, load, data set, application and simulation tools
  • Design and develop interactive results analysis viewers
  • Track quality assurance metrics and provide code coverage analysis metrics
  • Define and enhance processes methodologies
  • Ensure established standards, processes and procedures are used consistently throughout the release life cycle
  • Write efficient, easy to follow documentation on all tools, scripts and processes
  • Maintain existing and new SQA environments and repositories
  • Understand and gather project requirements from the customer, both internal and external, creating and reviewing specification artifacts
  • Execute and report results of entire project
[Update]
後來很多朋友跟我解釋,SQA 和 QA 差一個字但是內容差很多,事完全不一樣的東西。

QA in Agile

回到Agile 這個問題就更有趣了,如果你問我Tester 要如何併入Agile 的 Sprint 運行,那我可能比較可以回答這個問題,通常有兩種模式:
  1. 在同一個Sprint 裡面就先與RD協調安排Testing 的時間和工作 (比較像Mini waterfall)
  2. 把Tester的 testing 放在下一個iteration,讓他們專心做測試,發現的bug依據priority 排入backlog看是要在下次或是其他時間解決
但是如果是廣義的SQA,那這個問題就有趣了,因為這個角色會貫穿整個軟體的開發流程,從初期的架構設計與需求分析就會加入,一直到Testing Automation、Deploy Automation、Release 都會參與。

所以一旦遇到有專職的QA team 或是 工作劃分非常精細的公司,在導入Agile可能就會遇到許多不一樣的問題,可以參考QA 團隊單獨執行 Scrum 的困難在Agile中如何進行測試的工作
等文章。

最後我自己的想法是,其實Agile重點就在於那個精神,然後必須根據不同的公司,不同的專案,甚至不同的分工方式做挑整,並沒有一體適用的方法,畢竟牽涉到人的事情總是複雜的(@@~)