在移动终端上采用无服务器后端是商业的焦点

日期: 栏目:科技资讯 浏览:2 评论:0
编者按:以“知乎云”为例,结合本凯霍(Ben Kehoe)关于无服务器和数字化效益的思维框架,解释了为什么无服务器云计算值得企业数字化团队采用,提出了“在移动上使用无服务器后端是业务的重心”的观点。

云感知和面向移动的无服务器架构

知乎云于2017年8月8日上线,是广州爱范儿科技有限公司旗下的数字化服务平台,提供一体化云服务,以“数据”和“营销”双引擎驱动行业数字化升级。知云是国内首家专注于小程序开发的后端云服务,为开发者提供最低门槛的无服务器免服务架构接入体验。

在移动终端上采用无服务器后端是商业的焦点

上图《企业移动架构:云感知vs传统云》对比了常见云计算平台和云感知无服务器平台上托管的移动(小程序)的不同软件架构。在两种不同的组合下,软件团队(包括测试、运营和产品管理)需要持续关注的技术组件范围是后者的数倍。在传统架构下,移动软件团队需要设计、开发和持续维护的软件组件不仅包括移动终端,还包括相应的业务逻辑、接口服务和底层连接独立数据库的一系列中间件软件代码,层次多、依赖关系复杂。事实上,每次架构中增加一个组件,团队都必须长期维护这个组件对应的软件代码。

对比新旧架构不难发现,移动后端通过“云感知”的无服务器平台实现相同的功能,而软件团队只需要专注于业务逻辑的设计、测试、开发和持续运维,即以不同的功能表达各种业务逻辑和功能3354,这是软件代码的最小单位。例如:用户如何使用小程序提交表单,如何支付产品和服务订单等。知云将移动终端后台所需的所有中间件功能封装成如图所示的六个服务。软件团队只需要了解云的官方文档和样本代码,就可以专注于业务功能的开发,比如支付和根据事件触发不同的工作流。

作为全球最早为社交网络原生的移动应用——小程序提供托管服务的提供商,爱范儿“知乎云”已经发展成为既能托管移动端又能托管小程序的后端平台,免去了配置和维护所有后端计算资源的麻烦。多出的人力时间可以更专注于如何提供更多更好的业务功能。

企业移动应用向无服务器(第三方)服务的后台迁移对整体团队效率意味着什么?接下来,我们来看看云机器人技术科学家Ben Kehoe是如何看待企业软件采用无服务器开发模式的,这对于你在思考企业移动和小程序(软件)是否采用无服务器有着同样的参考价值。

无服务器软件开发模式侧重于“以业务为中心”

无服务器是一种关注商业价值的方法。

团队在移动业务代码中专注于业务的具体功能,这样大家就可以专注于写业务逻辑,而不是写业务逻辑的支撑基础设施。

(第三方)托管服务让你专注于编写函数。更少的运维资源可以腾出人力和资金,为客户创造新的价值。

可观察性为您提供了处理MTBF和MTTR的工具,这两者都可以衡量您的客户获得价值的频率。在云计算上花更少的钱,意味着可以更直接地花钱支持价值创造。

你应该选择无服务器,因为你想专注于创造价值——。在你的公司里,你努力应用技术来创造商业价值。例如,回到成本,Lyft的AWS账单,一年1亿美元,最近成了新闻。许多人附和说他们可以做得更便宜,但这不是重点。如果Lyft尽可能切换到Lambda并托管服务,他们的账单会更低吗?也许吧。但是当他们花时间重新架构时,这又有什么用呢?他们会失去重点。公司正处于发展比成本控制更重要的阶段。最终,这种情况可能会改变。上市公司对股东负责,所以降低成本才能给他们带来价值。但对于今天的Lyft来说,为客户提供价值意味着执行他们当前的应用程序和流程。他们正在做出无服务器的选择。

无服务器从来没有涉及到我们称之为无服务器的技术。所以我们称之为

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 最近为选择技术提供了一套出色的指导方针。

这些天来我对无服务器的思考是按考虑顺序进行的:如果平台拥有,请使用–如果市场拥有,请购买;如果你可以重新考虑需求,请执行–如果必须构建,请拥有它。

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 阶梯。配置是你的朋友。数天的编程时间可以节省数小时的配置时间。害怕可能发生的巨大事件。接受不拥有自己命运的不适感。找到你的业务价值部分,并实现 Serverless 状态。

(部分内容来自 Ben Kehoe 的Serverless is a State of Mind)

标签: serverless  知晓云  架构  中间件 

标签:

评论留言

我要留言

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。