CaaS: 內容是新的基礎設施 Content-as-a-Service

內容是每家企業的必爭之地,根據 CMI 的數據報告,88% 的 B2B 企業每天至少產生一篇內容。內容正在成爲新的基礎設施,Content as a Service 可以被簡單理解爲一種 CMS(Content Management Systen,內容管理系統),但是和傳統的 CMS (如 Wordpress、Drupal 等)完全不同。傳統 CMS 聚焦於內容管理和創建網站(比如 Wordpress 提供的大量網站模版),而 CaaS 只聚焦於內容的生產,並以 API (應用程序編程接口)的形式向外提供服務,這些 API 可被二次編程,從而用於打印機、移動應用或者其他設備上。

在這篇文章中,你將瞭解到什麼是 CaaS 以及爲什麼內容是一種新的基礎設施。在你想要使用 CaaS 時,本文可作爲對比 CMS 和 CaaS 優劣的參考文章。我們還會羅列一些 CaaS 的使用場景,幫助你更好的瞭解 CaaS。

內容是新的基礎設施

互聯網上的所有應用都是信息管理軟件,這些軟件在本質上是由一張張互相聯繫的表組成的(如果你不理解這句話,那麼你可以將一個網站想象成三張 Excel 表,一張表存儲網站用戶,一張表存儲網站內容,還有一張表存儲網站分類)。當你使用一個傳統 CMS 時,你可以創建一些分類,並在分類上面撰寫文章,這樣的操作在網站時代是比較友好的,因爲每個用戶都只有一個平臺 —— 那就是瀏覽器,這種方式在瀏覽器上分發非常容易。

進入移動時代後就不一樣了,一家公司至少擁有三個平臺(Web、iOS、Android),針對這些平臺,每家企業都需要定製自己的 CMS,他們可能是在 Wordpress 上做深度定製,也可能是自己開發。做的多了之後,大家會發現,每家公司都在做同樣的事情 —— 寫管理界面、建表、寫 API,這些界面可能是與公司業務高度結合的,比如頭條 APP 的後臺與微信公衆號的後臺肯定是不一樣的。但細細研究卻會發現,其本質就是五個事情:增刪改查和聯表。

於是有人做了一種名爲「Headless CMS」的平臺出來,這種平臺可以在線設計表和表的字段(和 想象下 Excel 的建表,寫字段,但是用起來要比 Excel 簡單很多),然後系統會根據設計好的表和字段自動生成立馬可以使用的 API,這些 API 符合一種名爲 RESTful 的規範,這種規範是開發者們共同遵守的一種規範,只要看到這個規範,開發者就知道該如何使用這些 API。知道如何使用之後,開發者就可以將這些內容用於實際的應用中(也就是展示給終端用戶看),可能是抖音,也可能是微博(這些本質上都是信息管理軟件)。

這麼做帶來的好處是,假如一款產品上線後,產品經理想要新上一個「用戶反饋功能」,在沒有 Headless CMS 的時候需要開發者在數據庫中建一個新的表,然後用一上午的時間調通 API 和圖片上傳功能,最後再做個界面。有了 Headless CMS 之後就不得了了,產品經理想要用戶反饋什麼內容直接在後臺建好字段,然後 API 就自動生成了,開發者省去了建表、建字段、調 API 的時間,直接進入界面開發了。如果產品經理想修改需求,自己就能直接改,這樣不但大幅提升了工作效率,還減少了很多產品經理與程序員之間由於需求變更帶來的巨大摩擦,因此世界更加美好了。

這類 Headless CMS 正在開發者圈子中流行開來,開發者開始主動將這類軟件用於公司業務中。「Headless CMS」 翻譯成中文就是「無頭 CMS」,簡單來說就是不管界面生成的 CMS,他使用了一種名爲「RESTful API」的規範對外提供服務,開發者根據這套規範可以做任何應用。

一旦標準化,就會變成基礎設施,內容正在這條路上。

什麼是 CaaS

CaaS 是內容基礎設施的雲上版本,他提供雲上的 Headless CMS,並提供公網可用的 API 讓開發者可以直接使用,開發者省去了部署運維的精力開銷。除此之外,其還有 Headless CMS 不具備的高性能高可用優勢。大部分 Headless CMS 是開源的,只能處理百萬級別的數據,對於千萬或億級的數據,仍需要做不少優化工作,而 CaaS 將這些也省去了,這就是雲計算的好處,標準化一切可以標準化的東西。

企業對於 CaaS 的擔憂主要還是安全和隱私問題,也就是大家經常聽到的對雲計算的質疑 —— 「憑什麼我把數據、代碼和業務給你,還要給你錢?」

對於中國的企業來說可能還有合規問題。如果在中國做 CaaS,必須投入大量資金和人力到內容審查上。

如果一個 CaaS 能做到壟斷做成寡頭,那麼未來的一個最大的可能就是開放版的微信公衆號。通過其 CaaS 平臺分發出去的內容不僅有社會大衆的娛樂內容,還有很多專業知識,而所有這些內容都是開放可檢索的 —— 如果說中國互聯網最大的遺憾是什麼,那就是大量優質內容無法通過搜索引擎檢索,中國只是個互閉網。

CaaS 相比 CMS 的優勢

