建構雲端服務的生態體系為何如此重要

生態體系Ecosystem，原來是生態環境領域的用詞，多半用來描述一個生態環境裡的環境與動植物生態體系如何形成及維持，在真實世界裡，我們也開始嘗試用生態體系的觀點來描述複雜的體系運作機制，而雲端服務的發展也趨於多元分工，讓我們關注到生態體系的動態變遷及成長，但怎樣的雲端服務生態體系是健康或有競爭力的呢? 這是本文嘗試探索的目標。

要談雲端服務的生態體系，不得不先從Amazon Web Service (AWS)的服務架構談起，許多人只知道AWS提供EC2、S3等主要的雲端服務，但其實AWS隨著業務的發展，已經推出許多與雲端服務運作及維持有關的周邊性服務，這些服務串起及支撐整個雲端服務的發展，或者說客戶的雲端服務須要架構在這許多服務之上，才能提供Scalable隨需成長、Sustainable可持續的運作，在Amazon的一份報告中，Amazon提到了以下這張圖足以表示AWS服務的發展概觀。

來源: "Architecting for the Cloud: Best Practices", Figure 1, January 2010, Amazon

另一份簡報資料，則呈現了從用戶端的角度更具像的AWS服務架構，對於用戶端的服務而言，使用EC2及S3、EBS僅是基礎工程，若要發展更完整的服務，需要有雲端資料庫、搜尋引擎、訊息服務、內容服務等，此外還要考量認證服務、監控服務、作業自動化等等，如果整個服務都是在雲端上，其時要考量的項目很多。

來源: "Building Powerful Web Applications In The Cloud: A Love Story", 2011, Amazon

「Lantana」為一家輔導客戶使用AWS的諮詢顧問公司，提出了以下的輔導流程，來幫助AWS用戶精打細算，以盡可能低的成本來發展出符合自己效能需求的最適雲端架構。

來源: "AWS Managed Services: Manage AWS Cloud Smarter Way", 2012, Lantana 

AWS雲端發展規模日漸龐大，除了AWS自己所發展的服務規模外，在其周邊也有很多業者提供諮詢服務、監控服務或加值服務，在AWS Marketplace中就提供非常多的應用系統，客戶可以搜尋可在AWS上運行的應用系統，這些應用系統都已經針對搭配AWS運作而進行設定的最佳化，可以很方便快速的放到AWS提供運用，AWS快速發展成龐大的生態體系，不僅擁有龐大的客戶社群、更有龐大的系統開發商圍繞在AWS周圍成為體系的一部份，在AWS的架構下，靠AWS的資源，作AWS客戶社群的生意。

Amazon也很清楚雲端服務的發展，雲端服務能否成功，關鍵並不在於提供那一類型的網路服務，而是如何建構出客戶需要且完整的生態體系，在這樣的發展概念下，與客戶、開發社群共同形成生態體系並且共同成長，才是Amazon能夠長遠發展的基礎。Amazon AWS的成功經驗很值得其他正在發展雲端服務業務的業者參考，包括Apple、Google、SalesForce等雲端代表性廠商，其實都發展出自己的生態系統，包含雲端應用、載具、用戶社群、軟體開發商社群、內容社群、通路體系、應用市集等，甚至可能包含競爭者。生態系統愈龐大或欲活躍，則生態系統的建全度及黏著度愈高，欲不易被其他競爭者取代。

台灣產業過去以製造業為主要強項，對於高科技製造業供應鏈的模式比較熟悉，台灣的中小企業廠商努力要成為國際知名產品的供應鏈一環，就是希望能獲得供應鏈體系價值外溢的效果，但在軟體應用部份，這樣的供應鏈體系比較不明顯，例如台灣趨勢科技TrendMicro雖然具備國際品牌價值，但並沒有因此帶動國內相關產業的發展，形成在資訊安全產業的產業人才或技術優勢，此外部份電腦硬體製造大廠，雖有龐大市場為後盾，但也缺乏結合軟體應用的戰略及創新作為，仍舊把硬體銷售當作主要的獲利來源，軟體只是附加價值，這樣的發展不易培植出更有價值的生態體系，更不用說用戶社群、開發商社群、應用市集等。因此，如果台灣要發展出具備國際競爭優勢的雲端服務產業，以目前政府的輔導模式，仍是非常困難。

