無服務器計算，雖然神祕，但一定會成爲IT行業最有力的工具之一。這種可能改變遊戲規則的技術雖然不是全新的，但就像之前的容器技術一樣，有一些神化和誤解。
1什麼是無服務器（Serverless）計算？
無服務器計算允許企業構建、運行應用和服務而不用去考慮服務器。無服務器應用不需要管理任何服務器，而且任何類型的應用或後端服務都可以構建爲無服務器應用。運行應用以及應用高可用所需要的一切，都由雲服務商來提供。
無服務器應用程序有四大優勢:
1)不需要管理服務– 不需要提供或維護任何的服務器，不需要安裝任何的軟件或運行時。
2）彈性擴縮–應用程序擴縮能自動完成或是通過調整其資源使用量來調整容量，而不是通過增減服務器的數量。
3）高可用－無服務器應用程序內置高可用和容錯。無需考慮高可用，運行應用的服務默認提供高可用。
4）沒有閒置損耗－不需要對計算和存儲之類的服務預留容量。如果代碼沒有運行，就不會收費。
構建無服務器應用程序意味着開發者可以專注在產品代碼上，而無須管理和操作雲端或本地的服務器或運行時。
2無服務器（Serverless）計算如何工作？
與使用虛擬機或一些底層的技術來部署和管理應用程序相比，無服務器計算提供了一種更高級別的抽象。因爲它們有不同的抽象和“觸發器”的集合。
拿計算來講，這種抽象有一個特定函數和抽象的觸發器，它通常是一個事件。以數據庫爲例，這種抽象也許是一個表，而觸發器相當於表的查詢或搜索，或者通過在表中做一些事情而生成的事件。
比如一款手機遊戲，允許用戶在不同的平臺上爲全球頂級玩家使用高分數表。當請求此信息時，請求從應用程序到API接口。API接口或許會觸發 aws 的Lambda函數，或者無服務器函數，這些函數再從數據庫表中獲取到數據流，返回包含前五名分數的一定格式的數據。
一旦構建完成，應用程序的功能就可以在基於移動和基於 web 的遊戲版本中重用。
這跟設置服務器不同，不是必須要有Amazon EC2實例或服務器，然後等待請求。環境由事件觸發，而響應事件所需的邏輯只在響應時執行。這意味着，運行函數的資源只有在函數運行時被創建，產生一種非常高效的方法來構建應用程序。
3適用於哪些場景？
無服務器計算適合於任何事件驅動的各種不同的用例。這包括物聯網，移動應用，基於網絡的應用程序和聊天機器人。事件是由人的動作（比如按下按鈕），傳感器或者系統中的數據流產生。
這方面的一個例子是，Thomson Reuters（人名）使用AWS Lambda來加載和處理數據流，而無需提供或管理任何服務器。Thomson Reuters建立了一個解決方案，使其能夠捕捉、分析和可視化其產品所生成的分析數據，提供幫助產品團隊不斷改進用戶體驗的見解。
AWS Lambda只在通過與其他AWS服務、Kinesis和AmazonS3集成的新數據條目觸發時運行代碼。
在事件驅動下，當代碼運行時，公司只收取計算處理的費用，這是非常節約成本的。
4不適用哪些場景？
對於已經構建的遺留應用程序來說，這不一定是一個完全的解決方案。如果是一個單體應用或者應用需要運行在操作系統級別，這樣的應用就不適合在無服務器平臺上運行。這並不意味着這樣的應用沒法實現無服務器架構，它只是意味着需要重新構建應用程序。
一個很好的例子是web應用程序，可以在應用程序服務器(如Tomcat)中將其作爲一個大型的單體job運行。如果要將應用程序分解爲複合函數集，則可以使用無服務器模型實現所有的新功能。隨着時間的推移，舊版本應用程序的使用級別越來越小，這些新的無服務器組件的使用率隨着使用量的增加而增加。對於這樣的客戶，都有一個過渡模型，客戶可以遵循這種過渡模式，將傳統的基於機器的應用程序架構遷移到基於功能的架構。
5無服務器（Serverless）計算貴嗎？
並不貴。只需要支付企業所使用的部分，沒有任何與無服務器計算相關的成本。特別對於小的用例，應用程序使用隨時間變化大的企業是非常划算的。
對於希望管理工作負載和操作的客戶來說，它也非常划算，因爲它可以使客戶避免成本，例如容量規劃或部署工具。許多AWS的客戶，現在正在嘗試用服務器來提高敏捷度，同時也節省了成本。健康零食公司Graze有許多使用for AWS的方法，包括將分析數據實時上傳至亞馬遜RedShift、管理備份和檢查GitHub拉請求，希望在未來幾個月內將其使用量增加兩到三倍。
6無服務器（Serverless）的行業炒作
無服務器計算得到了開發人員的積極響應。在以資源有效的方式交付應用程序時，它提供了更多的選項和可能性。
很多大型的企業，比如Netflix，已經在探索無服務器計算，希望解放開發人員的時間。Netflix使用AWS Lambda來構建基於規則的自我管理基礎設施，並替換低效的流程，減少錯誤的速率，爲開發人員節省寶貴的時間。
以前，雲開發者必須使用那些耗費大量人力和時間的機器。無服務器技術允許開發人員在幾分鐘內運行測試和產品。開發人員直接控制部署時間以及如何部署，通過建模框架控制應用架構。還允許發佈自己的產品並親自體驗。
2
容器和無服務器（Serverless）
無服務器計算和容器之間正在醞釀一場戰鬥——當塵埃落定時，誰會倒下？會是容器嗎？
如前所述，無服務器具備一些明顯的優勢。比如節省成本，提高IT支出的效率，減少資源和維護需求，允許開發人員和IT人員專注於高價值的任務等等。這也是爲什麼人們會對這項技術充滿熱情的原因。但是，通往無服務器的路徑並不輕鬆。
SetfiveConsulting 的合夥人 Ashish Datta 說，將基於容器的架構遷移到無服務器通常需要重新架構系統的重要部分。
“與從虛擬機到容器的轉換相比，從容器到無服務器的轉換更有戲劇性，因爲容器和無服務器之間的計算環境發生了根本性的變化。”
相反，從虛擬機到容器的遷移更爲直接，因爲這實際上只是部署哲學的變化。
Stackery CEO Nate Taggart說，最大的障礙是企業無法輕易地遷移到無服務器架構上。
“(無服務器應用程序)必須是爲無服務器基礎設施設計的。這對於新的開發來說可能是相當經濟的，但是遷移遺留應用程序將是很繁重的，在某些情況下甚至是不可能的。
今天的無服務器產品有資源的限制，Taggert解釋道，包括內存、計算和時間限制;有限的語言支持;以及在請求之間管理狀態的特殊考慮。所有這些都必須“從一開始就融入到應用程序設計中”，Taggert說。
PubNub的產品營銷總監James Riseman說，遷移到無服務器架構還需要對現有基礎設施進行重大的反思。
“無服務器計算需要一個非常現代的、組件化的架構。系統和應用程序必須被分解成離散的邏輯函數，而要保證這樣的質量企業會失去控制。” JamesRiseman 表示。
無服務器的另一個問題是定價。“公司是按照每筆交易或每秒鐘計費，而不是按照傳統的基礎設施條款，”Siseman說。“這使得定價更加難以預測。”
除了地址遷移需求之外，轉向無服務器計算還會導致思維模式的改變。
“最大的障礙之一是，需要考慮在離散的單元中計算資源，而不是始終佔用進行計算。”這與對內存使用量和運行時等框架的限制相吻合，比如Amazon Lambda這樣的框架。“Atta說道。
1對手還是盟友？
撇開正反兩方面的因素不說，在面對面的交鋒中，容器和無服務器是相互排斥的解決方案。但是每個人都說這樣想是錯誤的。
SwymSystems CEO兼首席顧問Todd Millecam 表示，這是一種蘋果和橘子的比較。“兩者都有使用，如果觀察大多數無服務器技術的運行方式，它們只是在後臺運行容器。”
無服務器和容器是互相補充而並非重疊的角色。Taggart說，雖然兩者都可以用於計算任務，但每個任務都有其優缺點。無服務器是一種理想的、可預測的、具有小型資源需求和短期事務的工作負載。
容器對於長時運行的流程和可預測的工作負載具有優勢。容器在應用程序設計方面也提供了更多的靈活性，但需要對底層基礎架構進行更多的管理。
“作爲一個無服務器操作控制檯產品，我們有一個幾乎完全沒有服務器的後端，”Taggart補充說，但是仍然使用容器來處理某些工作負載，在這些工作負載中，它們是更好的工作工具
2 Serverless是未來嗎？
看來，關於容器式微的謠言被誇大了。
Datta說，不同的架構和應用程序總是需要不同程度的抽象，同樣，不同的團隊也會對做出不同的權衡。
正如容器沒有取代虛擬機，虛擬機也沒有取代裸金屬的服務器。抽象不會成爲“更接近金屬”的解決方案的生死存亡的威脅。
無服務器，應該被看作是技術的進化。大多數觀察者警告說，無服務器仍然不成熟，還沒有建立架構模型和健壯的開發工具。這意味着將企業應用程序的命運與特定的雲供應商綁定，將帶來自身的風險。
因此，儘管它有巨大的潛力，但可能需要數年才能在企業中獲得廣泛的應用。
同時，無服務器將會對創業公司產生重大影響。
“無服務器計算提供了一種託管代碼的方法，並以很低廉的成本在web上可用。在擁有活躍的用戶基礎之前，無服務器是構建web應用程序的一種划算的方式。”Millecam說道。
不過，數字機構POP CTO Jake Bennett 表示，隨着無服務計算技術的成熟，架構師會發現無服務器將越來越難以抗拒。“無服務器計算解決了太多被忽視的問題。將對可伸縮性問題的關注轉移給第三方供應商，是每個開發人員的夢想，讓別人關心服務器維護是IT運維人員的一種幻想。”
原文鏈接：
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY
