Ruddy Lee 分享空間

Emergent Design 演化設計

Hybrid cloud –The real world cloud computing

leave a comment »

A hybrid cloud is a cloud computing infrastructure composed of two or more clouds that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability。

Hybrid Cloud是在不同的雲端(公有雲、私有雲及個人雲)之間混合著進行資料的傳遞、呼叫及進行應用程式的運算。靠的是甚麼呢? 無論是採用如日中天的Restful API 或是有些過時但卻能處理複雜運用且持續撐住一片天的HTML都成。

Why hybrid cloud?

Hybrid Cloud的主要由來是來自客戶的需求;由於需求的多變性造成他們需要有著不同的架構來達到不同程度的要求(難的地方在資料該存於何處,運算該在哪裡進行,規劃錯誤就慘了)。在這裡我想談的是一種能夠解決上述問題的架構。先細分一下,企業上的Hybrid Cloud就是介於公有雲與私有雲之間的運作。而公有雲與個人雲之間或是私有雲與個人雲之間的運作則可稱之為Personal Hybrid Cloud。我們縮小一下範圍,這裡我們先來淺談個人混合雲Personal Hybrid Cloud的解決方案。

其實怎麼做都成

在運用雲端服務的時候(混合雲的解決方案中);架構師經常會遇到一種決策性的問題,那就是:應該把重心放在本地端還是雲端,應該採取thin client 還是fat client。有時你會有些迷惑不能肯定該怎麼作才對,建議你在分析上;應該試著採用三層式的架構來探討,隨後在視需求來實作架構,這樣便可以大大的縮小複雜的程度了。

我們由下圖來看一個混合雲的典型通訊方式: 透過運用Service相互呼叫的方式形成典型Hybrid Cloud System.

跨不同的雲端系統進行作業;這是一種十分複雜的資訊交互運作,與你經常運用手機連接到雲端;然後輕鬆存取存在雲端上的資料形式是不能相比的。舉個例子來說,就好比運用Google 做搜尋時;準確度的要求是幾乎只要搜尋得到;有找到資訊就可以了。這跟你在銀行領錢一毛都不能少是完全不能相比的。也好比開發純粹娛樂性質的軟體與開發企業運用的應用程式,二者在精確度的設計上真是無法比擬一般。

圖一、運用Service相互呼叫的方式形成典型Hybrid Cloud.

這個圖看起來有些複雜,它在描述公有雲與個人雲之間或是私有雲與個人雲之間的運作。但其實就是透過相互呼叫Service的方式來達成雲端與雲端、或是既有系統與雲端之間的資料傳遞或應用程式的分享。典型的Hybrid Cloud解決方案就是運用這種方式來達成的。當然你可以運用瀏覽器的方式來存取雲端的資訊,但是在處理hybrid cloud 時大半是以restful API 的方式;並透過專屬的應用程式為主。

這個Client/Server的通訊模式是二層式的架構,(這裡所謂的client指的是mobile devices也就是所謂的smart device,Server則是public cloud) 。如果傳遞的資料量不大而且你的需求可以維持十分單純的資料傳遞方式的話,這倒是一個乾淨的解決方案。但若要充分運用雲端或本地端分散式資源的考量下,多層式的架構應該更能符合客戶多變的需求。

多出來的這層架構是甚麼呢?

是Station層,他可以是虛擬的雲端(Virtual Cloud)或是虛擬的本地端伺服器(Virtual Station)。這樣架構的目的是在針對需求來規劃資料存取的路徑及執行服務的真正位址。而不是一層不變的受限於通訊速度或是資料量的大小;然後綁手綁腳的很難做整體的設計。這種應用station層來促成資料傳遞、呼叫及運算時,能夠『順暢』的解決問題(我深深想信要能夠成功的實行混合雲的主要決定因素在於工作流程的順暢度上頭)。

順暢: 我沒有直接說效能,而改用順暢的意思是指,有時候我們會犧牲一些效能,而只是為了達成某些資料的存取及視覺上的需求。

一般採用smart device上的app 直接存取雲端資訊的方式, 是公有雲的一種標準的存取方式(如:Dropbox 的應用程式),但是它比較接近SAAS(software as a service) 的運用方式,對較需要本地端進行運算的需求就顯得稍為不足,所以需要一個中間層,來彌補這種不足的情境(服務層),我們可以稱之為 Station 層。藉著新增一個具有高度虛擬化彈性的station 層,讓通訊品質不佳時的3G使用情況下仍能順暢的運作,也能在只有本地端WiFi連線還可以的情況下還能讓應用程式正常的動起來。

上圖中,對照到Personal Hybrid Cloud的情境,在上層為隨時隨地都能存取得到的公有雲,中層為本地端俱有服務多樣化、呼叫反應快速的個人雲端(personal cloud)系統,終端則為ipad、android等智慧形裝置。左側是Virtual Cloud,右側則為Virtual Station。這樣的圖示剛好運用station層來協助你判斷該將資料及運算架構放在哪裡的思維。

為什麼要三層式架構呢?

目的是要針對不同的情境提供個別的最佳解決方案。因為某些時候服務運作在本地端會比在雲端要快上許多,但在其他情境下卻是完全相反。我深切以為我們開發應用程式時,無須墨守在雲端運行或是在本地端運行的原則,應該視需求改變而作調整(符合鬆偶合loosely couple的架構原則),至於資料應該存放在哪兒呢?就交給多出來的中間層吧!

舉例來說;在聚餐或是喜宴的情境下,3G的通訊模式可能是最便利的連線情形,當你運用手機替一大群人拍了照片;這個時候分享變成了首要的樂趣(你應該不會在喜宴上打開PC或Notebook來進行分享),所以此時智慧型裝置便成了主要的I/O顯示裝置,拍照的同時資料實際上已經妥善的存在手機(相機)中了,無需急著作上傳雲端完成備分的步驟。反而應該將這部份虛擬化,代替以將大小差許多的縮圖上傳到雲端(一般手機拍出來的照片大小約2~3M bytes,將它縮小成尺寸更小的縮圖),讓快速分享成為主角,供大家即時觀賞。將儲存的動作留到通訊品質好的時候再來進行。

相反的例子是在會議室中使用Smart 裝置進行分享的情境。此時可能會在擁有良好的WiFi通訊頻寬的環境下運作,這個時候應用程式的服務多樣化就會成為較大的重點,而不是一直在受限於等待雲端回傳訊息的情境。目的是讓Smart 裝置可以在暢通的Local 網路下快速的存取位於本地端的豐富資料或對資料在加工產出更有用的資訊。基於這種需求;與雲端的連線可以交給中間層(station層)來加以即時處理,然後再以批次的方式更新到雲端。這樣的情境就自然地衍生出虛擬雲端Visual Cloud 的架構。

架構一個三層式的系統來解決複雜的混合雲運算

資料該在哪裡?該由誰來執行服務?是虛擬化雲端還是虛擬化本地端的伺服器? 答案好像顯而易見,該在哪兒執行就讓他在那兒執行!拘泥於其中一種架構都容易讓程式寫起來顯得綁手綁腳的。新的一年的開始;若你正要做混合雲的架構設計,建議你;與其事後再來改變架構去符合需求,不如把傳統的二層式換成三層式的彈性架構。

你說這樣的設計是讓程式變複雜了呢?還是簡化了?其實我的原則是;該在哪兒執行就讓他在那兒執行

還沒說完;下一回告訴你,晚安!

Written by ruddyllee

2012 年 01 月 24 日 於 16:10:46

張貼於未分類

Tagged with

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: