共计 1705 个字符，预计需要花费 5 分钟才能阅读完成。
简介：在对于无服务器的第二篇文章中，咱们将探讨一些更宽泛的问题。再次强调，咱们并不是要做硬性规定。咱们想提出一些观点，以促成所有利益相关者之间的探讨。许多说所有应用程序都将是无服务器的应用程序的人并未大规模运行其应用程序，也未解决与提早、复杂性和供应商锁定无关的所有问题。这就是咱们在这里要议论的。
原文 | https://www.pulumi.com/blog/i…
作者 | 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 公众号，转载请分割原作者。
