本地部署時代

在軟件還是“本地部署（on-premise）”的時候，SaaS的版圖被大型玩家把持著，幾乎所有的垂直領域（營銷、支持、銷售、人力）都被微軟、SAP等大公司的解決方案占據。那時候的用戶並沒有什麽“軟件棧”可供選擇。

第一代SaaS冠軍

隨著互聯網的不斷普及，SaaS模式開始發揮作用。第一代純“SaaS”玩家獲得了很好的發展勢頭。這些玩家提供的是垂直化而非水平化方案，滿足了垂直領域的諸多需求。

而用戶開始有了更多的選擇。

SaaS的第一次爆發

隨著SaaS日益普及（即企業無論大小都已準備好購買SaaS），以及技術門檻的不斷降低，許多垂直領域湧現出了許多新的玩家。這些新生初創企業往往聚焦於某個垂直領域的特定部分，相對於更大的老玩家提供了更好的UX/UI。

此時用戶開始需要思考自己的SaaS技術棧構成，需要想清楚應該用什麽。

現狀

主要的SaaS垂直領域已經開始變得人滿為患。從大型玩家到中小型甚至微型SaaS（只是更大型SaaS的“擴展”或“插件”的SaaS）層出不窮，用戶的選擇變得數以百計甚至數以千計。

隨著大家把越來越多的SaaS追加進自己的技術棧裏面，軟件互連、數據遷移、技術棧管理、工作流集成、體驗定制等工作的痛苦也與日俱增。

於是新的混合型產品/方案開始浮現，試圖填補這些缺口：

垂直型SaaS中樞（Vertical SaaS Hub）：把用戶技術棧的差異集中化，以便更好地進行管理。此類中樞會聚焦於某一個垂直領域上面。

例子：營銷域的 Lytics以及支持域的elev.io。

解綁定API（Unbundling API）：把SaaS打包為API而不是傳統的完型產品，這樣用戶可以根據自己的需求打造自己的UX。

這是一種開發“內部”產品（而不是重新發明輪子）或對現有技術棧做出補充的有趣辦法。

例子：營銷域的Clearbits以及支持域的supportive.io。

客戶數據層：segment.io是“收集、管理以及引導客戶分析數據的單一中樞”。工作機制：你把你所有的客戶數據（通過javascript標簽）傳給segment.io，後者再路由給你使用的SaaS。這樣你的客戶數據就集中化到一個層上面，可以無縫地從一個服務遷移到另一服務，或者通過同一客戶數據連接不同垂直領域的軟件。

命令&通知層：棧裏面有很多app的時候，有個問題是你希望不需要每次都要登錄上去才知道應用情況。Slack就是通知層（你可以把SaaS插入到Slack以便可以直接接收通知）。你還可以直接從Slack界面發起動作。就像命令行一樣。比方說“/hangout”發起Google hangout就是例子。

補充

橫向層

個人認為segment.com對於SaaS生態體系來說是一個重要產品（Slack已經很大了）

會有新的層出現，但是出現什麽樣的層未知（發現層？單點登錄層？安全層？……）

對於SaaS制造商的影響

對SaaS制造商來說，通過相關橫向層提供集成開始變得重要（比方說必要時進行細分領域或Slack集成）

客戶點擊2下就能夠從你的產品遷移到競爭對手那裏，你也許不喜歡這個，但客戶是不會在乎的。如果你不提供這項功能的話一開始他可能就不會選擇你。

SaaS中樞

這些中樞可以僅僅是“界面”中樞（參見 elev.io），或者提供與現有棧的更深層面的功能集成，像 Lytics。“中樞”的概念很寬泛，你可以同時使用幾個中樞。

這些中樞也會與橫向層進行連接。Lytics和elev.io都有跟segment.com的集成。

隨著技術棧的不斷壯大，會有越來越多新的混合產品和方案的出現。預期未來幾年一切都會不斷演進和變化。

推薦閱讀：

用kafka實現消息推送

大數據Spark與Storm技術選型

華為Java編程軍規，每季度代碼驗收標準

你可以不懂但一定要知道的代碼審查 Code Review

6 個重構方法可幫你提升 80% 的代碼質量

SaaS技術棧的走勢