ServerLess -- 除了極簡架構和極科運維外，更應該多考慮一下極簡開發

文章開頭，我向全部喜歡ServerLess的人們說一聲對不起先，ServerLess我我的以爲是個好東西，但今天文章中會主要談談不足。

Serverless的初衷

• 極簡架構：不須要考慮消息，緩存，數據庫分庫分表，併發等等問題。

• 極簡運維：雲服務器，不須要專門的運維人員。

Serverless的分類

• BaaS（Backend as a Service）即後臺即服務

• FaaS（Function as a Service）即函數即服務

ServerLess的批評聲音都有哪些

「運行時間受限的函數是巨大的挑戰。而是否須要如此細粒度的拆分是須要回答的第一個問題。有些問題或許變成無解難題又或成本極高，例如分佈式數據庫事務。」

」Serverless將無狀態進行的更加完全，在不一樣的調用之間沒法共享內存狀態，這讓複雜業務邏輯代碼編寫變得更加困難。「

」做爲一個新的技術，Serverless還面臨着集成測試困難、Vendor Lock-in、調試監控困難、版本控制等諸多不足「

Serverless架構不會成爲複雜應用的架構首選，相反，它應該是後端小程序的將來

軟件企業技術負責人們如何看Serverless

最近在一個技術論壇，和不少企業技術負責人討論serverless的時候，你們廣泛的表示是serverless和目前的主流技術圈子感受還很遙遠，主要觀點有以下：

• 極簡架構：想法是好，但如今的產品侷限性很強，與現有的系統整合也是個困難，並且生態不成熟，很容易反而增大了開發成本。MVP階段弄個即用即扔的試驗性產品，到是不錯，但在國內，仍是不多。

• 極簡運維：如今自己運維成本也是逐年下降的，並且隨着技術的進一步成熟，現有的雲產品運維成本也不高，並且還能支持將來業務邏輯愈來愈複雜。
  因此，給人的感受很雞肋。

同時，Serverless在你們都但願看到的」極簡開發「上，彷佛沒有什麼建樹，也沒有什麼好的產品出現。

其實，除了架構&運維外，更多的實際上是開發過程的複雜。、

如今開發一個項目/產品的複雜在哪裏呢？舉個例子來講，若是咱們開發一個企業內部管理系統，咱們須要

1. 項目/產品經理與企業內部人員討論需求

2. 將需求與研發人員討論，拿出業務流程與數據流程設計報告（或概要設計，詳細設計）。

3. 項目/產品經理與客戶確認需求

4. 開發人員開始開發，完成後提交給相關人員

5. 項目/產品經理拿着初版產品與客戶確認，客戶可能提出各類問題，再轉給開發人員。

6. 研發人員再進行開發 再來確認。。。

7. 4 - 6這個流程，可能重複幾輪。

這當中，還可能出現一系列的問題，好比：

1. 客戶不滿意，認爲作的不是他想要的

2. 研發不滿意，認爲需求變化過大，很難跟的上

3. 項目/產品經理不滿意，感受兩頭受氣

4. 老闆不滿意，由於項目賠錢。

極簡開發更重要

極簡開發是什麼？極簡開發說大白話就是讓開發更簡單。

讓開發更加簡單最直接的思路是

讓產品/項目經理在與客戶溝通的過程當中，把用戶須要的業務流程和頁面直接配置出來，拿着能運行的產品與客戶溝通，快速的多輪溝通完成後進行一些測試，就能夠直接上線。

這裏面有幾個重點

• 業務流程能夠可視化配置，並支持各類靈活設置。（畢竟企業服務的要求各類可能性都有，工具備侷限性會讓使用場景侷限不少）。

• 頁面能夠靈活配置，沒有侷限性。

• 企業內部的術語，能夠配置。（企業作定製化的系統就是爲了符合本身的業務流程，因此這個很關鍵）

• 有移動端的支持，同時能提供移動端的API。

• 可以經過簡單的配置方式整合其它平臺/系統的數據（企業內部數據打通將來將會愈來愈重要，不少公司接項目時遇到困難也是在這方面）

這樣，有了這樣的工具後：

• 若是企業對前端UI風格沒有特殊的要求，」配置「出的產品，就能夠直接交付使用。

• 若是企業對前端UI風格有要求，則後臺邏輯全配置出來，經過提供的API，本身開發前端UI，知足客戶要求。

相信有了這樣的工具，纔會讓咱們的開發更加容易，更加快速的知足客戶要求，更加靈活的適應市場的變化。

下面是咱們打算於2017年10月下旬開源的一款針對於上面所討論的想法的Serverless引擎，若是你們有興趣，請關注。

http://git.oschina.net/yanglf...