沒有人否認SaaS是一個非常熱的話題。真的非常熱。2010年，Gartner指出95%的組織將增長或者維持他們在SaaS上的投資。根據GigaOM的數據，SaaS公司的估值要遠超過傳統軟件廠商的估值。當絕大多數的組織都在增加他們對SaaS的投入，很多組織也在考慮一種將他們現有應用以SaaS交付出來的模式。“SaaS你的應用”意味著什么呢?接下來的文章將重點介紹如何在現有應用基礎上創建(或轉換)成SaaS。在這篇文章里，我們將指出SaaS的關鍵判別要素，以及當你在規劃和架構你的軟件時你該考慮哪些因素。

ASP(應用托管)和SaaS的對比

“SaaS難道不是ASP模式下的產品和服務的重新包裝嗎?”對這個問題的回答顯然是“肯定不是!”，但在對比多個打上“云”標簽的產品時，你確實很容易弄混。公平的說，SaaS是對ASP引入的概念的擴展，但是卻有著非常明顯的差別。

我們快速過一遍兩種交付模式的差別。

從本質上來說，ASP替客戶運營軟件環境，而SaaS則讓客戶通過可擴展、自服務的方式租用他們的服務。

SaaS你的應用——確認架構

在一個應用能夠以SaaS方式交付之前，你必須評估它的架構是否可以支持。

無狀態的Web服務器：為了能夠清晰的支持橫向擴展和增加新的機器，構建Web服務器的時候必須要求他們不能有任何本地的狀態。Web服務器必須依仗一些共享的數據庫來保存他們的狀態。為了提供一個“面向云”的應用，如果你的Web服務器有本地的狀態，你就不可能支持一個無縫的、自動的彈性擴展。

沒有硬連接：如果你的應用服務器有一些硬連接(比如寫死的IP地址)作為數據庫或者服務器-服務器的連接方式，你在遷移應用到云端的時候肯定會遇到問題。這些問題不容易被發現，但是你務必要保證不同層之間都可以獨立的擴展，而不需要拆開層之間的連接。

可擴展的數據模型：如果你已經預見了特定客戶的定制化需求，這一點非常關鍵。是否允許用戶擴展現有的數據對象、增加新的數據結構、以及施加唯一的驗證邏輯?如果是這樣，那么就需要在設計數據存儲的時候設計一種方式，支持用戶的擴展。

多租戶的支持：這并不像想象中的那么直接。SaaS的一個關鍵原則是將多個用戶，或者租戶，放在同一個服務器或者軟件實例里面。這種模型的好處是軟件提供者可以獲得高效的運營，因為他媽呢不再需要為每一個用戶維護唯一的環境了。這一點同時意味著，多租戶可以在你應用的各個層次都發生作用。三個漸進的階段包括：

***階段：為每個客戶提供唯一的Web應用和數據庫。雖然底層的基礎架構是租戶之間共享的，也必須為每個客戶分割出唯一的應用環境。這個分割的好處是實現租戶之間的物理隔離(這在某些行業，如醫療行業，會很關鍵)，并且提供每個用戶按照自己定義的日程來升級的可能。這個雖然會和ASP模型混在了一起，但是一個有著好的架構、高度自動化的應用提供方式的軟件仍然可以讓這種交付模型變得持久。

第二階段：允許客戶共享應用(版本)但是維護獨立的數據庫。在這個場景下，軟件只需要安裝一個版本，但是每個客戶的配置信息提供了一個獨立的數據庫的連接方式。在這里，物理數據的分割仍然存在，仍然支持每用戶加密或者直接數據庫隧道，但是全部應用的維護變得更簡單了。

最終：實現像Salesforce那樣的模型，所有的租戶共享相同的應用版本和數據庫。數據在邏輯上實現隔離，但是共享同一套物理資源。

界面的配置：如果租用你軟件的客戶不需要做任何修改，那么顯然沒有必要暴露用戶驅動的配置點。但是，如果你希望用戶都以自服務的模式，獲得擴展數據模型、更改外觀、設置組織特定的流程、構建安全組和權限這方面的靈活性，那么如何設計你的應用來支持用戶驅動的配置變化將變得非常關鍵。SaaS的一個關鍵原則是“自服務”，不需要用戶致電服務提供商來實現任何更改。通過在你的架構中暴露一些可以支持的、用戶驅動的配置變更，你可以讓自服務變得更現實，進而讓支持的成本變得更低。

API：如果你不能提供API，那么你就不能成為真正的云端應用。沒有API的應用將逐步成為“煙囪”式的應用，變得更難集成或者以后更難管理。好的API的設計需要投入，但是卻能夠讓SaaS應用的客戶變得更能接受你的產品。

細致的考慮安全架構：顯然，當構建一個“共享托管”的應用時，安全是一個主要的考慮因素。在這里，“安全”指的是包括“你的身份是如何鑒權的”、“你的身份是如何授權的”、“靜態數據是如何加密的”、“傳輸數據是如何加密的”、“審計是如何實現的”乃至更多。理想情況下，你的應用允許通過SAML這樣的標準機制實現SSO，來讓用戶只需要記住一個賬戶和密碼就可以登錄不同的SaaS系統。

同其它云平臺的集成：雖然不是必需的，但云端應用如果能夠擁抱其他的云平臺，它們將變得更加強大。試想一下，如果你的SaaS應用能夠和Google Docs或者Office365實現集成會怎樣?如果你可以使用Facebook或者Twitter ID來實現身份的聯合呢?

以上的列舉還不夠全面，但希望能夠幫助你在將應用作為SaaS的模式提供出來之前，讓你重新審視一下你的應用是否適合SaaS化。

SaaS你的應用：找到應用托管的環境

你已經有了一個SaaS友好的架構。恭喜你。你如何以一種***可靠性以及最小支持代價的方式來部署呢?你需要找到一個成熟的IaaS提供商，并且提供一個有如下特性的、成熟和彈性的環境。

可測量的計費：按量使用是SaaS應用的關鍵特性，你需要確認你可以輕松的獲取按月的使用量。雖然你可以制定一個簡單的按用戶收費的價格策略(放棄了對類似存儲、帶寬和CPU之類的資源計費)，你的托管商為你的SaaS提供一個清晰的資源成本結構還是顯得很重要。

快速的水平/垂直擴展：對于特定的應用，你有時候會需要更多的處理能力，因此你會需要更多的RAM和CPU。但是記住，“云”和廉價硬件提供的橫向擴展能力是緊密相關的。你SaaS應用底層的平臺必須能夠保證能夠以自動和自服務的方式提供快速擴展的能力。

可訪問基于Web的安裝包：當需要擴展的時候，選擇自動構建新服務器的方式，而不要通過現有應用的鏡像來重新組合。如果你使用了VM快照，你將不得不在你需要他們的時候對他們進行升級和補丁，來保證他們可用。相反，如果你可以訪問到應用的源碼(或者Web安裝包)，你可以使用很多工具來快速構建新的服務器。

積極的監控：為了能夠支持海量的用戶，你的應用需要能夠對不可避免的、由于硬件和軟件問題導致的故障進行快速響應。你的SaaS托管平臺需要能夠積極的監控到它們服務器的健康狀況，不僅需要告訴你問題發生了，還需要能夠根據既定的策略采取行動(比如重啟服務器、讓故障服務器下線、增加更多的服務器等)。

全球部署的選項：SaaS軟件的一個價值就是它是在公共的互聯網上運營。這意味著應用有可能被全球的用戶訪問。如果你的SaaS應用要考慮到支持全球的用戶訪問，那么就需要選擇一個能夠在全球的數據中心提供服務的托管商。

一鍵部署：一個云應用的架構可能并不簡單。你的軟件可能會需要很多個前端服務器，一個Web服務層，分布式的數據庫，批量的任務處理系統，等等。如果可能，找到一個IaaS能夠提供將解決方案做成模板，并且支持一鍵部署的。

健壯的備份和恢復選項：災難總會發生。即使是***的云環境，在未知問題的發生時，也會毀掉一整個數據中心。你需要保證你的應用數據能夠及時(并且常規化)的保存在主數據中心之外的地點。容災的規劃是一個非常嚴謹的工作。理想狀態下，你的托管商需要在這個領域有很多的經驗，能夠提供權威的幫助和工具來提供可靠的能力。

一個架構優秀的應用，如果陷在了一個不入流的托管環境里，會導致你的客戶快速流失。除非你提供不可比擬的、必需的功能，否則你的客戶會輕松的轉投你競爭對手的懷抱。

SaaS你的應用—提供注冊、管理和計費服務

一個好的應用，托管在一個***的基礎架構上，剩下的就只是讓客戶來使用了。為了構建一個最小人工介入的、可持續服務的平臺，你需要提供如下的功能：

注冊頁面：這個太顯然不過了，但是你需要仔細的構建一種能夠讓客戶快速使用起應用的方式。如果你的注冊過程還需要讓客戶撥打一個電話，你已經錯了。

管理控制臺：前面我們提到了界面的價值，它能夠允許用戶對外觀或者功能進行一定程度的更改。不應該讓你的客戶通過一系列腳本或者REST API來實現這些配置更改，而必須提供一系列讓客戶查看和編輯這些數據的方法。比如，一個好的管理控制臺需要能夠支持安全角色設定(用戶創建)和計費服務。

數據導入/導出服務：恭喜你，有人決定使用你的SaaS產品了。他們如何將現有的數據導入進來?如果你說“手工錄入吧”，你已經邁出了錯誤的一步。數據導入工具允許用戶以一種正確的方式開始使用應用，并且創建了一種快速的數據集成的能力。你不僅需要提供簡單的數據導入能力，還需要相同簡單的數據導出應用的能力。雖然你很自然的希望鎖住你的客戶，但你讓簡單的集成變得更困難的同時也在傷害你的客戶。

花一些時間來考慮如何讓你的客戶(或者潛在客戶)更容易評估、購買和快速使用你的產品。