軟件即服務(SaaS)在云計算中扮演的角色 |
發布時間: 2012/8/3 17:04:41 |
想要知道軟件即服務 (SaaS) 在云計算中的扮演的是什么角色嗎?本篇文章將探究不同風格的 SaaS,并給出兩個 SaaS 如何在按需付費的云計算環境中工作的例子 —— 工廠工程管理和遠程學習。通過結合多租賃和虛擬化的優點對 SaaS 進行性能調優。尋找針對未使用資源和互操作性問題的解決方案。最后,如果沒有恰當的計劃和實現,安全性防護的成本將遠遠超出 SaaS 和云計算的價格優勢。 如果使用過 Amazon Web 服務,您一定會對 SaaS 在云計算中扮演的角色很感興趣。好消息是您可以基于這些 Web 服務開發 Web 感知、云友好的 SaaS。您可以將這個 SaaS 銷售給許多用戶,比如顧問或產品工程師,并通過更實惠的按需付費方式減少提前購買軟件的成本。另一個好處是 SaaS 在一個集中的位置提供更新,避免經常下載補丁和進行升級。 在本文中,我將向您展示 SaaS 和云計算之間的異同,并討論 SaaS 在云計算中扮演的角色,以及展示它與效用計算和平臺即服務(Platform as a service,PaaS)等其他形式的云計算的巨大差別。我還將給出服務類別和應用程序示例,探討關于結合多租賃和虛擬化的內容。然后,我將論及未使用的資源和互操作性問題,并提供一些相應的解決方案。最后介紹測試 SaaS 在云計算中的執行情況所需的條件,以及 SaaS 在安全性方面的問題。 SaaS 已經非常成熟,可以看作是 mashup 的一部分,或是 PaaS 產品或基于 Internet 的服務的一個插件。它提供開箱即用的應用程序,比如企業資源管理或工廠工程管理。不管您身居何處,都可以從 Web 瀏覽器訪問這個應用程序。 SaaS 服務的完善得益于服務器和磁盤上的虛擬平臺軟件。服務完善程度僅次于它的是 PaaS 和基礎設施即服務(Infrastructure as a Service,IaaS)。服務完善程度最低的是基于 Internet 的服務。PaaS 在磁盤上運行 API 和虛擬平臺軟件,而 IaaS 則通過 Internet 提供了一個完整的計算機基礎設施,并僅為 Amazon EC2 和 IBM Blue Cloud 等的用戶提供了服務器虛擬化。Amazon S3、Amazon Simple DB 和 Google Base 等都是基于 Internet 的服務。 我們可以構建一個完善的 SaaS,工廠工程公司可以利用它改進生產周期,以及為商品采購、銷售和財務交易提供保障。這個 SaaS 還能幫助決定生產轉包中的容量計劃所需的業務流程。它的用戶群很大,可以是廠長、質量經理、生產線管理員、COO 和 CFO。 主管人員不僅可以利用 SaaS 在按需付費的訂閱環境中訪問數據,他們還可以借助它在財務、工廠工程、生產周期、供應管理和人力資源計劃方面做出關鍵決策。SaaS 可充當制造型工廠的決策者的經營業務智能工具。比如,通過 SaaS 提供的工具可以為決策者提供原料處理時間、生產周期時間和設備更換時間的理想指標。這些工具還可以給出分析,并在某個指標沒有達到理想指標時為決策者提供補救措施。 我們可以將一個培訓程序構建為 SaaS。DigitalChalk 的 SaaS 模型專門針對大學或企業客戶,幫助他們通過 Web 站點傳輸培訓內容(包括遠程學習)。在構建這個 SaaS 時,它創建了自己的 Amazon Machine Image (AMI) 并使用 Amazon S3、EC2 和 SQS,而不是使用數據中心。 要開發其他的 SaaS 服務,可以使用 EC2 將要運行的 IBM AMI。其中包括 IBM DB2、IBM Informix、IBM Websphere Smash 和 IBM Lotus Web Content。要擴展 AMI 存儲庫,可以使用預先配置好的 AMI 模板,也可以創建一個包含有應用程序、庫、數據和相關設置的 AMI。 Microsoft® 將 SaaS 分為兩類:面向企業的服務和面向個人消費者的服務。這兩種服務均可通過訂閱購買得到。面向企業的服務是用于金融、供應鏈管理及客戶關系等方面的、基于按需付費的大型定制商業解決方案(例如,工廠工程管理)。面向個人消費者的服務的目標是不需要他們付費,而是依靠廣告支持獲得收入。 由于這兩種分類仍然很有限,我這里再增加兩個種類:共享資源服務和 外包服務。共享資源服務在一個用戶池中分發服務,能夠讓大型公司以很低的成本能獲得峰值的負荷容量,減少了對大型內部數據中心的需求。外包服務則讓中小型企業可以通過完全外包數據中心基礎設施的方式提供服務(比如,遠程學習)。 除了面向個人消費者的服務外,只有企業向大量客戶提供服務時,才可能有收益。因為只有客戶群足夠大,按需付費訂閱的低收益才能彌補基礎設施的高成本 — 它不像效用計算那樣按使用率來收費。除訂閱外,收入來源還有介紹費、交易費、基于消費的定價、基于性能的定價、轉銷收益及收入分成。 每個示例都顯示 SaaS 的三個屬性:可配置性、可伸縮性及多租賃效率。如果 SaaS 不具備一個或多個這樣的屬性,那么這個 SaaS 就是不成熟的。為了獲得更靈活的系統最佳性能調優,可以將多租賃與虛擬化相結合。 多租賃是指一種軟件架構,在這種架構下,軟件的單個實例作為一個 SaaS 運行,服務于多個客戶組織(租戶)。對于這種多租戶的架構,數據和配置被虛擬分區,以使每個客戶組織都能處理一個虛擬的應用程序實例。通過合并單個操作中的 IT 資源,多租賃節約了成本。 多租賃的一個缺點就是當用戶的基數很小時,它也要占用大量的內存和進行大量的應用程序處理。當用戶基數很大時,由于負荷可以在多個用戶間分攤,就克服了這個缺陷。多租賃的另一個缺點就是構造一個高效的多租賃應用程序可能需要額外的編程,這就增加了開銷。 SaaS 架構中的服務器虛擬化不局限于多租賃的數據和配置虛擬分區。虛擬化的好處之一就是它能通過動態調整實際服務器的數量以及資源的合理大小(包括存儲和數據庫資源),從而提高系統的容量以滿足需求(比如在 12 月份購買會增加)。不好的一面是,由于虛擬化軟件互操作性方面的問題,虛擬化后的服務器有可能不能從一個廠商轉移到另一個廠商。 運行在 Web 服務之上的 SaaS 利用 SOA 在軟件應用程序之間進行交互。每個軟件服務均可充當一個服務提供者或請求者。SaaS 服務提供者通過公共代理向其他應用程序公開其功能。SaaS 服務請求者合并來自其他服務的數據和功能。二者均在 SaaS 服務的部署和管理上因經營規模擴大而得到節約。 不管資源是否缺乏,Web 服務通常會松散地耦合。要確保用于服務器提供者和請求者的資源在容量隨需求上下波動時不會被浪費,需要創建一個具有耦合開關的 Web 服務以配合 SaaS 應用程序。當 Web 服務收到一個告警表示其對應的資源已經達到特定的浪費級別時,這個開關就會從松散耦合倒向緊密耦合。 如果您的 SaaS 是 Web 感知、云友好的,公司可能會發現很難對不同的廠商運行同一個 SaaS 應用程序,因為這些廠商可能具有不同的導入和導出數據的格式。考慮這樣一個場景:假設您有兩個 SaaS 應用程序需要 mashup。一個在某個廠商的云計算環境中使用了行業標準 API。另一個則在另外一個廠商的云計算環境上運行了專有 API。不經過某些修改,這種 mashup 將不能工作。 首先必須解決這兩個云計算廠商間的可移植性問題。這兩個廠商是已經允許兩種環境之間的通信,還是必須要對二者間的數據進行處理?這兩種類型 API 的數據格式和邏輯是兼容的,還是必須要重新格式化兩個應用程序間的數據或更改邏輯?目前,還沒有 API 導入和導出數據的相關標準。不過,IBM 和 Amazon 正在共同努力以使互操作性和 mashup 更易于設計和管理。 作為軟件開發的一部分,測試可以確保云計算和 SaaS 能正常工作。為了提高服務質量,也需要進行 SaaS 服務和應用程序的測試。為了開始測試,需要仿真終端用戶環境,比如多個 Web 瀏覽器、操作系統和網絡連接性。沒有這些條件就不是一個好開端。例如,一個 Web 瀏覽器有的特性,另一個瀏覽器可能沒有。特性的缺少有可能會影響用戶訪問云計算中的 SaaS 服務的方式或者未使用資源如何處置的方式。 接下來,測試是否有多租賃漏洞,比如由于軟件漏洞,用戶 A 得以假冒成用戶 B。其他需要進行測試的還有:在系統負載正常的情況下,用戶使用的擴展范圍是多少。在按需付費的環境中如何最好地管理專有密鑰。云中的大量數據應如何備份和存儲。在 SaaS 模型中,版本控制和更改管理并非客戶行為,但必須對其進行須測,以確保它們能被充分驗證。同樣重要的是要測試 SaaS 是否滿足垂直需要,因為 SaaS 是一個水平應用程序。 要記住,與部署于典型的數據中心環境中的產品相比,云中的 SaaS 產品有著不同的部署和使用條件。因此,基于云的應用程序的測試要求也是不一樣的。例如,SaaS 產品可以在用戶不知情的情況下被更改。由于集中化的管理使進行微小更新變得更為容易,SaaS 部署模式的發布與其他模式相比更為頻繁,因此 SaaS 產品的客戶支持周期更短些。然而,如果不經過充分測試就頻繁進行更改,這種短的發布周期就會給用戶造成很大的麻煩。 購買、維護與運營測試所需基礎設施成本非常昂貴。在 SaaS 基礎設施不斷增長時,設置功能、回歸、性能和壓力測試的成本肯定不會低。在一個 SaaS 產品最終發布前,需要建立 Alpha 和 Beta 測試環境來獲取潛在用戶的反饋。因此,提前計劃并贏得一個大的市場份額至關重要,只有這樣才能從價格低廉的訂閱中實現盈利,并且抵消昂貴的測試成本。 在按需付費的基礎設施中,災難恢復、專用密鑰管理和控件行為公開是 SaaS 環境中的主要安全性顧慮。如果不進行適當的計劃和實現,那么安全防護的成本很可能會遠遠超出 SaaS 及云計算的經濟優勢。 在 2008 年初 Amazon 的 S3 和 EC2 遭遇了一次三小時停機后,針對災難恢復提前進行計劃就顯得尤為重要。在停機期間,用戶錯過了很多銷售機會,主管人員也無法訪問關鍵業務信息。停機所產生的影響要遠遠超出了一個 SLA 所提供的數據恢復和服務信用。 在沒發生停機之前,用戶不妨自己進行安全性測試,以檢查 SaaS 供應商是否可以很快地恢復數據。這個測試很簡單:只要給供應商發一封電子郵件索要您的存儲數據,并檢查此供應商恢復這些數據要花多久。如果恢復所需時間太長,請詢問此提供商其中的原因以及您在其他的情形下可以獲得多少服務信用。即便恢復大量數據所需的時間很短,也要驗證校驗和能否與原始數據匹配。另外,還需要在高峰時和低谷時測試災難恢復。 測試一種可信算法來加密您看得見的本地計算機上的數據,然后再用解密密鑰訪問您在云中看不見的遠端服務器上的數據。這個測試非常必要。如果試圖訪問數據時無法讀取數據,原因之一是解密密鑰無效,原因之二是遭服務器拒絕,因為此提供商使用的是自己的加密算法。請詢問您的提供商它所使用的是哪種加密算法。 云中的數據也可能存在一些問題。要保護數據,最好是管理自己的專用密鑰。請咨詢提供商有關專用密鑰管理的相關信息。如果在 Amazon 上注冊,它將會給您這種證書。 并非所有提供商都愿意公開它在 SaaS 環境中是如何管理控件行為的。有些提供商具有審計其控件行為的策略。 請詢問您的提供商在向用戶公開控件行為和過程時使用的是不是 SAS 70 Type II 認證。這種認證可以確保數據中心(包括云計算內的訪問和鏡像數據中心)具有完善的更改管理文檔、備份和恢復需求、災難恢復需求以及物理級安全需求。如果它不是認證的,那么就要詢問此提供商如何能夠獲得它管理控件行為方式的信息。如果您對您的提供商的程序質量很滿意,那么就無需這種認證。 本文幫助您規劃云計算中 SaaS 的開發和管理。用戶希望通過廉價訂閱按需付費的基礎設施來獲得服務,這為開發人員和項目團隊中的其他人員帶來了挑戰。認識并解決開發和管理 SaaS 的問題,包括潛在的安全性問題,能夠讓您的團隊免受麻煩的干擾。使用 IBM Rational Web Developer WebSphere Software 和 IBM Rational ClearQuest 發現缺陷并跟蹤使用 IBM AIM 構建的 SaaS 應用程序可以實現這個目標。
本文出自:億恩科技【www.laynepeng.cn】 |