Serverless:這真的是未來嗎?(二)

作者 | Lee Briggs & Piers Karsenbarg
譯者 | donghui

在關於無服務器的第二篇文章中,我們將討論一些更廣泛的問題。再次強調,我們並不是要做硬性規定。我們想提出一些觀點,以促進所有利益相關者之間的討論。許多說所有應用程序都將是無服務器的應用程序的人並未大規模運行其應用程序,也未解決與延遲、複雜性和供應商鎖定有關的所有問題。這就是我們在這裏要談論的。

供應商鎖定怎麼辦?

你有多關心廠商鎖定問題?例如:你很可能無法將 AWS 中的無服務器架構轉移到另一個雲提供商。有些組織不關心廠商鎖定問題,但很多組織關心。如果你真的在乎,那麼在你繼續前進之前,請決定你應該在乎多少。

您的組織有多大?

無服務器對於較年輕的組織或較小的組織來說是一個很好的選擇,也許大型組織中的新手團隊直接關注於交付價值。一旦組織發展到足夠大,可以支持專門管理基礎設施的團隊了,並且使用率增長了,可能就該重新評估情況了。成功採用無服務器平臺的大型組織往往是經歷了文化轉變才獲得成功。如果您還沒有準備好在組織的所有級別上進行大量投資,以使無服務器的採用獲得成功,那麼使用更傳統的方法(由專門的團隊控制供應基礎設施)可能更合適。最後,正如在前一篇文章中所討論的,大型企業可能想要考慮構建一個基礎設施平臺,在那裏像 Kubernetes 這樣的技術可以受益。

架構是什麼樣的呢?

需要考慮的一點是無服務器的產品和更 "傳統" 的方法在思維方式上的顯著差異,這意味着當切換平臺時,應用程序可能經常需要重新設計。您可能需要考慮這些體系結構更改的 ROI 是什麼。通常,從時間和財務的角度來看,任何應用程序的重新設計都是昂貴的,甚至會給最成功的工程團隊帶來問題。

無論您是在開發一個新開發的應用程序還是評估一個現有的應用程序,考慮無服務器應用程序的架構都是很重要的。傳統的 N 層風格的體系結構或 N 層風格的 web 應用程序需要大量的投資才能遷移到無服務器的平臺。

總結

總而言之,無服務器並不能解決所有問題,但是在正確的地方可以提供很多服務。請記住以下問題:

1. 您有多在乎供應商鎖定?

無服務器架構不能簡單地從一個雲提供商遷移到另一家雲提供商。您的組織在多大程度上關心供應商鎖定?

2. 您的組織規模是多大?

無服務器通常更適合小型組織。一旦有了 IT 員工來支持它,您可能想看看更傳統的選擇。大型企業可能希望研究 Kubernetes。

3. 您是否比提供應用程序透明性更關心快速提供價值?

如果您希望儘快將應用程序推向市場,那麼無服務器可能是一個不錯的選擇。但是,您將犧牲應用程序的指標和洞察力。隨着規模的增長,這可能會導致真正的問題。

4. 您瞭解應用程序的屬性嗎?

通常說無服務器可以省錢,因爲您只需爲使用時間付費。但是,如果您的應用程序具有較長的響應或啓動時間,請仔細觀察。無服務器可能是一個昂貴的選擇。

5. 您的應用程序的體系結構是什麼樣的?

不要期望傳統的端層風格的體系結構能夠很好地與無服務器的應用程序配合使用。尋找可以分解成更小的組件一起工作的應用程序。另一方面,將無服務器應用程序遷移到您控制的服務器也需要重新構建應用程序。你有時間和人去做嗎?

6. 無服務器是繞過 IT 的一種方法嗎?

使用無服務器作爲繞過 IT 部門的方法可能不是最好的主意。編寫不合規且容易受到攻擊的代碼太容易了。相反,請使用 DevOps 方法並與所有利益相關者會面以提出解決方案。

7. 安全性如何?

無服務器架構的安全性存在問題。雲提供商提供了一些現成的選項,例如 Amazon GuardDuty,但是它們可能有很多限制,限制了無服務器提供的靈活性。實現安全的無服務器應用程序需要大量的思考。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/oBSoSZqer8BCVUvfEHG3tA