以台灣市場的規模要發展出具備規模經濟的生態體系也有困難，對於台灣的廠商而言，台灣市場雖小，但相對比較熟悉且不做可惜，這時候，如何整合，如何提高雲端服務在市場的滲透率等，都是政府及產業需要共同思考的。

雲端服務等級協議初探(3)

軟體即服務(SaaS)通常是架構在IaaS服務上的雲端服務，以Google為例，包括Gmail、Google 日曆、Google Talk、Google 文件和雲端硬碟、Google 網上論壇、Google 協作平台等都是SaaS服務的案例，Google針對商業用戶、政府機構用戶、ISP用戶、教育版用戶等，訂定了「Google Apps 服務水準協議」(網址)，承諾「Google Apps 涵蓋服務」的網頁介面每月至少需有 99.9% 的時間正常提供「客戶」操作與使用。Google App 在SLA中也約定了因停擺致未達約定可用性標準時的賠償方式、賠償上限及排除條件，整體而言這份SLA有其指標性的意義。

Google Apps的使用人數眾多，許多功能(例如Gmail、Google日曆、Google Talk、Google文件等)甚至彼此參用及互連整合，甚至許多其他軟體業者所開發的SaaS服務，也會整合Google的這些基礎SaaS服務或者其他知名SaaS服務，包括知名的Evernote、Dropbox、Youtube...等等，因此可以看到SaaS服務有可能會架構在其他SaaS服務之上，形成Nested從屬關係，這樣的關係讓SLA的訂定(以下假設主要評估指標皆為uptime百分比)更增加了複雜度，雲端服務SLA從討論單一服務的SLA，變成要檢視整個服務鍊的從屬關係，從下而上，才能推算出位於最上層服務的SLA評估指標。例如，假如某個SaaS服務X的底層應用到一個網路儲存SaaS服務Y，且假若這個網路儲存SaaS服務Y的可用性為99.5%，則服務X的可用性就會比99.5%略低一些。

SalesForce為知名的SaaS業者，主要發展CRM及相關的應用，在SaaS領域發展很早，已累積大量客戶並且獲利，也已發展完整的服務生態體系，有許多第三方的軟體開發商，與SalesForce結合，透過SalesForce的API及開發環境，來開發許多創新加值應用，拓展服務的範疇。SalesForce算是SaaS領域的領先者，但SalesForce一直不願意主動公佈其SLA，根據SalesForce的觀點，SalesForce認為客戶重視的是服務的透明度，當服務有問題時，能夠即時獲得正確的資訊，幫助客戶來進行因應。因此，SalesForce僅針對客戶有要求時，才提供SLA，但一般情況下，SalesForce著重在提供即時的系統狀態資訊給客戶。

SalesForce對於SLA的態度，讓我們重新審視SLA對於用戶的意義，SLA一般應用於客戶在選擇服務時藉以了解服務供應商對於服務的保證，但不可諱言，現行的許多SLA讓客戶常摸不著頭緒，又難以比較，因此SalesForce身為領導廠商，不與其他廠商在SLA上玩文字遊戲，反而著重於提供客戶清楚的服務狀態資訊，強調內部治理的透明化、效率化，在某種心理層面上，更可讓客戶安心。

「到底客戶重視什麼？」，是可用性保證? 是賠償的保障? 還是更全面的保險? 這是很難回答的問題，但愈來愈多的SaaS業者也公開其系統狀態資訊，包括Netsuite Status、Google Apps 狀態資訊主頁等。都可看到藉由公開即時的狀態資訊，讓客戶一目瞭然。

台灣目前SaaS業者也開始揭露其SLA資訊，但一樣面對國外業者所會面臨的狀況，關於可用性的定義仍是各家自行發揮的情況，客戶也不易針對各家的服務進行比較。此外，國內SaaS業者為了避免過於頻繁或過高比例的賠償情況發生，在可用性的承諾上仍舊低於國外一般水準，或增加一些除外條款。

台灣推動雲端產業的發展，業者須要透過累積許多經驗後，才能逐漸提升服務水準及品質，政府可以在過程中協助相關產業的發展，除了幫助業者提升內部治理的能力外，也要適度強化客戶服務能量及資訊透明度，進而轉化成具備國際競爭力的SaaS服務。

雲端服務等級協議初探(2)

