Serverless 是一种思想状态

来源 | Serverless 公众号；做者 | Ben Kehoe；译者 | donghui

函数不是重点

若是你由于喜欢 Lambda 而选择 Serverless，你这样作的缘由是错误的。若是你选择 Serverless，是由于你喜欢 FaaS，你这样作的缘由也是错误的。函数不是重点。

固然，我喜欢 Lambda ——但这不是我提倡 Serverless 的缘由。

不要误解我，函数很好。它们让你透明地伸缩，你没必要管理运行时，并且它们自然地适合事件驱动的架构。这些都是很是有用的特性。

可是函数最终应该成为整个解决方案的一小部分。你应该使用包含业务逻辑的函数做为托管服务之间的粘合剂，这些托管服务提供了构成应用程序的大部分繁重工做。

托管服务不是重点

咱们很幸运，云提供商可以为应用程序的许多不一样部分提供如此普遍的托管服务。数据库、身份和访问管理（真高兴我不用本身拥有它！）、分析、机器学习、内容分发、消息队列等各类不一样模式。

托管服务以较少的麻烦提供你所需的功能。你没必要给他们运行的服务器打补丁。你没必要确保自动缩放在没有大量空闲容量的状况下正确地提供所需的吞吐量。

托管服务显著下降了你的运维负担。托管服务很棒——但……它们不是重点。

运维不是重点

很高兴知道你能够应用更少的运维资源来保持应用程序的健康。尤为重要的是，你所须要的资源主要是根据你所提供的函数数量而不是流量来伸缩的。

减小运维、效率更高——但……这不是重点。 

成本不是重点

好吧，有时候企业但愿你作的只是下降成本——而这正是你所关心的。Serverless 会帮助你作到这一点。但总的来讲，云计算帐单并非问题的重点。

你的云帐单只是云应用程序总成本的一个组成部分。首先，是运维人员的薪水——若是你的运维人员资源更少的话，成本会更低。还有你的开发成本。

这里有不少成本优点——但……这些都不是重点。 

代码不是重点

代码不只不是重点，并且是一种责任。代码最多只能作你想作的事情。Bug 会削弱这一点。你只会由于编写更多的代码而失去重点。你拥有的代码越多，偏离你预期价值的机会就越多。理解这是一种文化转变。

技术一直以来都很困难。聪明的人经过技术创造价值。因此开发者开始相信聪明是与生俱来的，是好的。咱们花了这么长时间来制造瑞士手表，以致于没有意识到石英卡西欧的出现，并指责这种演变缺少优雅。

咱们须要理解并解决业务问题，而不是将咱们的聪明才智用于解决技术问题。当你必须编码时，你是在解决技术问题。 

技术不是重点

咱们这样作的缘由，是为了达到某种商业目标。你的组织试图创造的业务价值就是重点。

如今，有时候，你卖的是技术。但即便你的产品是技术，那也可能不是你销售的产品的价值所在。

有句老话说，人们买的不是钻子，而是洞。当你须要在墙上钻个洞时，你不会在意钻得有多漂亮，你只在意钻得有多好就能钻出你须要的洞。

在 iRobot，咱们不卖机器人。咱们甚至都不卖吸尘器。咱们卖清洁房屋。Roomba 让你有时间回到你的平常生活中去关注对你来讲重要的事情。因此，若是技术不是重点，咱们在这里是为了什么?

重点是专一

Serverless 是一种专一于业务价值的方法。

函数如何帮助你交付价值？它们让你将重点放在编写业务逻辑上，而不是为业务逻辑编写支持的基础设施。

托管服务让你能够专一于编写函数。较少的运维资源能够腾出人力和资金，为客户创造新的价值。

可观察性为你提供了处理 MTBF 和 MTTR 的工具，这两种工具均可以度量你的客户得到价值的频率。在云计算上花更少的钱意味着你能够更直接地把钱花在支持创造价值上。 

专一是选择 Serverless 的缘由

你应该选择 Serverless，由于你想专一于创造价值——在你的公司，你努力应用技术来创造商业价值。

回到成本上，Lyft 的 AWS 帐单，每一年1亿美圆，最近已经成为新闻。许多人插话说他们能够作得更便宜——他们不能，但这不是重点。

若是 Lyft 切换到 Lambda 并尽量地托管服务，他们的帐单会更低吗?可能。但当他们花时间从新架构时，这会有什么用呢?他们会失重点。

公司正处于发展比成本控制更重要的阶段。最终，这种状况可能会改变。上市公司对股东负责，所以下降成本能够为他们带来价值。可是对于如今的 Lyft 来讲，为他们的客户提供价值意味着执行他们当前的应用程序和流程。他们正在作一个 Serverless 的选择。

我要告诉你的是，Serverless 从未涉及到咱们称之为 Serverless 的技术。那么咱们所谓的 Serverless 技术和它有什么关系呢?

Serverless 是专一业务价值的结果

技术是你如何交付价值的结果。开发团队和运维团队传统上是分开的，由于他们有不一样的专一点。但咱们看到这一趋势正在改变。

