编者按：本文以「知晓云」为例，结合 Ben Kehoe 对 Serverless 和数字化效益的思考框架，说明为什么 Serverless 云计算值得企业数字化团队采用，并提出「移动端采用 Serverless 后端是对业务的专注」的主张。
知晓云上线于 2017 年 8 月 8 日，是广州爱范儿科技股份有限公司旗下的数字化服务平台， 提供云端一体化服务，以「数据」+「营销」双引擎，驱动产业数字化升级。知晓云是国内首家专注于小程序开发的后端云服务，为开发者提供最低门槛的 Serverless 无服务架构接入体验。更多……
上图「企业移动端架构：知晓云 vs 传统云」对比了移动端（小程序）托管在普通云计算平台和知晓云无服务器平台的不同软件架构。两种不同组合下，软件团队（含测试、运维和产品管理）需要关注的技术对象，前者是后者的好几倍。传统架构下，移动端软件团队需要设计、开发和持续维护的软件组件不但包括移动端，还包括对应的业务逻辑、接口服务以及底层对接独立数据库的一系列中间件软件代码，层级多、依赖关系复杂。而事实上，架构中每增多一个组件，团队就必须长期维护这个组件对应的软件代码。
对比新旧架构，我们不难发现：移动端后台通过「知晓云」无服务器平台来实现同等功能，软件团队则只需专注业务逻辑的设计、测试、开发和持续运维——也就是专注用不同的函数——软件代码最小单元，来表达各种业务逻辑和功能。例如：用户如何利用小程序提交表单、如何支付产品和服务订单等。知晓云把移动端后台所需中间件功能全部封装为如图的六大服务，软件团队只需要根据知晓云官方文档和示例代码，即可专注在业务功能的开发，例如：支付和按事件触发不同工作流。
作为全球最早为社交网络原生的移动应用——小程序提供托管服务的供应商，爱范儿「知晓云」已发展为能同时托管移动端和小程序的后端平台，免去配置和维护后端所有计算资源的麻烦，多出来的人力时间可以更专注如何提供更多、更好的业务功能。
企业移动端应用后台迁移到 Serverless（第三方）服务，对团队整体的效能意味着什么？接下来，我们看看云机器人技术科学家 Ben Kehoe 针对企业软件采用 Serverless 开发模式是如何看的，这对您正在思考企业移动端和小程序（软件）是否采用 Serverless 也具备同等参考价值。
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 最近为选择技术提供了一套出色的指导方针。
这些天来我对无服务器的思考是按考虑顺序进行的：如果平台拥有，请使用–如果市场拥有，请购买；如果你可以重新考虑需求，请执行–如果必须构建，请拥有它。
My thinking on serverless these days in order of consideration.
– If the platform has it, use it
– If the market has it, buy it
– If you can reconsider requirements, do it
– If you have to build it, own it
– @ShortJared
因此，如果你使用的是云平台，请尽可能留在生态系统中。这样，你就可以从方程式中消除很多可能性。但是，如果无法在平台上获得所需的东西，请从其他地方购买。
如果你不能完全购买所需的东西，你是否可以重新考虑自己在做什么以适应你可以购买的东西？这一点真的很重要，它就是你的团队把控产品投产时间的核心。如果你有一些你认为有价值的东西，你会想要尽快运送。但更快地运送一些东西，总比精确地构建好，因为你还不知道这是不是正确的东西。等待构建出正确的东西不仅会花费更长的时间，而且后续的迭代也会更慢——并且对其进行维护将占用你将来可用于运送更多东西的资源。即使在该技术不是 Serverless 的情况下，这也适用：始终询问对你的要求的调整是否可以实现更快，更好或更专注的价值交付。
但是，最后，如果必须构建它，请拥有它。寻找一种使其与众不同的方法。现在，这并不意味着你已经构建的所有内容都应该变成差异化的。在完美的世界里只看你买不到的东西。想象一下完全 Serverless 的技术实现会是怎样的，并找到需要在那里构建的内容。
因此，从根本上讲，你希望找到你的业务价值部分。你所服务的技术工作是什么？也许你与面向用户的产品相去甚远。你可能只贡献了一小部分。但它在那里，你可以找到它——并专注于这一价值。
从你为组织中其他人提供的直接价值开始，并专注于此。然后开始追踪价值链。确保所有决策都围绕你所创造的价值。做出 Serverless 的选择。雇佣可以自动完成工作的人员，然后继续为他们提供工作。
– @jessfraz
我喜欢 Jessie Frazelle 的话。你可以把它转过来：自动化完成工作，继续做有要求的工作。
请记住，你不是工具。对于你要创建的任何价值，请自动化创建。如果你管理构建服务器，请找到使它们成为自助服务的方法，因此你交付的不是构建本身，而是构建工具，以便团队可以自己交付构建。
在中国的企业软件体系中，移动端和小程序比重越来越大，采用 Serverless 云计算的重点是 「专注」——这就是移动端选择 Serverless 后端服务的原因。
选择 Serverless 后端，而不是让团队同时开发和运营业务软件中间件，是专注业务价值的结果。这是一个特质。这是方向，而不是终点。爬上永无止境的 Serverless 阶梯。配置是你的朋友。数天的编程时间可以节省数小时的配置时间。害怕可能发生的巨大事件。接受不拥有自己命运的不适感。找到你的业务价值部分，并实现 Serverless 状态。
（部分内容来自 Ben Kehoe 的 Serverless is a State of Mind）
加载中,请稍侯......