這幾年雲端運算發展快速，有些業者認為現在要跟客戶談雲端，比較可以不需要費太多口舌去解釋何謂雲端(註)，許多雲端的產品與服務也都直接把行銷重點放在所要提供的服務項目及收費上，似乎雲端字眼已廣被接受及使用，但也有許多人提出質疑這種人「云」亦「云」的情況，尤其台灣政府已多次宣示要推動許多公有雲服務如教育雲、交通雲、食品雲、農業雲...等等，聽起來台灣在雲端技術及應用上似乎已走得很前瞻，但事實如何? 未來有這麼多公有雲提供服務，又要如何與民眾的觀感連結起來，提供可被檢視及評估的服務等級呢?
註: 關於雲端運算的定義可參考美國國家標準局(NIST)所公佈的定義(網址)。

雲端服務掛上「服務」的名稱，代表本質上必須是一項服務(As a Service)，因此雲端服務的提供必須考量服務等級協議SLA，不管是公有雲、私有雲服務，只要是服務，都牽涉到服務等級協議的規劃與提供。

IaaS雲端服務等級協議的評估指標

針對IaaS雲端服務等級協議的制定，目前首要的評估指標就是系統可用性(System Availability)，可用性的意義是評估雲端服務的可使用時間比例，基本上是全部可使用時間減掉預估無法使用時間後，除以全部可使用時間，來計算可用性百分比(也可稱uptime百分比)，但統計期間一般可為月或年，有些IaaS業者還會強調系統回復性(System Recovery)，說明當服務Unavailable時，系統可於多少時間內回復正常，少數的業者會進一步提供系統回應時間(System Response)及網路QOS(Quality of Service)的保證，整體而言，服務等級的重要指標就是可用性Availability及效能Performance兩大評估領域。

當發生服務中斷(unavailable or downtime)時，若中斷時間超過IaaS業者所承諾的中斷容許時間時，客戶可向IaaS業者申請未達承諾之賠償(請留意客戶須負舉證責任)，整理相關中斷事實(例如發生中斷的日期時間、問題記錄等)，並根據服務中斷的時間長久度量，來申請賠償(通常作為下個月費用折抵)，但總賠償金額多半不超過用戶所支付的月結帳費用，範圍約在5%-100%間，並視各家IaaS業者的情況而定。

IaaS業者雖提供服務中斷時的賠償條款，但通常也會強調排除條款，例如有些業者會將天然災害、停電、用戶本身或其第三方軟硬體所造成的狀況、用戶端到供應商網路連結問題等等業者無法控制因素列為排除條件，因此客戶在選擇IaaS服務時，應要求業者提供相關SLA條款，仔細閱讀及評估所要承擔的風險，SLA承諾的高低與業者的成本及風險承擔有關，由於目前仍缺乏公正單位來評價各IaaS業者的服務品質，因此用戶仍須謹慎評估，或者嘗試跟多家IaaS業者打交道，累積經驗以找到最合適自己或服務機制健全的業者。

政府應輔導業者並訂定SLA共同定型化契約

目前IaaS業者的SLA文件，看起來有一些大致的脈絡或類似的用語，但整體而言，仍欠約標準化的制定，這也造成客戶再審閱各家業者SLA的困擾，即使許多業者都用uptime來當作統計指標，但關於uptime指標的定義卻要仔細閱讀SLA文件，才會知道到底如何認定，若再考量IaaS業者的排除條款裡面隱藏許多文字遊戲，則SLA文件真是成為用戶的夢饜，難以看懂，也難以申張權益，因此，未來政府如要推動雲端產業，應該輔導業者並訂定SLA共同定型化契約，幫助用戶更容易看懂，也更容易保障權益，如此才能消弭障礙，有利產業的長遠推動。

此外，為有利雲端產業發展，市場分析機構或媒體機構也可嘗試進行IaaS服務的客觀調查分析，透過分析比較，幫助需求端更容易來選擇及找出適合的IaaS服務供應商，不僅可以加速用戶的決策程序，也可藉此提高IaaS的服務提升意願，加速服務能量及市場信心的整體提升，有利於整體產業的正向成長循環。

公有雲應即時揭露可用性、效能、客戶服務等指標

以上的探討多針對一般商業IaaS服務的情況，針對國內公務單位所要推動的公有雲服務，在基礎架構部份仍可訂定「可用性」及「效能」等評估指標外，並可進一步要求各公有雲公開各相關指標的即時資訊及狀態，隨時瞭解公有雲的服務及效能情況(「透明度」)。