传统的模式把重点放在技术上——开发技术 vs 运维技术。可是咱们看到人们意识到重点应该放在价值上——交付的功能，包括如何构建和运行。

当咱们采用这种关注业务价值的概念，并运行其逻辑结论时，咱们获得 Serverless。

当你想要专一于交付价值时，你想要编写函数。当函数须要状态时，须要一个数据库。要从别人那里得到它，你可使用 DBaaS——你能够根据它让你专一的程度来在你的选项之间进行选择。

在选择托管服务时，其中一些甚至多是面向用户的。若是你可使用社交帐户登陆而不是拥有本身的帐户，那你就少了一件须要管理的事情，也少了你拥有的对用户体验的筹码。

如今，对于你所外包的一切，你仍然有责任。你的用户并不关心他们的糟糕体验是由第三方形成的，这仍然是你的问题。你须要将中断留给你的用户，同时接受你不能彻底控制你在那里的命运。这是一个不舒服的地方，但它是值得的。

在这些事情上你不能赢得分数——但你能够失去。这意味着你须要知道“坏”是什么样子。这就要求你对外包的产品和技术有足够的了解，以确保你为用户提供了足够的质量。

请注意，在一个重点领域有深刻的专业知识，而在相邻领域有普遍但薄弱的知识，这与 T 型技能的概念很是类似——适用于组织和团队。 

Serverless 是一种特质

Serverless 是公司的一个特质。若是一个公司决定它不该该拥有不是实现其商业价值的核心技术，那么它就是 Serverless 的。不多有公司是彻底 Serverless 的。可是在公司内部，仍然能够有 Serverless 的部分。

若是你的团队决定只关注它所传递的价值，并将任何超出这些价值的东西委托给另外一个团队，或者理想状况下委托给外部——那么你的团队就会变得 Serverless。你不能老是选择使用外部技术——这很好，你仍然能够在有限的条件下作出最好的选择。

在一个足够大的组织中，它就再也不重要了。当 Amazon.com 使用 Lambda 时，它是彻底 Serverless 的，尽管它在某种意义上是 on-prem 的。但若是只有你一我的呢?

若是你对 Serverless 感到兴奋，但在公司里感到彻底孤独怎么办?若是你与实际的商业价值相去甚远——若是你为一个服务于建立面向用户内容的团队的团队打补丁，那该怎么办?我想说服你，你今天能够在任何状况下变得 Serverless。

Serverless 是方向，而不是终点

我曾经把 Serverless 技术做为一个光谱来讨论，由于我知道没有一条清晰的线来区分 Serverless 技术和非 Serverless 技术。个人意思是，几乎没有一条明亮的线来分隔任何给定的分组，因此我在这个假设中我是很安全的。

我讲过像 Kinesis 这样须要管理碎片的东西，它是 Serverless 的，但比 SQS 少一些 Serverless。你没必要使用 RDS 修补实例，但须要选择实例类型和数量。这些技术都是不一样程度的 Serverless。

但最近我开始意识到将 Serverless 描述为光谱的一个问题是，它并不意味着移动。仅仅由于你使用的是某种指定为 Serverless 的产品，并不意味着你应该感到本身已经得到了 Serverless -继续使用它并认为你已经选中了 Serverless 复选框是能够接受的。 

爬上 Serverless 阶梯

我开始把 Serverless 想象成一个***。你正在攀登某种必杀技，在那里你能够在没有开销的状况下交付纯业务价值。但阶梯上的每一个梯级都是有效的 Serverless 步骤。

若是你从 on-prem 移动到公共云，那是阶梯。若是你从虚拟机迁移到容器，那简直就是天梯。若是你从没有容器编排或自定义编排迁移到 Kubernetes，这是阶梯。若是你从长期运行的服务器转移到自托管的 FaaS，那将是天梯。但总有一个梯级在你之上，你应该始终保持攀登。 

"阶梯"没有传达的一件事是它不是线性的。从虚拟机迁移到容器再到 Kubernetes 都是在梯级上的阶梯，可是将虚拟机从本地迁移到云也是如此。在这些状况下，一般没有一个明确的“更好”。

我想到了通往山顶的许多路径的比喻，但我喜欢***的一点是它能够是无限的。没有最终状态。我喜欢 Lambda，但我一直在寻找更好的方式来交付代码，使我更关注价值。

Serverless 是一种思想状态

Serverless 是关于你如何决策的问题，而不是你的选择。每一个决定都是有约束的。可是，若是你知道正确的方向，即便你不能以这种方式直接移动，也能够选择最紧密结合的选择，而后再向上移动另外一个梯级。那么，你如何采用这种思惟方式？你如何作出 Serverless 选择？

配置是你的朋友

我认为许多开发人员看不起配置，认为它“不是真正的编程”。如今有一种对编程的盲目崇拜。咱们被告知“软件正在吞噬世界”，而咱们却不许确地将其翻译成“编码正在吞噬世界”。

