Serverless：这真的是未来吗？（二）
原文 | 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 公眾號，轉載請聯系原作者。原文鏈接：https://developer.aliyun.com/article/784180?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的Serverless：这真的是未来吗？（二）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何通过Graph+AI的方法打造高精度
- 下一篇： 参与Apache顶级开源项目的N种方式，