像許多熱門的IT趨勢一樣，無服務器計算及其優勢經常被過度簡化。因此，有些組織甚至在沒有強大的理由的情況下追趕無服務器的潮流。

 

無服務器部署需要考慮很多因素，但是有三個特定的警告信號表明并不適合某些企業。

 

 

如果企業打算部署第三方軟件或傳統應用程序，卻無法或不會改變，企業將面臨無服務器的主要問題。來自頂級云提供商的無服務器產品(如AWS的Lambda，Azure Functions和Google Cloud Functions)還是相當新穎的，但很多舊版本的軟件并沒有考慮到這些。

 

可以說，無服務器計算是從社交網絡應用程序中派生出來的，其中最引人注目的是Twitter，它遵循事件處理模型。但是如今的大多數商業應用程序并不是為事件處理而構建的，這并不意味著它們不能這樣工作，而是需要改變這些應用程序如何分解成組件，以及這些組件的邏輯。

 

一些用戶發現，近三分之二的無服務器目標應用程序是無法更改的，無論是因為第三方供應商擁有它們還是需要大量時間和費用。如果企業使用第三方軟件，需要從軟件供應商那里尋求應用程序可以在無服務器體系結構上運行的合同承諾。

 

 

當需要應用程序功能時，企業僅需要支付無服務器計算成本，雖然這可以節約成本，但也會導致經常運行的應用程序的成本過高。一個理想的無服務器應用程序已經準備好在幾毫秒內運行，但不能經常被調用。一個持續運行的應用程序將在大多數時間內承擔費用，這些費用將遠高于在云端運行虛擬機或容器的成本。

 

通常企業很難知道應用程序是需要運行還是只是準備運行。需要運行的一個很好的例子是在繁忙的零售商店中支持信用終端的應用程序。這個應用程序被稱為每一次購買，這使得它適合更加傳統的基礎設施即服務平臺。準備運行的一個例子是監視由溫度波動觸發的倉庫中的環境傳感器的應用。這種類型的應用程序需要隨時運行，但不會經常運行，這使得它成為無服務器計算的理想選擇。

 

 

由于無服務器應用程序按需加載和運行，因此在使用的應用程序之間不能保存結果。這種保存操作被稱為有狀態或場景。如果企業的應用程序本質上是有狀態的 - 就像提供某些更新或支持多步對話的任何業務應用程序一樣，將會遠離無服務器。

 

亞馬遜公司和微軟公司將無服務器計算描述為functional或lambda處理。這是指一種特定的編程技術，它可以避免在應用程序或應用程序組件中從一個激活到另一個激活保存任何東西。functional或lambda邏輯始終是無狀態的，這使得應用程序組件的任何副本都可以處理事件。

 

谷歌公司將無服務器稱為微服務計算。微服務也應該是無狀態的，部分原因是應用程序可能共享相同的邏輯，這使得保存場景可能會在不知情的情況下傳遞給另一個應用程序或用戶是危險的。

 

企業可能需要重寫部分或全部應用程序來解決這個無狀態問題。即使不需要重寫，只需要更改應用程序設計的一部分，就可以讓開發人員知道如何處理狀態、場景、lambda編程，以及微服務。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。