咱们已经相信，开发人员是组织中惟一重要的人，而咱们的生产力意识是惟一重要的事情。咱们想在区域中感觉到，这就是编码所提供的。这方面的任何障碍都对企业不利。咱们对进入该区域是否真的比替代路线更快，更好地创造价值没有任何感受。 

切记：数天的编程能够节省数小时的配置

约束是好的。删除选项能够帮助你保持专一。显然，并非全部的约束都是好的——可是通常来讲，作通常事情的能力是以花费更长的时间来作一件特定的事情为代价的。护栏可能会磨损，但你会比一直盯着护栏边缘跑得快。

这样，Serverless是关于极简主义的。消除干扰。Marie Kondo 如今很大，而且一样的建议也适用。查找你的堆栈中不会产生价值的组件。 

惧怕可能发生的巨大事件

可能性蕴含着隐藏的复杂性。对于任何技术，个人主要评估指标之一是它有多少能力超出手头的任务。当有不少额外的空间时，就会处理和学习没必要要的复杂性。

人们把 Kubernetes 吹捧为一个单一的工具来完成每个云需求——它确实能够！但若是一切皆有可能，一切皆有可能。对于一个给定的任务，Kubernetes 可能会出错，由于你没有考虑它在与该任务无关的状况下的行为方式。

另外一方面，当你考虑 Serverless 的服务时，你可能必须在主要提供商提供的80%的解决方案或第三方提供商提供的更适合你需求的服务之间作出选择。可是该新提供商的运维需求是什么？身份验证是什么样的？这些是隐藏的复杂性，你须要引入这些特性，你须要权衡这些特性差别。 

接受不拥有本身命运的不适感

当你使用托管服务时，提供者中断会带来压力。你没法解决他们的问题。这是没法回避的——这老是让人感受很糟糕。你可能会想，“若是我运行本身的 Kafka 集群而不是使用 Kinesis，我就能够找到问题并解决它”。这多是真的，但你应该记住两件事：

• 那会分散人们对创造商业价值的注意力。
• 你几乎确定会在运行它方面作得更差。你会遇到更多更糟糕的事情。服务提供商的人生目标就是擅长于此——他们有规模经济，而你没有。

超越“我老是能够本身创建它”的态度可能很难。Jared Short 最近为选择技术提供了一套出色的指导方针。
_
这些天来我对无服务器的思考是按考虑顺序进行的。–若是平台拥有，请使用–若是市场拥有，请购买–若是你能够从新考虑需求，请执行–若是必须构建，请拥有。——@ShortJared

所以，若是你使用的是云平台，请尽量留在生态系统中。这样，你就能够从方程式中消除不少可能性。可是，若是没法在平台上得到所需的东西，请从其余地方购买。

若是你不能彻底购买所需的东西，你是否能够从新考虑本身在作什么以适应你能够购买的东西？这一点真的很重要。它到达了上市时间的核心。

若是你有一些你认为有价值的东西，你会想要尽快运送。但更快地运送一些东西，总比精确地构建好，由于你还不知道这是否是正确的东西。

等待构建出正确的东西不只会花费更长的时间，并且后续的迭代也会更慢——而且对其进行维护将占用你未来可用于运送更多东西的资源。即便在该技术不是 Serverless 的状况下，这也适用：始终询问对你的要求的调整是否能够实现更快，更好或更专一的价值交付。

可是，最后，若是必须构建它，请拥有它。寻找一种使其不同凡响的方法。如今，这并不意味着你已经构建的全部内容都应该变成差别化的。在完美的世界里只看你买不到的东西。想象一下彻底 Serverless 的绿地实现会是什么样子，并找到须要在那里构建的内容。 

找到你的业务价值部分

所以，从根本上讲，你但愿找到你的业务价值部分。你所服务的技术工做是什么？也许你与面向用户的产品相去甚远。你可能只贡献了一小部分。但它在那里，你能够找到它-并专一于这一价值。

从你为组织中其余人提供的直接价值开始，并专一于此。而后开始追踪价值链。确保全部决策都围绕你所创造的价值。作出 Serverless 的选择。

雇用能够自动完成工做的人员，而后继续为他们提供工做。——@jessfraz

我喜欢 Jessie Frazelle 的话。你能够把它转过来：自动化完成工做，继续作有要求的工做。

请记住，你不是工具。对于你要建立的任何价值，请自动化建立。若是你管理构建服务器，请找到使它们成为自助服务的方法，所以你交付的不是构建自己，而是构建工具，以便团队能够本身交付构建。 

总结：Serverless 是一种思想状态

重点不是函数，托管服务，运维，成本，代码或技术。重点是专一——这就是选择 Serverless 的缘由。

Serverless 是专一业务价值的结果。这是一个特质。这是方向，而不是终点。爬上永无止境的 Serverless 阶梯。

配置是你的朋友。数天的编程时间能够节省数小时的配置时间。惧怕可能发生的巨大事件。接受不拥有本身命运的不适感。

找到你的业务价值部分，并实现 Serverless 状态。 

英文原文连接：https://read.acloud.guru/serverless-is-a-state-of-mind-717ef2088b42