沒有人否認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産品了。他們如何将現有的資料導入進來?如果你說“手工錄入吧”，你已經邁出了錯誤的一步。資料導入工具允許使用者以一種正确的方式開始使用應用，并且建立了一種快速的資料內建的能力。你不僅需要提供簡單的資料導入能力，還需要相同簡單的資料導出應用的能力。雖然你很自然的希望鎖住你的客戶，但你讓簡單的內建變得更困難的同時也在傷害你的客戶。
花一些時間來考慮如何讓你的客戶(或者潛在客戶)更容易評估、購買和快速使用你的産品。
本文作者：佚名
來源：51cto