尽可能地做到无服务器，但不止于此

毫无疑问，如果您一直关注技术趋势，那么您会看到“无服务器”的兴起。 在某些情况下，“无服务器”被称为“下一个应用程序体系结构”样式。 我什至听说有人说“您不需要技术X，因为无服务器是未来之路”，或者“技术X是红鲱鱼，因为无服务器”，等等。在本期中，我们将了解为什么它与“微服务与无服务器”。

到目前为止，我对无服务器的最佳描述来自Patrick Debois在他的“无服务器到完整服务”演讲中 。 在该演讲中，他为“无服务器”提供了一个定义，并实际上定义了什么是什么，而不是什么不是 。 专注于它不是什么（即，没有服务器！！！！）实际上会干扰任何真实含义（当然，还有服务器！！）。 通过集中的事实，它更多的是使用作为提供的服务（想事情像SQS，DynamoDB时，Gmail，谷歌日历，SalesForce公司，快速度等），将它们订在一起，以提供某种功能，我们可以得出一个更有趣的定义 ：

将核心基础架构服务外包给服务提供商，并通过API（和功能）将它们组合在一起以提供业务价值

在许多方面，“利用现有服务并在其之上构建”的想法并不是新事物。 这是“面向服务的体系结构”背后的精神的化身：

如果我们可以利用现有的服务来降低进入门槛（即注册一个API而不是购买硬件，设置安全性/网络/ DNS /操作系统等），那么我们可以为我们的客户更快地构建有趣的东西。 这是什么是无服务器的一部分。 第二部分是您不必拥有来自这些不同服务的所有技术的事实。 也就是说，您需要为使用（计量）和SLA付费，而您不拥有并且必须解决棘手的技术问题才能使用提供业务价值的功能。 Ben Kehoe 在最近的播客中很好地传达了这一点。 我完全赞同这个。

因此，当客户问我“如果无服务器是应用程序体系结构的下一个发展趋势，我是否应该跳过微服务和容器”？ 答案：

尽可能地做到无服务器，但不止于此。

让我们剖析一下。

作为技术专家，我们被技术和任何新的闪亮趋势所吸引。 无服务器，容器等都很重要。 但归根结底，我们作为技术专家的作用是帮助企业发现和利用企业价值，并且比竞争对手更快地做到这一点。

如果我们处于应用程序生命周期的“探索”部分（就像所有初创公司一样），我们想要做的就是Swift使我们关于将为客户创造价值的假设无效，并同样Swift地找到能够为客户创造价值的假设。 客户在看到价值之前就无法明确表达其价值。 最好通过将服务摆在它们前面来快速进行试验，并观察它们的响应方式。 如果某件事对客户的兴趣不大，最好抛弃它并继续前进。 为此，我们不能在建立基础设施，开发成本，合作伙伴等方面投入大量资金。我们必须尽可能便宜地运行这些实验，而“无服务器”方法为实现这一目标提供了绝好的机会。 我们可以利用现有的技术服务为客户创建数字资产，而无需大量投资，而且至关重要的是：我们可以随行付款。 如果我们对新产品/服务的兴趣为零，那么花费不多。 如果我们最初有一些不可预测的尖峰兴趣，那么我们将提供一个平台（服务+ FaaS），可以快速扩展而不会造成很多麻烦。

如果我们偶然发现确实能够提供客户价值的产品（即产品/市场契合度），那么我们希望在此基础上进行扩展，扩展并围绕其构建有利润的产品。 在这一点上，您可能会发现自己想要采用部分无服务器且部分非无服务器的体系结构来解决此问题。 您将不得不面对以下两个技术决策：“我应该拥有多少堆栈才能实现业务价值和差异化”，以及“我愿意将SLA，法规遵从性，价格和路线图外包给我的服务提供商” ？ 在探索阶段，将所有内容外包给服务提供商可能很好。 但是随着业务的成熟，关于这些决定如何影响组织（结构，运营，TCO等）的真实讨论。 这是一个影响我们客户的非常实际的问题。

当您开始为新产品/服务找到可预测的模式，决定要优化某些部分时（包括成本和技术因素，例如延迟，尾部延迟等），您可能会认为无服务器方法过于昂贵，并且可能值得拥有更多堆栈部分的所有权。 看看这种无服务器及其周围基础设施的账目，这对于使用模式更可预测的应用程序来说太昂贵了

最后，对于确实能产生大量收益的现有应用程序，您不能仅仅将其全部神奇地转移给服务提供商。 但是，您可以尝试对其中的某些部分进行现代化改造，以参与公司的一些较新的数字计划。 我们看到组织通过对基于容器和Kubernetes构建的服务体系结构（微服务/ API / SOA等）进行现代化改造，朝着更高性能的IT迈进了巨大的步伐，如果将其扩展到其逻辑结论，则可以将其构建为组织服务的平台，从而实现组织的各个部分都变得“无服务器”。 也就是说，组织的某些部分（从事探索性工作的人们）可以利用企业的其余部分，而不必严格“拥有”完整的实施方案。

企业产品组合的不同部分以及应用程序开发生命周期的不同范围要求使用不同的工具和方法，所有这些工具和方法都旨在“在当前环境下，最快实现价值的最佳方法是什么？”。 我们应该更加专注于发掘我们真正的“背景”，并基于此做出关于投资，所有权，技术等的最佳决策。

问你自己：

• 您在产品生命周期中处于何处？
• 您应该拥有什么技术来解决业务问题？
• 您的团队目前对现有技术有多满意？
• 您正在考虑采用“无服务器”功能的功能对您的业务有多么战略和“核心”？

很高兴在评论中或Twitter @christianposta上发表分歧或想法

尽可能做到无服务器，但不要超过 2018年9月14日发布的服务器。

翻译自: https://www.javacodegeeks.com/2018/09/be-as-serverless-as-you-can-but-not-more-than-that.html