台達電子雲端技術中心資深處長翟本喬：企業軟體要上雲端必備的3大關鍵

台達電子雲端技術中心資深處長翟本喬曾為Google研發省電伺服器，目前正在開發台達電自家的雲端服務平臺。翟本喬認為，企業若要將自家軟體移轉上雲端平臺，必須把握3大關鍵來實踐軟體即服務（SaaS）平臺的彈性，達到快速甚至自動化地開關、伸縮與搬移，而且不受底層故障或不相容的影響。在應用上，SaaS平臺不再以獨立運作的單套軟體為中心，所有軟體功能及其功能元件都轉化為一個個服務窗口，環繞著使用者，透過API介面進行協同合作來完成使用者的任務。

真正要實踐這樣理想的SaaS平臺，在單套軟體與整體系統架構都必須符合雲端的概念。首先，SaaS平臺上的單套軟體都具備了Scale-out與容錯的能力，以充分發揮雲端兼顧高彈性與穩定的效益，而所有應用集結而成的SaaS平臺，整體的系統架構設計是高度模組化的服務導向架構（SOA），因而能打通個別應用的大門，讓所有功能元件沒有上下層級之分，都能在同一水平互相介接存取，以使用者為中心來提供服務。

關鍵1：要能Scale-out

在翟本喬的心目中，理想的雲端平臺要能讓企業Pay as you grow，企業使用這樣的雲端平臺時，不必理會每臺虛擬機器（VM）的規格大小，或要買多少臺VM才足夠，企業只要將軟體丟上雲端平臺，此平臺就能按軟體的負載量變動，來自動增減資源用量。

好比企業從頭到尾只用了一臺能彈性伸縮的VM，否則企業每次在軟體負載量攀升時，還要考慮將整套軟體搬到更大臺的VM，如此又會重回傳統Scale-up的觀念。

企業要實現Scale-out軟體，不只是IaaS和PaaS底層架構的協助，上層應用軟體也要設計為分散式運算架構，來支援負載平衡功能，才能做到Scale-out，軟體能夠Scale-out，才能充分發揮雲端平臺自動擴充資源的效益。

翟本喬表示，目前絕大多數軟體應用都偏向執行交易（Transaction-based）的需求，如訂票系統、一般網站服務等，每筆交易與服務要求（Service Request）的關聯度不高，很適合設計為分散式運算架構。透過分散式運算的設計，這套應用就能支援負載平衡功能，將過剩的負載量移轉到別的機器，可及時Scale-out。

然而，許多企業會用虛擬化軟體的vMotion或Live Migration功能，將負載量過高的應用系統從小機器搬上大機器，這樣只做到了Scale-up，與雲端訴求Scale-out的概念背道而馳。「企業真正需要的是負載平衡功能，而不是vMotion或Live Migration。」翟本喬坦言。

當企業設計分散式運算的軟體架構時，必須讓每臺機器都能互相溝通，合力完成軟體設定的任務，不會有特定任務必須交給特定機器執行的情況。翟本喬打了一個比方，一個大型的巨蛋運動場設立了數百個入口，每個人都必須拿門票於入口處驗票才能入內，每個入口處如同執行任務的機器，每次的驗票工作就是任務或稱為交易。

如果管理員開放所有入口處都提供驗票服務，容易發生不同入口重複放行拿了同一張票去影印的觀眾。為了避免分散驗票的作法造成重複放行的問題，以傳統的作法來說，巨蛋管理員只會開放單一個入口處進行驗票，因此降低驗票的速度。

翟本喬表示，正確作法應該是數百個入口都同時開放驗票，當A入口處查核過一張票後，必須通知其他所有入口已查核過此票，若其他入口又查到此票，就不許放行，其他入口收到A入口的通知，也必須發布已知此消息的回應。如此一來，所有入口就能同時驗票，且不會出錯了。更重要的是，當特定入口擁塞了過多人潮，還能將這些人潮移轉到其他入口，以分攤工作量，這就是分散式運算可達到負載平衡的好處。

這項驗票的例子呼應了企業設計傳統與雲端軟體架構的不同：傳統軟體往往有一個核心的集中式模組，底下延伸出許多子模組，建構起階層式且垂直林立的軟體架構，所有子模組必須經過上層的集中式模組，才能繼續工作。例如，所有元件都要存取同一套資料庫，這個集中式模組因為難以將工作量分攤給其他模組，容易成為整套軟體無法Scale-out的瓶頸。翟本喬表示，企業設計雲端軟體架構時，必須時時把握去中央化的概念，這樣的軟體才能Scale-out。

關鍵2：建立容錯機制

