无服务器计算、发布速率和发布加速度

通联网络是国内著名的虚拟主机和域名注册提供商。独创的第6代虚拟主机管理系统,拥有在线数据恢复、Isapi自定义,木马查杀等30余项功能.千M硬件防火墙,为您保驾护航!双线虚拟主机确保南北畅通无阻!

无服务器计算、发布速率和发布加速度

2022年6月16日 主机租用 0

编者按:本文探索软件发布「速率」和「加速度」与无服务器计算的关系。众所周知,无服务器能简化数字化业务运维和降低成本,但这还不是本文重点,重点是解析如何在「敏捷」协作中实现更快的软件「发布速率」和「发布加速度」。

上周在 JeffConf 的一个小组讨论中,一位小组成员(我忘了是谁)说,「公司对通过云节省托管成本并不感兴趣,因为它的成本已经相对较低。企业感兴趣的是提高他们的软件功能发布速率」。

这一洞察对我冲击很大。我对无服务器价值的认知一直是随之而来的降低「总拥有成本 / TCO」,减少维护、减少错误修复和问题似乎与 Serverless 配合得很好,但我并没有过多考虑 Feature Velocity(FV)(软件发布速率)。

有时很难在技术团队的环境中定义它,仅仅是因为功能不是固定的大小 / 时间范围,因此您最终会得到不同的功能,坦克需要不同的开发工期。

您可以把每个功能分解为一个称为「单元工作」的已知交付单元(许多人都这样做),但在开始开发一个功能之前,这只是猜测(对于有经验的团队来说,这是经过专业评估的猜测)。这也不是特别容易做到,因为那里有偏见。如果一个团队希望成为具有高发布速率团队,那么他们可以轻松地在开始时添加额外的(超额预估的)「单元工作」并快速交付,瞧:我们是高发布速率团队。

单元工作可以是常见的工作天数或故事点,许多敏捷方法使用这些作为确定团队是否足够快地交付工作的基础。

对于团队来说,了解他们是领先还是落后是一个广泛且相对有用的概念。对于技术团队以外的人来说,这也是一个有用的概念,可以用来衡量团队是否在执行(或不执行!)工作任务。

将发布速率作为衡量技术团队绩效的标准,我遇到的最大问题是:它只是针对连续性很强的软件开发过程的一个「快照工具」。在管理良好的团队中的任何给定时间点,您都可以通过查看发布速率来了解团队是领先还是落后(通常是落后的……但这是关于评估软件工作的另一个话题)。

在一个小型技术团队中,您可能有多个关注领域,包括维护基础设施、修复错误、「架构债」、「技术债」等。

而且您还将让 DevOps 同事们围绕它工作,并使用 CI/CD 管理开发和软件代码库等。

换句话说,技术团队的工作绝不仅仅是开发新功能。随着时间的推移,团队会执行许多其它任务,这些任务可能会影响您的工作,从而影响您的发布速率。

这真的很简单。发布速率(Feature Velocity)需要在一段时间内进行,而不是作为「快照」。换句话说,它需要在整体而不是孤立的背景下进行。

如果您构建了一个软件并发布它,并产生了许多错误,那么您就降低了您未来的发布速率。

如果您在特定技术栈之上构建软件,然后发现需要替换技术栈,那么您将再次降低未来的发布速率。

当然,所有这些都是假设,但是当您将无服务器解决方案添加到技术平台中时,会发生什么变化?

因此,我经常谈论的主要内容之一是无服务器的总体拥有成本。事实是,如果您构建了正确的解决方案,就管理和维护整个解决方案所花费的时间而言,您最终应该会承担更小的 DevOps(开发 + 运维)负担。

无服务器的优点之一是您可以更轻松地「就地」替换解决方案的元素。将 Lambda 函数替换为另一个函数通常对整个解决方案的影响很小。这意味着技术债和缺陷修复实际上可以提高

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注