CaaS 相比 CMS 有非常多的優勢。

  1. 結構化的內容。CaaS 可以讓內容管理者從「管理頁面」的思維轉向「管理內容」,這將讓我們互聯網上的內容變得更加專業和優質。
  2. 代碼結構優化。傳統 CMS 的內容和界面都是耦合十分嚴重的,像 Wordpress 使用了非常多的自定義指令去表示網頁內的信息,從開發者的角度來說,這點是無法忍受的。CaaS 允許內容代碼和界面徹底分離,這對開發效率來說會有更大幅的提升,並且符合現代開發框架。
  3. 內容和展示分離。傳統 CMS 由於其界面佈局等原因會制約內容的發展,有了 CaaS 之後作者只用關心內容而不必關心界面設計,只需要生產優質內容。
  4. 雲原生應用。CaaS 是一種雲原生應用,也是 SaaS 的一種,雲服務提供商會爲你安裝、維護和做自動伸縮、性能優化等工作,你需要做的只是將內容遷移到 CaaS 和使用。
  5. 個性化。使用 CaaS 可以隨心所欲的定義你想要的表和字段,並且有可以立即投入生產環境的接口使用。這在做一些 A/B 測時會非常有用,因爲所有的修改都不需要改動底層的數據庫或代碼結構。

CaaS 的使用場景

總的來說,CaaS 的主要特性就是自由和靈活,以下是依據這些特性的典型使用場景(其實 CaaS 的應用場景非常廣泛,幾乎所有信息系統都可以用 CaaS 完成,以下只是拋磚引玉):

  1. 多渠道分發。這裏的多渠道分發主要是指分發到不同的內容平臺上,可能是三端相同的應用,也可能是三端不同的應用。通過 CaaS 的開放 API 特性,作者只需要寫一次,就可以重用這些內容,並分發給所有兼容了這些 API 的網站。
  2. 移動應用內容分發。很多移動應用都直接內嵌網頁來展示內容,而 CaaS 的 API 允許移動應用在很方便的進行內容展示(傳統的 CMS 沒有結構化的 API 可用)。
  3. 移動應用後端。移動應用本質上也是信息管理軟件,使用 CaaS 管理移動應用的業務邏輯是個不錯的解決方案,CaaS 是個成熟的方案,比自己寫要容易且穩定很多。
  4. 與身份認證雲配套使用。使用身份認證雲(如 Authing.cn)的用戶往往有自定義字段和內容管理的需求,這些在業務層面的功能身份認證雲是不提供的,那麼 CaaS 便成爲了拓展這些字段的一個良好補充。我們所知道的案例是,將 Authing.cn 配置進 Strapi(一款 CaaS 產品),登錄 Strapi 時使用 Authing 登錄,然後攜帶 Authing 的 Token 訪問 Strapi 的資源並進行授權認證。
  5. 個人博客。與傳統 CMS 一樣,CaaS 也可以作博客,不過需要創作者懂一些編程能力。如果懂編程,CaaS 是個更容易實現個人博客的方案。

一個優秀 CaaS 應該具有的功能特性

作者角度

  1. 體驗良好的編輯器。有類似石墨文檔或 Notion 的文檔編輯體驗,讓作者儘可能舒適的創作內容。
  2. 簡單符合直覺的建表及字段配置。讓內容創作者可以很容易管理、修改和與團隊協作。

開發者角度

  1. 支持 CRUD 的自動生成並符合 RESTful 規範。
  2. 支持每個 API 邏輯的增加和修改。 開發者可以很方便的無限制的拓展 API 的業務邏輯。
  3. 支持拓展計算能力。 支持函數計算,讓開發者可以無限制的拓展平臺能力。
  4. 支持數據的授權以及標準認真協議(OAuth 2.0 或 OIDC)。 能基於 RBAC 或 WAC 對數據進行細粒度授權,同時支持 OAuth 2.0 或 OIDC 協議,能兼容各類身份提供商的登錄認證,並能使用身份提供商的 Token 授權資源訪問。
  5. 高可用高性能。 低時延,快速響應以及完善的日誌記錄和錯誤監控。

如何開始使用 CaaS

  1. 如果你是 JavaScript 開發者,我們建議到 Github 上搜索 Strapi 使用;
  2. 如果你是其他語言開發者,請到 Google 上搜索 Headless CMS 尋找你想要的語言使用;
  3. 如果你是非工程人員,請到 Google 上搜索 Content as a Service 找到最適合你的在線 CaaS 使用。

什麼是 Authing?

Authing 提供專業的身份認證和授權服務。
我們爲開發者和企業提供用以保證應用程序安全所需的認證模塊,這讓開發人員無需成爲安全專家。
你可以將任意平臺的應用接入到 Authing(無論是新開發的應用還是老應用都可以),同時你還可以自定義應用程序的登錄方式(如:郵箱/密碼、短信/驗證碼、掃碼登錄等)。
你可以根據你使用的技術,來選擇我們的 SDK 或調用相關 API 來接入你的應用。當用戶發起授權請求時,Authing 會幫助你認證他們的身份和返回必要的用戶信息到你的應用中。

<div align=center>Authing 在應用交互中的位置</div>

歡迎關注 Authing 技術專欄

Authing 社區

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章