為了讓雲端軟體在動態Scale-out的過程中，仍能夠兼顧穩定性，雲端軟體還必須具備嚴密的容錯機制。此外，雲端平臺的龐大規模，也促使企業必須打造具備高容錯能力的軟體，因為雲端平臺上的軟體正在存取的資料或執行的任務，通常不知道現在正在哪臺機器上，任務可能隨時動態移轉到不同機器來執行，軟體在這一秒沒有存檔，下一秒這個檔案的儲存空間可能就被其他檔案複寫掉。以前IT人員尋找資料存放的磁區再復原的作法已不可行。

企業若要讓雲端軟體完全不受底層平臺影響，在最初設計軟體架構時，就必須把握容錯的觀念。容錯的核心觀念是讓軟體在執行程式的途中，在任何狀態下都要能夠挽救。

翟本喬舉了一個例子，當使用者編輯完檔案，要存檔時，系統若將舊檔刪除，再寫入新檔，那麼從刪除舊檔到存完新檔的過程，就可能遺失檔案，萬一新檔存到一半當機，使用者就會失去這筆檔案而難以挽救。正確的軟體容錯機制應該是，使用者替正在編輯的檔案以不同檔名開設成另一個新檔，同時保存舊檔，當使用者完成編輯後，先存好新檔，再將新檔復寫到舊檔上，萬一新檔或舊檔在編輯或讀寫過程當機，都還有另一個檔案存在，不會無法挽救。翟本喬指出，企業設計雲端軟體架構和程式運作程序時，也必須把握類似的容錯觀念，讓軟體隨時都能被挽救。

關鍵3：SOA系統架構

Scale-out與容錯是單套雲端軟體的關鍵特性，若是從整套的SaaS平臺來看，企業整體的系統架構設計必須符合雲端的精神，盡量設計為高度模組化的SOA架構，才能讓軟體實現任意開關、動態搬遷等雲端的彈性。「雲端時代的開發趨勢，就是SOA架構。」翟本喬說。

傳統企業軟體架構會依據不同部門來建立軟體，如財務、法務、人資、工程等在不同部門之下的軟體，個別軟體之間都是垂直並立或上下階層的關係，當使用者要跨部門取用不同軟體時，就必須自行前往個別軟體來使用，或在不同軟體之間的資料庫互相匯入和匯出資料。這樣的使用經驗是以軟體為中心，使用者必須掌握軟體之間的關係才能完成任務。

例如，每個月人事單位必須匯出人資系統的資料，再匯入薪資系統，才能計算出每位員工的薪水，若薪資系統改版或更換廠牌時，人資系統可能面臨資料格式不同或系統不相容等問題，而無法完成任務。

SOA架構可以解決這些問題，建立以使用者為中心的SaaS服務平臺。翟本喬說明，在SOA系統架構下，個別軟體當中的每個軟體元件都是服務，每個服務都提供API介面，開放給其他軟體取用，即使底層平臺執行服務的方式改變了，也不影響服務的運作。

此外，每個軟體元件具備無狀態（Stateless）的特性，每項任務要求傳遞給軟體元件時，該元件只在處理此要求時，會記得處理狀態。一旦將處理結果移交給使用者後，此元件就會忘記這項要求。藉此，這套軟體就能在沒有任何要求的狀態下，可隨時關閉和搬遷。

這樣的SOA架構做到極致，就能夠打造出以使用者為中心的SaaS平臺。因為每套軟體的功能元件都釋出了API介面，如同打通了個別軟體的大門，大門裡，所有元件都轉變為一個個的服務窗口，讓軟體與軟體之間、功能與功能之間能任意介接存取，彼此不是階層式的上下關係，而是同在一個水平面上的協同合作關係，協力完成使用者交付的任務。

此SaaS平臺可依據使用者的任務，串連起原本個別軟體的功能元件。例如，當企業要建立網路購物服務，SaaS平臺可透過API介面結合信用卡付款、美工編輯、貨運服務等不同功能元件，串連出這項服務。又如，每個月人事單位不必匯入和匯出不同系統的資料，人資系統會透過API介面自動存取薪資系統的年資和部門別等欄位的資料，自動計算每位員工的薪水。

翟本喬建議，現在企業還擁有許多傳統的軟體，不必急著一次轉換為雲端軟體，可以等到軟體自然汰換時，再把握Scale-out、容錯與SOA架構來開發，而企業目前正在開發的新軟體，就應該把握這3大關鍵來設計，才足以稱為雲端軟體。

改變軟體架構，而不是改變開發方式

以開發團隊的運作來說，翟本喬認為，企業不需要改變開發方式，要改變的是軟體架構設計，運用Scale-out、容錯與SOA等觀念來設計架構，軟體元件也要API化，這樣就能打造出SaaS平臺。

相關報導請參考「2012企業雲端開發術」