来源 | Serverless 公众号；作者 | Ben Kehoe ；译者 | donghui
如果你因为喜欢 Lambda 而选择 Serverless，你这样做的原因是错误的。如果你选择 Serverless，是因为你喜欢 FaaS，你这样做的原因也是错误的。函数不是重点。
当然，我喜欢 Lambda ——但这不是我提倡 Serverless 的原因。
不要误解我，函数很好。它们让你透明地伸缩，你不必管理运行时，而且它们天然地适合事件驱动的架构。这些都是非常有用的特性。
但是函数最终应该成为整个解决方案的一小部分。你应该使用包含业务逻辑的函数作为托管服务之间的粘合剂，这些托管服务提供了构成应用程序的大部分繁重工作。
我们很幸运，云提供商能够为应用程序的许多不同部分提供如此广泛的托管服务。数据库、身份和访问管理（真高兴我不用自己拥有它！）、分析、机器学习、内容分发、消息队列等各种不同模式。
托管服务以较少的麻烦提供你所需的功能。你不必给他们运行的服务器打补丁。你不必确保自动缩放在没有大量空闲容量的情况下正确地提供所需的吞吐量。
托管服务显著降低了你的运维负担。托管服务很棒——但……它们不是重点。
很高兴知道你可以应用更少的运维资源来保持应用程序的健康。尤其重要的是，你所需要的资源主要是根据你所提供的函数数量而不是流量来伸缩的。
减少运维、效率更高——但……这不是重点。
好吧，有时候企业希望你做的只是降低成本——而这正是你所关心的。Serverless 会帮助你做到这一点。但总的来说，云计算账单并不是问题的重点。
你的云账单只是云应用程序总成本的一个组成部分。首先，是运维人员的薪水——如果你的运维人员资源更少的话，成本会更低。还有你的开发成本。
这里有很多成本优势——但……这些都不是重点。
代码不仅不是重点，而且是一种责任。代码最多只能做你想做的事情。Bug 会削弱这一点。你只会因为编写更多的代码而失去重点。你拥有的代码越多，偏离你预期价值的机会就越多。理解这是一种文化转变。
技术一直以来都很困难。聪明的人通过技术创造价值。所以开发者开始相信聪明是与生俱来的，是好的。我们花了这么长时间来制造瑞士手表，以至于没有意识到石英卡西欧的出现，并指责这种演变缺乏优雅。
我们需要理解并解决业务问题，而不是将我们的聪明才智用于解决技术问题。当你必须编码时，你是在解决技术问题。
我们这样做的原因，是为了达到某种商业目标。你的组织试图创造的业务价值就是重点。
现在，有时候，你卖的是技术。但即使你的产品是技术，那也可能不是你销售的产品的价值所在。
有句老话说，人们买的不是钻子，而是洞。当你需要在墙上钻个洞时，你不会在乎钻得有多漂亮，你只在乎钻得有多好就能钻出你需要的洞。
在 iRobot，我们不卖机器人。我们甚至都不卖吸尘器。我们卖清洁房屋。Roomba 让你有时间回到你的日常生活中去关注对你来说重要的事情。所以，如果技术不是重点，我们在这里是为了什么?
Serverless 是一种专注于业务价值的方法。
函数如何帮助你交付价值？它们让你将重点放在编写业务逻辑上，而不是为业务逻辑编写支持的基础设施。
托管服务让你可以专注于编写函数。较少的运维资源可以腾出人力和资金，为客户创造新的价值。
可观察性为你提供了处理 MTBF 和 MTTR 的工具，这两种工具都可以度量你的客户获得价值的频率。在云计算上花更少的钱意味着你可以更直接地把钱花在支持创造价值上。
你应该选择 Serverless，因为你想专注于创造价值——在你的公司，你努力应用技术来创造商业价值。
回到成本上，Lyft 的 AWS 账单，每年 1 亿美元，最近已经成为新闻。许多人插话说他们可以做得更便宜——他们不能，但这不是重点。
如果 Lyft 切换到 Lambda 并尽可能地托管服务，他们的账单会更低吗?可能。但当他们花时间重新架构时，这会有什么用呢?他们会失重点。
公司正处于发展比成本控制更重要的阶段。最终，这种情况可能会改变。上市公司对股东负责，因此降低成本可以为他们带来价值。但是对于现在的 Lyft 来说，为他们的客户提供价值意味着执行他们当前的应用程序和流程。他们正在做一个 Serverless 的选择。
我要告诉你的是，Serverless 从未涉及到我们称之为 Serverless 的技术。那么我们所谓的 Serverless 技术和它有什么关系呢?
技术是你如何交付价值的结果。开发团队和运维团队传统上是分开的，因为他们有不同的专注点。但我们看到这一趋势正在改变。
传统的模式把重点放在技术上——开发技术 vs 运维技术。但是我们看到人们意识到重点应该放在价值上——交付的功能，包括如何构建和运行。
当我们采用这种关注业务价值的概念，并运行其逻辑结论时，我们得到 Serverless 。
当你想要专注于交付价值时，你想要编写函数。当函数需要状态时，需要一个数据库。要从别人那里获得它，你可以使用 DBaaS——你可以根据它让你专注的程度来在你的选项之间进行选择。
在选择托管服务时，其中一些甚至可能是面向用户的。如果你可以使用社交账户登录而不是拥有自己的账户，那你就少了一件需要管理的事情，也少了你拥有的对用户体验的筹码。
现在，对于你所外包的一切，你仍然有责任。你的用户并不关心他们的糟糕体验是由第三方造成的，这仍然是你的问题。你需要将中断留给你的用户，同时接受你不能完全控制你在那里的命运。这是一个不舒服的地方，但它是值得的。
在这些事情上你不能赢得分数——但你可以失去。这意味着你需要知道“坏”是什么样子。这就要求你对外包的产品和技术有足够的了解，以确保你为用户提供了足够的质量。
请注意，在一个重点领域有深入的专业知识，而在相邻领域有广泛但薄弱的知识，这与 T 型技能的概念非常相似——适用于组织和团队。
Serverless 是公司的一个特质。如果一个公司决定它不应该拥有不是实现其商业价值的核心技术，那么它就是 Serverless 的。很少有公司是完全 Serverless 的。但是在公司内部，仍然可以有 Serverless 的部分。
如果你的团队决定只关注它所传递的价值，并将任何超出这些价值的东西委托给另一个团队，或者理想情况下委托给外部——那么你的团队就会变得 Serverless 。你不能总是选择使用外部技术——这很好，你仍然可以在有限的条件下做出最好的选择。
在一个足够大的组织中，它就不再重要了。当 Amazon.com 使用 Lambda 时，它是完全 Serverless 的，尽管它在某种意义上是 on-prem 的。但如果只有你一个人呢?
如果你对 Serverless 感到兴奋，但在公司里感到完全孤独怎么办?如果你与实际的商业价值相去甚远——如果你为一个服务于创建面向用户内容的团队的团队打补丁，那该怎么办?我想说服你，你今天可以在任何情况下变得 Serverless 。
我曾经把 Serverless 技术作为一个光谱来讨论，因为我知道没有一条清晰的线来区分 Serverless 技术和非 Serverless 技术。我的意思是，几乎没有一条明亮的线来分隔任何给定的分组，所以我在这个假设中我是很安全的。
我讲过像 Kinesis 这样需要管理碎片的东西，它是 Serverless 的，但比 SQS 少一些 Serverless 。你不必使用 RDS 修补实例，但需要选择实例类型和数量。这些技术都是不同程度的 Serverless 。
但最近我开始意识到将 Serverless 描述为光谱的一个问题是，它并不意味着移动。仅仅因为你使用的是某种指定为 Serverless 的产品，并不意味着你应该感到自己已经获得了 Serverless -继续使用它并认为你已经选中了 Serverless 复选框是可以接受的。
我开始把 Serverless 想象成一个梯子。你正在攀登某种必杀技，在那里你可以在没有开销的情况下交付纯业务价值。但阶梯上的每个梯级都是有效的 Serverless 步骤。
如果你从 on-prem 移动到公共云，那是阶梯。如果你从虚拟机迁移到容器，那简直就是天梯。如果你从没有容器编排或自定义编排迁移到 Kubernetes，这是阶梯。如果你从长期运行的服务器转移到自托管的 FaaS，那将是天梯。但总有一个梯级在你之上，你应该始终保持攀登。
"阶梯"没有传达的一件事是它不是线性的。从虚拟机迁移到容器再到 Kubernetes 都是在梯级上的阶梯，但是将虚拟机从本地迁移到云也是如此。在这些情况下，通常没有一个明确的“更好”。
我想到了通往山顶的许多路径的比喻，但我喜欢梯子的一点是它可以是无限的。没有最终状态。我喜欢 Lambda，但我一直在寻找更好的方式来交付代码，使我更关注价值。
Serverless 是关于你如何决策的问题，而不是你的选择。每个决定都是有约束的。但是，如果你知道正确的方向，即使你不能以这种方式直接移动，也可以选择最紧密结合的选择，然后再向上移动另一个梯级。那么，你如何采用这种思维方式？你如何做出 Serverless 选择？
我认为许多开发人员看不起配置，认为它“不是真正的编程”。现在有一种对编程的盲目崇拜。我们被告知“软件正在吞噬世界”，而我们却不准确地将其翻译成“编码正在吞噬世界”。
我们已经相信，开发人员是组织中唯一重要的人，而我们的生产力意识是唯一重要的事情。我们想在区域中感受到，这就是编码所提供的。这方面的任何障碍都对企业不利。我们对进入该区域是否真的比替代路线更快，更好地创造价值没有任何感觉。
约束是好的。删除选项可以帮助你保持专注。显然，并不是所有的约束都是好的——但是一般来说，做一般事情的能力是以花费更长的时间来做一件特定的事情为代价的。护栏可能会磨损，但你会比一直盯着护栏边缘跑得快。
这样，Serverless 是关于极简主义的。消除干扰。Marie Kondo 现在很大，并且同样的建议也适用。查找你的堆栈中不会产生价值的组件。
可能性蕴含着隐藏的复杂性。对于任何技术，我的主要评估指标之一是它有多少能力超出手头的任务。当有很多额外的空间时，就会处理和学习不必要的复杂性。
人们把 Kubernetes 吹捧为一个单一的工具来完成每一个云需求——它确实可以！但如果一切皆有可能，一切皆有可能。对于一个给定的任务，Kubernetes 可能会出错，因为你没有考虑它在与该任务无关的情况下的行为方式。
另一方面，当你考虑 Serverless 的服务时，你可能必须在主要提供商提供的 80%的解决方案或第三方提供商提供的更适合你需求的服务之间做出选择。但是该新提供商的运维需求是什么？身份验证是什么样的？这些是隐藏的复杂性，你需要引入这些特性，你需要权衡这些特性差异。
当你使用托管服务时，提供者中断会带来压力。你无法解决他们的问题。这是无法回避的——这总是让人感觉很糟糕。你可能会想，“如果我运行自己的 Kafka 集群而不是使用 Kinesis，我就可以找到问题并解决它”。这可能是真的，但你应该记住两件事：
超越“我总是可以自己建立它”的态度可能很难。Jared Short 最近为选择技术提供了一套出色的指导方针。 _ 这些天来我对无服务器的思考是按考虑顺序进行的。–如果平台拥有，请使用–如果市场拥有，请购买–如果你可以重新考虑需求，请执行–如果必须构建，请拥有。——@ShortJared
因此，如果你使用的是云平台，请尽可能留在生态系统中。这样，你就可以从方程式中消除很多可能性。但是，如果无法在平台上获得所需的东西，请从其他地方购买。
如果你不能完全购买所需的东西，你是否可以重新考虑自己在做什么以适应你可以购买的东西？这一点真的很重要。它到达了上市时间的核心。
如果你有一些你认为有价值的东西，你会想要尽快运送。但更快地运送一些东西，总比精确地构建好，因为你还不知道这是不是正确的东西。
等待构建出正确的东西不仅会花费更长的时间，而且后续的迭代也会更慢——并且对其进行维护将占用你将来可用于运送更多东西的资源。即使在该技术不是 Serverless 的情况下，这也适用：始终询问对你的要求的调整是否可以实现更快，更好或更专注的价值交付。
但是，最后，如果必须构建它，请拥有它。寻找一种使其与众不同的方法。现在，这并不意味着你已经构建的所有内容都应该变成差异化的。在完美的世界里只看你买不到的东西。想象一下完全 Serverless 的绿地实现会是什么样子，并找到需要在那里构建的内容。
因此，从根本上讲，你希望找到你的业务价值部分。你所服务的技术工作是什么？也许你与面向用户的产品相去甚远。你可能只贡献了一小部分。但它在那里，你可以找到它-并专注于这一价值。
从你为组织中其他人提供的直接价值开始，并专注于此。然后开始追踪价值链。确保所有决策都围绕你所创造的价值。做出 Serverless 的选择。
雇用可以自动完成工作的人员，然后继续为他们提供工作。——@jessfraz
我喜欢 Jessie Frazelle 的话。你可以把它转过来：自动化完成工作，继续做有要求的工作。
请记住，你不是工具。对于你要创建的任何价值，请自动化创建。如果你管理构建服务器，请找到使它们成为自助服务的方法，因此你交付的不是构建本身，而是构建工具，以便团队可以自己交付构建。
重点不是函数，托管服务，运维，成本，代码或技术。重点是专注——这就是选择 Serverless 的原因。
Serverless 是专注业务价值的结果。这是一个特质。这是方向，而不是终点。爬上永无止境的 Serverless 阶梯。
配置是你的朋友。数天的编程时间可以节省数小时的配置时间。害怕可能发生的巨大事件。接受不拥有自己命运的不适感。
找到你的业务价值部分，并实现 Serverless 状态。
原文链接：https://read.acloud.guru/serverless-is-a-state-of-mind-717ef2088b42
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.