![頭圖.jpg](https://ucc.alicdn.com/pic/developer-ecology/b8f3dbba827c49e082417d79250c93ad.jpg)

原文 | [https://www.pulumi.com/blog/is_serverless_the_future_part_2/](https://www.pulumi.com/blog/is_serverless_the_future_part_2/)
作者 | 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，但是它們可能有很多限制，限制了無伺服器提供的靈活性。實現安全的無伺服器應用程式需要大量的思考。

> 本文轉載自 Serverless Life 公眾號，轉載請聯絡原作者。

Serverless：這真的是未來嗎？（二）

相關文章