没有这个dll ‘mvtnorm’:是不是没有为此架构安装?_无服务器架构无服务器架构是应用程序的正确选择？考虑利弊...
在适当的情况下，我们喜欢无服务器架构。但这些情况是什么呢?
在前一篇关于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中像以前一样工作。
正确的无服务器开发应该意味着在云供应商之间迁移就像改变移动运营商而保持你的旧号码在最近几年变得一样容易。支持无服务器开发的框架正在迅速成熟，并且解决了供应商锁定等明显的弱点。企业越来越确信，无服务器技术栈的主要缺点正在被消除，使其优势不受损害。
可口可乐公司的方案架构师Patrick Brandt最近表示:
无服务器框架是可口可乐公司降低IT运营成本和更快部署服务计划的核心组成部分。
太积极了?我们是不是把缺点滑向了无服务器？，Serverless?在我看来只有一件事可能意味着厂商锁定是一种担心,可能阻止你为您的下一个项目采用serverless开发——常见的组件需要使用功能需要独特的代码完全控制没有商量的余地。
无服务器的运行成本是骗局吗?
反对新应用程序的无服务器开发方法的另一个常用论据是潜在的计算成本。我多次听说云资源很昂贵，用户无法控制成本。
这是部分正确的。传统的发展意味着可以准确地预测计算资源的开销。一个企业确切地知道一个应用程序需要多少服务器，它们的位置等等。预算是很容易的。
如果您选择一个没有云服务器的环境，您会在月底收到账单，并且很难预测准确的成本。尾巴上的刺是可能的。这种对管理费用缺乏控制的情况经常阻碍公司投资于无服务器的技术。
从商业的角度来看，不能准确地控制或预测成本会导致交易失败。这是否会成为瓶颈，意味着未来的无服务器开发将无法与当前的炒作相匹配?
我不这么想。首先，如果您知道自己在做什么，那么准确预测无服务器应用程序的云资源成本其实并不困难。你只需要定义你的应用将使用什么云资源，以及这些资源如何适应供应商的定价结构。是的，您可能无法准确地预测应用程序的需求和使用水平。如果它像病毒一样传播开来，你会不会被云计算供应商的发票所咬，从而毁掉你的公司?
这是一个需要考虑的问题，但在绝大多数情况下，它不会真正影响Serverless是否是合适的技术。事实上，初创企业之所以经常青睐Serverless，正是因为成本被重新加载了。运行一个应用程序是非常便宜的，直到它有大量的用户，在这一点上额外的成本是合理的。这也使得Serverless成为MVPs和新产品的理想架构。
首先，如果一个应用程序是直接盈利的，那么在需求激增的情况下，收入应该随着云资源成本的增加而增加。如果一个应用程序不能直接变现，那么它可能会增加另一种商业价值，间接代表公司的经济收益。
可能会出现意想不到的高云资源成本会对业务现金流产生负面影响的情况，尽管应用程序的正面需求高于预期。但从一开始就应该清楚，这种情况是否有可能出现。除了简单地拒绝Serverless及其作为技术堆栈的优势之外，可能还有其他解决方案。
在大多数场景中，应用程序在需求高峰期间保持一致的性能将是压倒一切的业务考虑。您是否曾经因为门户运行缓慢或在使用高峰期崩溃而离开门户?上周给亲戚买礼物时，我就是这么做的。
三个电子市场以同样的价格提供同样的产品。其中两个明显比第三个慢(过滤慢2-4秒)。是的，也许缓慢的应用程序只是低劣的架构的结果。但是，如果他们有相同的代码，他们如何有效地扩展以满足需求?
如果您使用硬件连接服务器容量，如何知道峰值需求可能需要哪些资源?您的服务器很少接近最佳容量。它们要么提供了太多的容量，而你已经为此付费，90%的时间都处于闲置状态，要么在高峰时刻容量不足，要么速度变慢，要么崩溃，失去你的业务。
有了Serveless，你就不需要‘hard plan’的能力了。它将无缝地扩展以满足需求。有很多方法可能会让您失去业务，但服务器容量运行在您需要的水平不是其中之一。
如果您真的不知道应用程序可能会有什么需求，Serverless是一个特别好的选择。你只会为你使用的东西付费，这让你能够感受事情的真相。这并不意味着成本计划在Serverless中不重要。组件成本应努力研究和技术优化的数据查询规划，lambda内存和时间消耗规划。
总之，如果您的应用程序是成熟的，并且需求趋势和服务器容量需求可以准确地长期预测，那么Serverless可能不是您可用的最便宜的选择。选择自己的固定服务器资源可能是有意义的。但是，即使在这种情况下，能够适应任何意想不到的需求高峰的混合云解决方案仍然值得考虑。
复杂的集成/迁移，从当前的非无服务器解决方案
我同意将现有体系结构迁移到无服务器体系结构或混合解决方案是具有挑战性的。然而，根据我的经验，问题的关键在于依赖于缺乏相关专业知识的开发人员。向云计算转型需要对新技能进行投资。这可能意味着为内部开发专业人员提供培训，或者引入有经验的外部帮助。
无服务器开发和传统开发之间的一个根本区别是，无服务器开发人员需要考虑并能够准确计算与他们如何构建应用程序相关的成本。所使用的技术组件、数据库请求、计算时间和性能成本有多少?这些成本是否与应用程序的业务案例和计划相匹配?传统的web开发人员不必担心这些问题。这不是他们的工作。
对于我个人来说，作为一个已经从传统开发过渡到无服务器开发的开发人员，这是工作性质中最难掌握的变化之一。组织向无服务器的转变，无论是完全的还是特定的应用程序，都应该考虑到这一点。开发人员需要接受再教育，他们的工作现在涉及在其业务案例的上下文中管理应用程序的运行成本。
什么时候无服务器开发是应用程序的最佳选择?
让我们总结一下业务考虑和应用程序的技术质量，广泛地说，这意味着它通常会受益于无服务器:
中小型应用程序
市场尚未建立，负荷难以预测
应用程序需要进行大量快速(快速失败)试验
公共模块(身份识别、通知)无独特主张
团队准备利用没有服务器的优势
当Serverless可能不是一个应用程序的最佳技术堆栈:
大型应用程序
确定和可预测的市场需求和高峰负荷时间
应用程序的特点是迭代和缓慢-实验不受欢迎
在公共模块中需要细粒度控制，并且它们包含唯一的流
团队没有做好准备，没有采用云服务器思维
在下一篇关于无服务器开发的文章中，我们将概述AWS提供的常见“即插即用”组件的优势和好处。
本文：http://jiagoushi.pro/node/1278
讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】
| 微信公众号 | 【首席架构师智库】 适合物业仔细反复阅读。 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 我们在等你，赶快扫描关注吧。 |
 |
| 微信小号 | 50000人社区，激烈深度讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化. |
|
| QQ群 | 深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。 |
|
| 视频号 | 【首席架构师智库】 1分钟快速了解架构相关的基本概念，模型，方法，经验。 每天1分钟，架构心中熟。 |
|
| 知识星球 | 向大咖提问，近距离接触，或者获得私密资料分享。 | 知识星球【首席架构师圈】 |
| 微信圈子 | 志趣相投的同好交流。 | 微信圈子【首席架构师圈】 |
| 喜马拉雅 | 路上或者车上了解最新黑科技资讯，架构心得。 | 【智能时刻，架构君和你聊黑科技】 |
| 知识星球 | 认识更多朋友，职场和技术闲聊。 | 知识星球【职场和技术】 |
