无服务员的业务案例-王其杉博客|程序员|科技新闻
扎克·坎特
贡献者
扎克·坎特是斯特迪的联合创始人。
此贡献者的更多帖子
为什么亚马逊正在吞噬世界
尽管无服务器通常被拥护为降低成本和按需大规模扩展的一种方式,但是采用无服务器优先的方法有一个特别令人信服的理由:它是随着时间的推移实现最大开发速度的最佳方式。正确实施并不容易,当然也不是万能药,但做对了,它为最大限度地提高发展速度铺平了一条非同寻常的道路,正因为如此,在当今的创始人和投资者中,无服务器是最被低估、被低估的技术运动。
无服务器的情况始于一个简单的前提:如果一个特定市场中最快的启动将获胜,那么最重要的事情是随着时间保持或增加开发速度。这听起来是显而易见的,但很少有初创公司将保持或增加开发速度作为明确的目标。
“发展速度”,具体地说,是指你能够向客户交付附加价值单位的速度。当然,额外的客户价值单位可以通过向现有客户运送更多价值或者通过向新客户运送现有价值——即现有特征——来交付。
对于许多技术初创企业,特别是在B2B领域,这两者都由开发吞吐量来决定(前者由于明显的原因,而后者因为新客户登机常常受到工程师必须构建的登机自动化的限制)。无服务到底是什么意思?有点用词不当。正如云计算并不意味着数据中心消失在以太中那样——它意味着那些数据中心正在由其他人运行,服务器可以按需提供,按小时支付——无服务器并不意味着没有服务器。
总有服务器在什么地方。广义上,无服务器意味着您不负责这些服务器的所有配置和管理。无服务器的良好定义是每次使用付费计算,其中正常运行时间不受开发人员的控制。零使用,零成本。如果服务出故障了,您不需要为备份负责。AWS在2014年以一个名为AWS Lambda的“无服务器计算”平台开始了无服务器运动。
尽管像AWS的EC2产品这样的“正常”云服务器必须预先提供,并且无论它是否被使用,都按小时计费,但是AWS Lambda是即时按需提供的,并且仅按请求计费。Lambda非常便宜:每请求0.0000002美元,每千兆字节计算0.00001667美元。而且,如果用户在EC2上遇到容量限制,则必须增加服务器大小,而Lambda将或多或少地无限扩展以适应负载,而无需任何手动干预。而且,如果EC2实例出现故障,开发人员将负责诊断问题并将其重新联机,而如果Lambda死亡,则另一个Lambda可以代替它。
尽管Lambda——和诸如Azure功能或Google云功能等同服务——从成本和容量的观点来看具有难以置信的吸引力,但事实是,对于初创企业采用特定技术,节省资金和准备规模是非常差的理由。很少有初创公司会因为花费太多的钱在服务器上或者由于无法扩展以满足客户需求而失败,事实上,优化这两者中的任何一个都是过早扩展的一种形式,在一个或多个维度(招聘、营销、销售、产品特性,甚至层次结构/标题)上的过早扩展是死亡的主要原因。对于大多数初创企业来说。换句话说,过早地优化成本、规模或正常运行时间是一种反模式。
当人们谈论无服务器方法时,他们不仅仅意味着将运行在服务器上的代码分割成Lambda函数,以便实现更低的成本和更容易的扩展。适当的无服务器架构是构建现代软件应用程序的一种完全不同的方式,这种方法被称为无服务器的、服务全程的方法。
它开始于积极采用现成的平台,即管理服务,例如AWS Cognito或Auth0(用户认证-注册和签入即服务)、AWS Step函数或Azure Logic Apps(工作流-编排-即服务)、AWS AppSync(GraphQL backend-as-a-service)或更熟悉的服务。像条纹。
类似Lambda的产品提供服务功能,而管理服务提供服务功能。换句话说,区别在于您编写和维护用于无服务器计算的代码(例如,函数),而提供者编写和维护用于托管服务的代码。对于托管服务,平台提供功能和管理其背后的操作复杂性。
通过采用托管服务,应用程序的大部分“商品”功能——身份验证、文件存储、API网关等等——由云提供商的各种现成的平台处理,这些平台与您自己的“粘合剂”代码的薄层缝合在一起。粘合代码——以及使应用程序独特的其余业务逻辑——在超廉价、无限可伸缩的Lambda(或等效)基础设施上运行,从而完全消除了对服务器的需求。像我们这样的小型工程团队正在使用它来在架构中构建非常强大、易于维护的应用程序,随着应用程序变得更加复杂,该架构产生了前所未有的、可持续的开发速度。
采用无服务式的、全服务的理念是一种权衡。构建一个完全无服务器的应用程序需要对短期开发速度进行巨大的打击,因为构建“服务”通常比使用AWS的现成服务要快得多。当开发人员考虑像Stripe这样的服务时,“build vs.”甚至不是问题——使用Stripe的支付服务明显比自己构建支付服务要快。更准确地说,理解Stripe的支付模型比理解和构建专有支付模型要快,这既证明了支付空间的复杂性,也证明了Stripe开发的直观服务。
但是对于处理诸如身份验证(Cognito或Auth0)或工作流编排(AWS Step Functions或Azure Logic Apps)之类的问题的开发人员来说,理解和实现服务提供者的模型通常比在应用程序的代码库中实现功能要慢(或者通过从头开始编写)。ch或者通过使用开源库)。通过选择使用托管服务,开发人员有意选择在短期内放慢速度,这对于初创企业来说是难以下咽的药丸。可以理解的是,许多人现在选择快速行驶,并开始自己的行驶。
这种方法的问题回到了软件开发中一个古老的公理:“代码不是资产代码,而是债务。”它是一种资产,使公司能够向客户交付价值,但它也需要维护,这些维护必须随着时间推移而考虑和分布。所有条件都一样,初创公司希望尽可能小的代码库(当然,前提是开发人员不会走得太远,并且编写聪明但不可读的代码)。更少的代码意味着更少的表面积需要维护,也意味着更少的表面积让新工程师在爬坡过程中掌握。
这就是使用托管服务的魔力。初创企业将供应商的代码作为资产进行有益的使用,而不必将代码债务保持在其“技术资产负债表”上。相反,代码位于供应商的资产负债表上,而供应商的工程师的任务是维护、改进和记录代码。换言之,初创公司得到的代码是自我维护、自我改进和自我记录,相当于免费聘请一流的工程团队,专门负责代码库的非核心部分。或者,更准确地说,以可预测的每次使用成本。与使用Cognito或Auth0等托管服务相比。在第一天,它可能没有初创公司的愿望清单上所有的功能。不同之处在于,供应商拥有一个工程师和产品经理团队,他们的唯一任务就是日复一日地将改进交付给这项服务。
如果在一个初创公司的工程团队中有一个统一的原则,那么就应该编写尽可能少的代码,并且尽可能少地负责非核心服务。通过采用这种理念,初创企业可以构建一个平台,以极其可预测的、纯可变的成本处理数十亿笔交易,同时几乎没有差错监督。
如此懒惰需要惊人的训练。善于管理无服务器代码库和无服务器基础结构是非常重要的。这意味着围绕测试和自动化建立广泛的实践,这意味着更大的前期时间投资。与托管服务集成可能非常痛苦,因为要花几天时间来理解所有差距、陷阱和边缘情况。实现专有解决方案的诱惑可能令人难以置信,特别是当它意味着一个故事可以在几分钟或几个小时内完成,而不是几天或更长时间。
这意味着当一个服务仅能满足开发人员80%的需求时,就需要编写不稳定的解决方案。随着丢失的20%的功能被释放,这意味着重构代码以移除变通方法,即使它工作正常,并且改变它没有短期效益。大量的早期投资意味着无服务器/托管服务优先的方法不是