「无服务器架构」无服务器架构是应用程序的正确选择？考虑利弊在适当的情况下

文章插图
在适当的情况下，我们喜欢无服务器架构。但这些情况是什么呢?在前一篇关于web开发中的无服务器架构的文章中，我们讨论了为什么我们相信无服务器将是云原生开发的未来。不可否认的是，重点是无服务器架构的优势。在我们的无服务器系列的这一期中，我们将通过概述无服务器的缺点以及在哪些情况下它可能不是你的下一个应用的最佳方法来增加更多的平衡。
当然，没有任何技术或架构是适用于所有情况的完美解决方案。在无服务器的web开发中，可以感知到的弱点在某种程度上得到弥补，这意味着它们不会拖累技术解决方案或业务案例，以达到优势被削弱的程度?
我们还将把无服务器web开发的优缺点理论应用于示例应用程序。这将说明在何种情况下， serverless的优点和缺点的平衡使得它成为技术堆栈的最佳选择，而在哪些情况下它可能不是最佳选择。
为了平衡我们上一篇文章中略显夸张的pro-serverless的立场，让我们从这次无服务器web开发的缺点开始：
Serverless缺点【「无服务器架构」无服务器架构是应用程序的正确选择？考虑利弊】那么，采用无服务器开发方法可能存在哪些问题和缺点呢?
厂商锁定在与我们自己的架构师和客户讨论serverless是否是一个新的开发项目的正确方式时，我们经常会看到对供应商锁定的担忧。有一种看法认为，一旦应用程序的无服务器架构由一家云供应商(通常是GCD、AWS和Azure)建立起来，如果环境发生变化，那么要迁移到另一家云供应商就非常困难(昂贵且耗时) 。
在现实中，如果从一个新的应用程序项目开始就提供正确的方法，供应商锁定不一定是无服务器开发的缺点。至少对大多数应用程序来说不是这样。对于真正的大型应用程序来说，供应商之间的迁移不可避免地会非常复杂。
例如，你正在设计一个具有以下功能的web应用程序:

安全的用户标识
收集及储存一些个人资料
应用程序功能的用户界面

让我们比较一下传统web开发和无服务器开发方法所需要的技术栈。
传统的web开发:

身份识别:Spring安全框架(Java)
数据存储:NoSQL更适合这里，因为不需要事务(MongoDB)
通知:带有Websockets的Spring
支付方式:第三方服务
业务逻辑核心:带有REST端点的Spring框架(Java)

无服务器web开发与AWS:

标识:AWS Cognito
数据存储:AWS DynamoDB
通知:AWS简单通知服务
支付方式:第三方服务
业务逻辑核心:AWS Lambda

许多不同的应用程序都需要用户标识、数据存储、通知和支付。除此之外，只有应用程序的“核心”才能被认为是“独特的” 。
传统的web开发需要对用户标识、数据存储、通知和支付进行自定义配置和编码。因此，任何改进、开发或修复应用程序中的问题的改变都需要一个新的软件开发迭代周期。这意味着任何改变都需要大量的资源(时间和金钱) 。
另一方面，无服务器的web开发允许您使用“即插即用”技术来实现应用程序涉及的常见功能——用户识别、支付等。上面列出的AWS工具(Cognito、DynamoDB等)只需要配置，然后就可以在测试和生产环境之间快速、轻松地进行更改。
这意味着在最初的开发阶段以及在需要引入任何后续更改或更新时，无服务器开发可以节省大量的时间和金钱。
但是，上面所说的与围绕无服务器开发的“供应商锁定”问题有什么关系呢?假设您想将您的应用程序从AWS移动到谷歌云。在您的应用程序中使用了几种AWS技术。这在使用AWS云时非常棒。但现在就有问题了，对吧?是的。将它们转换成谷歌云的等价物将是一个痛苦的过程。这就是对无服务器开发的供应商锁定批评的症结所在。
但事实并非如此。如果从一开始就采用无服务器框架，那么无服务器应用程序可以构建为“云供应商不可知论” 。无服务器框架解决方案允许您使用一个常见的配置文件来设置无服务器架构，在这个配置文件中，您只需更改云供应商的名称，就可以将AWS技术转换为谷歌云(或任何其他主要供应商的云)的对等产品。不需要任何其他操作，你的应用程序将在新的云home中像以前一样工作。
正确的无服务器开发应该意味着在云供应商之间迁移就像改变移动运营商而保持你的旧号码在最近几年变得一样容易。支持无服务器开发的框架正在迅速成熟，并且解决了供应商锁定等明显的弱点。企业越来越确信，无服务器技术栈的主要缺点正在被消除，使其优势不受损害。