近來政府努力作為，期望讓民眾有感，因此在公開資訊的部份，還可再加上問題回應時間及問題解決時間等「客戶服務」指標。幫助公有雲的推動，朝向為民眾服務的大原則來發展，而非僅為發展技術或整合資源，如此民眾也不致擔心政府官員總在雲深不知處。

雲端服務等級協議初探(1)

Service Level Agreement(簡稱SLA)一般翻譯成「服務等級協議」(或「服務層級協議」)，不管如何翻譯，都代表服務提供者應與使用客戶之間，就服務品質、服務水準以及效能等方面訂定協議或契約。以保障客戶使用服務後的權利，也作為服務收費的客觀依據。

目前國外的IaaS服務業者針對所提供的雲端服務多半都會提供SLA，知名業者Amazon即針對EC2及S3分別定義了SLA，EC2的SLA(網址)保證為每年的Uptime百分比至少為99.95%，99.95%代表一年當中最多發生4.38小時的當機時間(Downtime)，並且不包含因為正常維護所公告的停機時間在內。透過這樣的資訊，使用Amazon服務的客戶，可以瞭解使用Amazon EC2所需承擔的風險，以及最壞狀況，並自行評估是否轉而使用能提供更高保障，但收費相對較貴的其他IaaS服務。

Amazon針對S3所定義的SLA(網址)與EC2的SLA略有不同，S3的SLA為以月為統計周期，並提供每月Uptime百分比至少99.9%的保證，99.9%代表每月發生downtime的時間不超過43.2分鐘，此外Amazon目前還針對CloudFront提供SLA保證，但此外其他許多服務，則都還未提供SLA保證的資訊。

有些業者為了與Amazon區隔，也為了行銷目的，提供所謂的100.0%的SLA保障，其實沒有業者敢保證自己的IaaS服務都完全不會有downtime，但IaaS業者認為客戶重視的是系統可以多快回復正常，因此用客戶的角度思考，認為客戶要求的SLA應該是100%，但若發生downtime問題時，IaaS業者應該承諾補償，Rackspace的SLA(網址)就強調發生downtime問題時，將於1小時內找出問題，並針對每一小時Downtime減免5%費用，另一家業者GoGrid (網址)也強調100% uptime保障，並提供100倍Credit Back (GoGrid號稱10,000%的保障)，賠償金額甚至可超過客戶所繳的費用。

國外IaaS業者除了公布SLA的資訊及承諾外，有些業者也進一步公開各項服務的即時監控資訊，以提供客戶了解當問題發生時，到底是IaaS業者的服務出問題，還是自己的應用系統出問題。Amazon針對AWS(Amazon Web Service)即公告即時的Service Health Dashboard (網址)，用戶可從這個網站即時了解各個區域的服務是否正常，其他案例如Netsuite Status (網址)、CloudHarmony Benchmarks 提供的第三方監測服務 (網址)。

綜觀上述案例，IaaS業者的服務為雲端服務中最基層的服務，IaaS業者的服務等級就影響了SaaS業者的服務承諾，SaaS業者承諾的SLA一般都會比IaaS的SLA低，這裡包括了SaaS業者無法控管的IaaS服務Downtime，因此SaaS業者可能會把服務分散到多個IaaS業者，避免雞蛋放到同一個籃子裡，但這樣的架構也增加管理的複雜度，營運成本更著提高。

國內IaaS業者目前多尚未提出標準化的SLA，中華電信HiCloud號稱提供99.9%的保障(根據研討會的資料，但官網未公告SLA)，業界間偶有hicloud發生downtime的傳聞，外商微軟的雲端服務也針對雲端服務、雲端儲存服務、雲端CDN等提供SLA(網址)，對於國內的SaaS業者而言，現行國內IaaS服務在保障及承諾方面仍不夠完整，有些業者因此選擇把服務架構到海外的IaaS服務上，但須負擔較高的資料傳輸成本。

國內在推動雲端產業的同時，建議政府應該加強輔導IaaS業者推動SLA制定及服務能量的提升，才能確實幫助SaaS產業的發展，否則在先天不足(市場不大)、後天失調(IaaS服務不穩)的情況下，許多客戶對於雲端應用失去信心，將造成推動困難，政府的雲端計畫變成官方(公務雲)的獨腳戲，但實際上雲端產業卻難以發展與扶持、前景困難重重。