原文 | https://www.pulumi.com/blog/is_serverless_the_future_part_2/ 做者 | Lee Briggs & Piers Karsenbarg 譯者 | donghuiweb
在關於無服務器的第二篇文章中，咱們將討論一些更普遍的問題。再次強調，咱們並非要作硬性規定。咱們想提出一些觀點，以促進全部利益相關者之間的討論。許多說全部應用程序都將是無服務器的應用程序的人並未大規模運行其應用程序，也未解決與延遲、複雜性和供應商鎖定有關的全部問題。這就是咱們在這裏要談論的。安全
供應商鎖定怎麼辦？
你有多關心廠商鎖定問題？例如：你極可能沒法將 AWS 中的無服務器架構轉移到另外一個雲提供商。有些組織不關心廠商鎖定問題，但不少組織關心。若是你真的在意，那麼在你繼續前進以前，請決定你應該在意多少。服務器
您的組織有多大？
無服務器對於較年輕的組織或較小的組織來講是一個很好的選擇，也許大型組織中的新手團隊直接關注於交付價值。一旦組織發展到足夠大，能夠支持專門管理基礎設施的團隊了，而且使用率增加了，可能就該從新評估狀況了。成功採用無服務器平臺的大型組織每每是經歷了文化轉變纔得到成功。若是您尚未準備好在組織的全部級別上進行大量投資，以使無服務器的採用得到成功，那麼使用更傳統的方法（由專門的團隊控制供應基礎設施）可能更合適。 最後，正如在前一篇文章中所討論的，大型企業可能想要考慮構建一個基礎設施平臺，在那裏像 Kubernetes 這樣的技術能夠受益。架構
架構是什麼樣的呢？
須要考慮的一點是無服務器的產品和更"傳統"的方法在思惟方式上的顯著差別，這意味着當切換平臺時，應用程序可能常常須要從新設計。您可能須要考慮這些體系結構更改的 ROI 是什麼。一般，從時間和財務的角度來看，任何應用程序的從新設計都是昂貴的，甚至會給最成功的工程團隊帶來問題。less
不管您是在開發一個新開發的應用程序仍是評估一個現有的應用程序，考慮無服務器應用程序的架構都是很重要的。傳統的 N 層風格的體系結構或 N 層風格的 web 應用程序須要大量的投資才能遷移到無服務器的平臺。ui
總結
總而言之，無服務器並不能解決全部問題，可是在正確的地方能夠提供不少服務。請記住如下問題：url
1. 您有多在意供應商鎖定？
無服務器架構不能簡單地從一個雲提供商遷移到另外一家雲提供商。您的組織在多大程度上關心供應商鎖定？.net
2. 您的組織規模是多大？
無服務器一般更適合小型組織。一旦有了 IT 員工來支持它，您可能想看看更傳統的選擇。大型企業可能但願研究 Kubernetes。設計
3. 您是否比提供應用程序透明性更關心快速提供價值？
若是您但願儘快將應用程序推向市場，那麼無服務器多是一個不錯的選擇。可是，您將犧牲應用程序的指標和洞察力。隨着規模的增加，這可能會致使真正的問題。server
4. 您瞭解應用程序的屬性嗎？
一般說無服務器能夠省錢，由於您只需爲使用時間付費。可是，若是您的應用程序具備較長的響應或啓動時間，請仔細觀察。無服務器多是一個昂貴的選擇。
5. 您的應用程序的體系結構是什麼樣的？
不要指望傳統的端層風格的體系結構可以很好地與無服務器的應用程序配合使用。尋找能夠分解成更小的組件一塊兒工做的應用程序。另外一方面，將無服務器應用程序遷移到您控制的服務器也須要從新構建應用程序。你有時間和人去作嗎？
6. 無服務器是繞過 IT 的一種方法嗎？
使用無服務器做爲繞過 IT 部門的方法可能不是最好的主意。編寫不合規且容易受到攻擊的代碼太容易了。相反，請使用 DevOps 方法並與全部利益相關者會面以提出解決方案。
7. 安全性如何？
無服務器架構的安全性存在問題。雲提供商提供了一些現成的選項，例如 Amazon GuardDuty，可是它們可能有不少限制，限制了無服務器提供的靈活性。實現安全的無服務器應用程序須要大量的思考。
本文轉載自 Serverless Life 公衆號，轉載請聯繫原做者。