亚马逊首席技术官的“中国台湾理论”

资料来源|人工智能-前沿作者|沃纳沃格尔翻译|核焦炭编辑|陈思作者沃纳·威格尔是Amazon.com首席技术官。他写了一篇文章,总结了在过去20年左右的时间里,AWS是如何通过改变应用程序架构和调整企业组织架构,让构建现代应用程序的客户“花更多的时间定义业务逻辑、扩展系统以轻松满足高峰客户需求、提高敏捷性,以及更快、更频繁地向市场发布新功能”。 他在文章中提到,亚马逊的“巨大集成”书店应用程序和臃肿的数据库极大地限制了我们的速度和敏捷性。 每次我们计划为客户提供新的功能或产品,我们都必须在专门为书店设计的应用程序中编辑甚至重写大量代码,将组织结构调整为一个小团队,并“给予他们对应用程序中特定部分更多的操作权限”。通过改变技术的使用方式,业务交付的速度大大提高。例如,某个汽车领域的客户将把新功能的发布时间从六个月缩短到一周。 这篇文章反映了许多地方与我们现在提倡的“中国台湾理论”是一致的。 这也是亚马逊的“中国-台湾理论”,尽管他们没有使用这个词 Amazon.com首席技术官沃纳沃格尔斯(WernerVogels)写了一篇文章,总结了过去20年左右,AWS是如何通过改变应用架构和调整企业组织架构,让构建现代应用的客户“花更多的时间定义业务逻辑,扩展系统以轻松满足高峰客户需求,提高敏捷性,并更快、更频繁地向市场发布新功能”。 他在文章中提到,亚马逊的“巨大集成”书店应用程序和臃肿的数据库极大地限制了我们的速度和敏捷性。 每次我们计划为客户提供新的功能或产品,我们都必须在专门为书店设计的应用程序中编辑甚至重写大量代码,将组织结构调整为一个小团队,并“给予他们对应用程序中特定部分更多的操作权限”。通过改变技术的使用方式,业务交付的速度大大提高。例如,某个汽车领域的客户将把新功能的发布时间从六个月缩短到一周。 这篇文章反映了许多地方与我们现在提倡的“中国台湾理论”是一致的。 这也是亚马逊的“中国-台湾理论”,尽管他们没有使用这个词 以下是文本:创新一直是亚马逊基因的重要组成部分,但大约20年前,我们迎来了一场彻底的变革 当时,我们的目标是进一步提高我们迭代过程的速度——发明、开始、重新发明、重新开始、消除过时的东西并再次重复 我们所做的改变对我们构建应用程序甚至组织企业结构的具体方式有着深远的影响。 那时,亚马逊为的客户比现在少得多。 然而,我们非常清楚,如果我们想要扩展我们提供的产品和服务,我们必须首先改变我们的应用程序架构。 尽管庞大的集成“书店”应用程序和臃肿的数据库为Amazon.com提供了充足的动力,但它们也极大地限制了我们的速度和灵活性。 每当我们计划为客户提供新的功能或产品,例如视频流,我们都必须在专门为书店设计的应用程序中编辑甚至重写大量代码。 这是一个漫长而复杂的过程,需要复杂的协调努力,极大地限制了我们快速推动大规模创新的能力。 为了从根本上解决这个问题,我们通过《分布式计算宣言》建立了一个新的变革蓝图。 这是描述新架构的内部文档 通过这个声明,我们开始通过许多称为“服务”的小型基本单元来重组我们的应用程序,从而大大提高了扩展亚马逊整体业务的能力。 然而,改变应用程序架构只是故事的前半部分 至于后一半…那是1998年,亚马逊内部的所有开发团队都在使用相同的应用程序,因此每个员工都必须为他们当前的版本跨团队进行协调。 为了支持这种新的架构,我们已经打破了功能层次,并将组织重组为小的自治团队——每个订单只有两个比萨饼。 我们将这些“双披萨团队”分配给不同的特定产品、服务或功能集,赋予他们对应用程序中特定部分的更多操作权限。 这使我们的开发人员能够成为产品所有者,并能够根据他们自己的决定快速影响单个产品 拆分我们的组织和应用程序结构无疑是一个大胆的想法,但也是一个很好的主意。 我们能够更快地向客户交付创新成果,随着亚马逊的快速发展,我们已经从每年部署数十项功能发展到今天部署数百万项功能。 更让人意想不到的是,我们在构建这一高度可扩展的基础设施方面的成功最终为另一个主要核心竞争力——2006年诞生的AWS——的发展和增长做出了贡献 然而,我们仍然坚持双比萨团队的基本组织。 当然,我们绝不是唯一一家强调创新的公司。 为了保持竞争力,亚马逊必须不断提高其敏捷性,以便不断发现新机会,创造更好的产品。 也正因为如此,越来越多的客户踏上了与亚马逊相同的旅程,转向现代应用开发。 这种新方法需要从整体架构转移到更小的基本单元或“微服务”,此外,现代应用程序的最佳实践需要在改变设计和构建技术的同时重新思考它们的管理方式。 为了成功地提高应用程序开发的敏捷性和创新速度,组织必须按照自己的顺序采用以下五个要素:微服务、专用数据库、自动软件发布管道、无服务器运行模式和连续自动化安全保证 架构模式:微服务架构模式:微服务像亚马逊这样的大多数企业最初都是基于集成应用程序来开展业务的,因为这是一个开发速度最快、难度最低的系统。 然而,这种将所有过程紧密结合并作为一个整体的方法通常会带来一系列严重的问题。 如果应用程序中的一个流程遇到峰值需求,我们只能扩展整个架构来实现单个流程的扩展。 此外,随着代码库规模的增长,函数的添加和改进变得非常复杂,这使得企业很难测试和实现新思想。 集成架构还增加了应用程序的可用性风险,因为大量相互依赖和紧密耦合的过程会由于失败而增加单个过程的影响。 这就是为什么微服务体系结构随着企业的发展而出现。 使用微服务架构,应用程序将由许多独立的组件组成,这些组件将每个应用程序的进程作为单个服务运行。 服务将专门为业务功能而构建,如在线购物车,每个服务将只负责自己的一项功能。 这些流程独立运行,并由相应的开发团队管理,因此我们可以独立更新、部署和扩展每个服务,最终满足应用程序特定功能的要求。 例如,当购物高峰时,我们可以简单地扩展购物车服务,以提高承载能力。 随着组织逐渐从集成架构转变为微服务架构,许多开发人员也希望通过流水线操作来管理各种服务中的依赖关系——这需要我们创建新的方法来实现应用程序打包和代码执行。 好消息是,凭借强大的创新成果储备,示例不再是我们今天唯一的计算选择。 您也可以使用容器或AWSLambda函数 容器是当前最流行的代码打包选项,也是更新遗留应用程序的最佳工具之一。 容器技术为我们带来了出色的应用程序可移植性和设置灵活性 Lambda使每个人更容易获得他们需要的功能——使用代码编写业务逻辑。 微服务体系结构的另一个主要要求是我们必须为它建立服务之间的通信模式。 目前,大多数应用程序继续使用应用编程接口连接,但是有些选择在不同的服务之间发送数据。 具体来说,它包括用于实时数据处理的流、用于根据数据变化触发响应的事件、以及用于应用层通信和可见性的服务网格等。 您可以根据需要选择最适合您的应用程序的集成方法。 数据管理:特殊数据库数据管理(Special Database DatabaSe M anagement):特殊数据库的现代应用程序采用解耦数据存储机制,其中微服务和数据库被一个接一个地映射,这意味着我们不再需要维护大量的整体数据库。 这也是对传统应用程序的重要创新,旨在解决集成应用程序在规模增长时遇到的可扩展性和容错问题。 此外,单个数据库也代表单点故障源,很难满足一组不同微服务的特定要求。 通过将数据与微服务分开,我们可以自由选择最适合我们需求的不同数据库类型。 对于大多数应用程序,最好的选择仍然是关系数据库;但是也有其他应用程序有不同的数据要求。 例如,如果我们运行的应用程序使用高度连接的数据集(如推荐引擎),我们可以选择一个具有存储和导航关系的图形数据库,如AmazonNeptune。 或者,如果您的应用程序需要实时访问数据,您也可以选择内存中的数据库,如亚马逊塑料(AmazonElastiCache),它通常用于游戏和物联网应用场景中。 一般来说,能够完全满足您的微服务需求的数据库是最理想的数据库选项 软件交付:自动发布管道(Automatic Release Pipeline)软件交付:自动发布管道当我们告别整体架构,重组为一个双披萨团队时,自动发布管道应运而生 这是为了摆脱原来的单一发布渠道,让每个团队独立地交付自己的开发结果。 尽管这种新方法消除了开发和交付更新等协调挑战,但也给我们带来了许多新挑战。 首先,要保持发布过程的一致性和所有团队的质量变得非常困难。 特别是考虑到发布过程中的每一步都是手动完成的,这无疑会大大增加人为错误的可能性。 我们的解决方案采取双管齐下的方法:标准化加自动化 首先,我们将软件交付过程定义为最佳实践模板,为云环境中所有基础架构资源的建模和配置提供标准 这些“基础架构即代码”模板可以帮助我们的团队从正确的地方开始,模板通过代码为应用程序提供整体技术堆栈,而不是依赖手动过程。 在亚马逊,这确保了每个团队可以根据我们的需求配置流程和部署 其次,我们开始使用自动化技术来消除软件交付管道中的手动过程。 借助自动发布管道(包括连续集成和连续部署,简称配置项/光盘),我们可以快速测试和发布大量代码,同时将出错的可能性降至最低。 通过配置项,我们的团队定期将代码更改集成到同一个中央存储库中。 之后,我们将自动构建并测试其操作,以确保问题能够尽早被发现。 有了光盘,我们的团队可以一天提交多次变更,并在没有任何人工干预的情况下将结果投入生产。 起初,我们发现消除人工干预只会导致相当糟糕的部署结果。 然而,我们在编写正确的测试和故障排除解决方案上投入了大量时间,最终发现新系统极大地提高了我们的速度和灵活性,并显著提高了代码质量。 操作模式:尽可能采用无服务器操作模式:尽可能采用无服务器模式现代应用包含大量运动部件。 今天的现代应用程序通常由成千上万个服务组成,这在过去远远超出了单个应用程序和数据库的范围,在每个服务后面都有一个专门的数据库和一个负责不断发布新功能的团队。 这些移动部件可分为以下两类:作为企业的“独特技能”,它们负责确保业务的成功,例如能够创造独特用户体验和开发创新产品的部件。 我们通常称之为“不加区分的承载”活动组件,这些活动必须完成,但它们本身不能提供任何竞争优势。 对于大多数企业来说,这些任务包括服务器管理、负载平衡和安全补丁应用程序等 我们在2014年提出了“无服务器”的概念,同时发布了AWSLambda AWSLambda是一种计算服务,可以帮助人们在不配置或管理服务器的情况下运行代码。 这种能力支持我们的总体目标,即通过向AWS分配非歧视性任务,帮助客户专注于优化他们的“独特技能”。 事实上,所有这些已经成为现代应用程序开发中的一个关键因素。 无服务器模式释放了每个人的精力,并在真正让你的业务与众不同的领域投入了更多的时间——比如产品创新。 当我们谈到“无服务器”时,我们指的是运行时不会分散对基础架构配置或扩展的注意力,具有内置可用性和安全性保证,并按使用情况计费的服务。 无服务器不仅仅是λ,它是一个完整的应用程序堆栈 应用程序堆栈通常由以下三个元素组成:计算服务(如AWSFargate),数据存储方案(如运行应用程序逻辑的MySQL和PostgreSQL关系数据库),以及集成层(如AmazonAurora),它们与事件总线AmazonEventBridge相似,用于实现数据移动。这些无服务器建筑单元使企业能够创建充分发挥无服务器模式优势的应用程序。 在亚马逊,我们自己还没有完全实现无服务器,但是我们正在朝着这个方向努力。 事实上,我们相信很快会出现整整一代只负责编写业务逻辑而从未接触过服务器的开发人员。 原因很简单。无论您是构建新应用程序还是迁移旧版本的应用程序,使用无服务器原语进行计算、数据处理和集成,您都可以确保每个人都能从云环境提供的敏捷性优势中获得最佳收益。 安全性:每个人都对安全性负责:每个人都对过去负责,许多企业将安全性视为一种神奇的“调味品”——在应用程序准备好发布后抛出一些应用程序。 然而,这种方法在连续发布周期中显然是不可接受的,因此组织必须采用新的安全方法来围绕整个应用程序构建防火墙。 然而,这也带来了新的挑战:在过去,我们只需要为集成应用程序建立一个安全设置;然而,面对微服务架构中成千上万个独立的进程,以前的安全思想根本无法解决问题。 有鉴于此,在现代应用程序中,我们将安全功能构建到应用程序的每个组件中,并随每个版本自动测试和部署。 这意味着安全不再是安全团队本身的责任——相反,安全被深深地融入到开发生命周期的每个阶段,在这个阶段,工程、运营和合规团队将发挥他们的作用。 安全性将被集成到代码库、构建管理器甚至部署工具中 这适用于分发管道本身和通过管道分发的软件。 此外,当使用无服务器服务时,维护安全状态的难度较小,因为底层基础架构的安全操作包括系统版本更新、软件修复和监控等。,以内置形式存在于各种服务中。 现代化之旅现代化之旅那么,有多少客户实施这些变革来推动应用程序现代化?必须承认,没有统一的路径,但是有许多常见的模式,包括我们在亚马逊采用的方法。 当我们决定专注于创新并大幅扩展Amazon.com时,我们重组了集成应用程序,重组了组织结构,然后使用自动化和抽象来促进云资源的优化 Yelp和其他客户采用了类似的现代改造方法。 对于从内部托管应用程序开始的客户,最常见的方法自然是重新托管,即“将应用程序直接迁移到云” 此后,许多客户开始进一步探索云环境中的托管服务,并尝试将数据库和应用编程接口管理等任务迁移到AWS,从而确保他们关注业务逻辑。 如今,越来越多的客户走上了重塑之路,将新的应用程序构建成无服务器的微服务,以充分发挥云服务的优势。 没有统一正确的现代化方法,因为在AWS平台上,各种应用程序可以在不同的状态下共存,并通过任何路径成功交互。 但是我们也看到了其中的一个重要共同点,即构建现代应用程序的客户可以检查他们的整体业务优势,尤其是时间和资源的最佳分配。 他们花更多时间定义业务逻辑、扩展系统以轻松满足高峰客户需求、提高敏捷性,以及更快、更频繁地向市场发布新功能。 以向汽车购买者提供最新汽车信息的Edmunds.com网站为例。他们将新功能的启动时间从六个月缩短到一周。 初创公司Bynder也将产品发布周期从一年缩短至一个月。 通过改变技术的使用方式,企业可以显著改善其业务交付途径和相关经验。 这是现代应用的力量。

发表评论