首页 >> 科技 >> 亚马逊CTO的“中台论”

亚马逊CTO的“中台论”

发布时间: 2019-11-07 16:30:39来源:互联网 

来源|人工智能前端(id:人工智能前端)

作者| |沃纳·沃格尔

翻译器|核焦炭

编辑|陈思

正文如下:

创新一直是亚马逊基因的重要组成部分,但大约20年前,我们迎来了一场彻底的变革。当时,我们的目标是进一步提高我们迭代过程的速度——发明、开始、再发明、再开始、消除旧的东西和重复。我们所做的改变对我们构建应用程序甚至组织企业结构的具体方式有着深远的影响。

那时,亚马逊为的客户比现在少得多。然而,我们非常清楚,如果我们想要扩展我们提供的产品和服务,我们必须首先改变我们的应用程序架构。

尽管庞大的集成“书店”应用程序和臃肿的数据库为Amazon.com提供了充足的动力,但它们也极大地限制了我们的速度和灵活性。每当我们计划为客户提供新的功能或产品,例如视频流,我们必须在专门为书店设计的应用程序中编辑甚至重写大量代码。这是一个漫长而复杂的过程,需要复杂的协调努力,极大地限制了我们快速推动大规模创新的能力。

为了从根本上解决这个问题,我们通过《分布式计算宣言》建立了一个新的变革蓝图。这是描述新架构的内部文档。通过这一声明,我们开始通过许多称为“服务”的小型基本单元来重组我们自己的应用程序,从而大大提高了我们扩展亚马逊整体业务的能力。

然而,改变应用程序架构只是故事的前半部分。至于后一半...那是1998年,亚马逊内部的所有开发团队都在使用相同的应用程序,因此每个员工都必须为他们当前的版本跨团队进行协调。

为了支持这种新的架构,我们已经打破了功能层次,并将组织重组为小的自治团队——每个订单只有两个比萨饼。我们将这些“双披萨团队”分配给不同的特定产品、服务或功能集,赋予他们对应用程序中特定部分的更多操作权限。这使我们的开发人员能够成为产品所有者,并能够根据他们自己的决定快速影响单个产品。

打破我们的组织和应用程序结构无疑是一个大胆的想法,但也是一个好的和有效的想法。我们能够更快地向客户交付创新成果,随着亚马逊的快速发展,我们已经从每年部署数十项功能发展到今天部署数百万项功能。更让人意想不到的是,我们在构建这一高度可扩展的基础设施方面的成功最终为另一个主要核心竞争力的发展和增长做出了贡献,aws诞生于2006年。

然而,我们仍然坚持双比萨团队的基本组织。

当然,我们绝不是唯一一家强调创新的公司。为了保持竞争力,亚马逊必须不断提高其敏捷性,以便不断发现新机会,创造更好的产品。也正因为如此,越来越多的客户踏上了与亚马逊相同的旅程,转向现代应用开发。这种新方法需要从整体架构转移到更小的基本单元或“微服务”,此外,现代应用程序的最佳实践需要在改变设计和构建技术的同时重新思考它们的管理方式。

为了成功提高应用程序开发的敏捷性和创新速度,组织必须按照自己的顺序采用以下五个要素:微服务、专用数据库、自动软件发布管道、无服务器运行模式和连续自动化安全。

像亚马逊这样的大多数企业最初都是以集成应用程序为基础的,因为它们是开发速度最快、难度最小的系统。然而,这种将所有过程紧密结合并作为一个整体的方法通常会带来一系列严重的问题。如果应用程序中的一个流程遇到峰值需求,我们只能扩展整个架构来实现单个流程的扩展。

此外,随着代码库规模的增长,函数的添加和改进变得非常复杂,这使得企业很难测试和实现新思想。集成架构还增加了应用程序的可用性风险,因为大量相互依赖和紧密耦合的过程会由于失败而增加单个过程的影响。

这就是为什么微服务体系结构随着企业的发展而出现。使用微服务架构,应用程序将由许多独立的组件组成,这些组件将每个应用程序的进程作为单个服务运行。服务将专门为业务功能而构建,如在线购物车,每个服务只负责自己的一项功能。这些流程独立运行,并由相应的开发团队管理,因此我们可以独立更新、部署和扩展每个服务,最终满足应用程序特定功能的要求。例如,当购物高峰时,我们可以简单地扩展购物车服务,以提高承载能力。

随着组织逐渐从集成架构转移到微服务架构,许多开发人员也希望通过流水线操作来管理各种服务中的依赖关系,这需要我们创建新的方法来实现应用程序打包和代码执行。好消息是,凭借强大的创新成果储备,示例不再是我们唯一的计算选择。

您也可以使用容器或awslmbanda函数。容器是当前最流行的代码打包选项,也是更新遗留应用程序的最佳工具之一。容器技术为我们带来了出色的应用程序可移植性和设置灵活性。Lambda使每个人更容易获得他们需要的功能——使用代码编写业务逻辑。

微服务架构的另一个主要要求是我们必须在服务之间建立一种通信模式。目前,大多数应用程序继续使用api连接,但是有些选择在不同的服务之间发送数据。具体来说,它包括用于实时数据处理的流、用于根据数据变化触发响应的事件、以及用于应用层通信和可见性的服务网格等。您可以根据需要选择最适合您的应用程序的集成方法。

现代应用程序采用解耦数据存储机制,其中微服务和数据库被逐个映射,这意味着我们不再需要维护一个庞大的整体数据库。这也是对传统应用程序的重要创新,旨在解决集成应用程序在规模增长时遇到的可扩展性和容错问题。此外,单个数据库也代表单点故障源,很难满足一组不同微服务的特定需求。通过将数据与微服务分开,我们可以自由选择最适合我们需求的不同数据库类型。

对于大多数应用程序,最好的选择仍然是关系数据库;但是也有其他应用程序有不同的数据要求。例如,如果我们运行的应用程序使用高度连接的数据集(如推荐引擎),我们可以选择具有存储和导航关系的图形数据库,如亚马逊海王星。

或者,如果您的应用程序需要实时访问数据,您也可以选择内存中的数据库,如亚马逊弹性缓存(amazon elasticache),它通常用于游戏和物联网应用场景中。一般来说,一个能够完全满足您的微服务需求的数据库是最理想的数据库选择。

当我们告别整体结构,重组为一个双人披萨团队时,自动配送线就出现了。这是为了摆脱原来的单一发布渠道,让每个团队独立地交付自己的开发结果。

尽管这种新方法消除了开发和交付更新等协调挑战,但也给我们带来了许多新挑战。首先,保持发布过程的一致性和所有团队的质量变得非常困难。特别是考虑到发布过程中的每一步都是手动完成的,这无疑会大大增加人为错误的可能性。

我们的解决方案采取双管齐下的方法:标准化加自动化。首先,我们将软件交付过程定义为最佳实践模板,为云环境中所有基础架构资源的建模和配置提供标准。这些“基础架构即代码”模板可以帮助我们的团队从正确的地方开始,并且这些模板通过代码为应用程序提供了整体技术堆栈,而不是依赖手动过程。在亚马逊,这确保了每个团队可以根据我们的需求配置流程和部署。

其次,我们开始使用自动化技术来消除软件交付管道中的手动过程。借助自动发布管道(包括连续集成和连续部署,简称ci/cd),我们可以快速测试和发布大量代码,同时将出错的可能性降至最低。通过ci,我们的团队定期将代码变更集成到同一个中央存储库中。之后,我们将自动构建并测试其操作,以确保问题能够尽早被发现。有了cd,我们的团队可以一天提交许多次变更,并在没有任何人工干预的情况下将结果投入生产。

起初,我们发现消除人工干预只会导致相当糟糕的部署结果。然而,我们在编写正确的测试和故障排除解决方案上投入了大量时间,最终发现新系统极大地提高了我们的速度和灵活性,并显著提高了代码质量。

现代应用包含大量运动部件。今天的现代应用程序通常由数千个服务组成,这在过去远远超出了单个应用程序和数据库的范围,每个服务背后都有一个专门的数据库和一个负责不断发布新功能的团队。

这些运动部件可分为以下两类:

作为企业“独特技能”的活动组成部分,它负责确保业务成功,例如创造独特的用户体验和开发创新产品。

我们通常称之为“不加区别的承重”活动组件,这些活动必须完成,但不能提供任何竞争优势。对于大多数企业来说,这些任务包括服务器管理、负载平衡和安全补丁应用程序。

我们在2014年提出了“无服务器”的概念,同时发布了aws lambda。Aws lambda是一种计算服务,可以帮助人们在不配置或管理服务器的情况下运行代码。这种能力支持我们的总体目标,即通过向aws分配非歧视性任务,帮助客户专注于优化他们的“独特技能”。事实上,所有这些都已成为现代应用程序开发的关键要素。无服务器模式释放了每个人的精力,并在真正让你的业务与众不同的领域投入了更多的时间——比如产品创新。

当我们谈到“无服务器”时,我们指的是运行时不会分散对基础架构配置或扩展的注意力,具有内置可用性和安全性保证,并按使用情况计费的服务。Lambda不是唯一的无服务器的,它是一个完整的应用程序堆栈。

应用程序堆栈通常由以下三个元素组成:

aws fargate等计算服务用于运行应用程序逻辑

mysql和postgresql关系数据库等数据存储方案也可以使用亚马逊极光等。实现数据的持久存储。

像amazon eventbridge这样的数据移动集成层

这些无服务器构建模块使企业能够构建充分发挥无服务器模式优势的应用程序。

在亚马逊,我们自己还没有完全实现无服务器,但是我们正在朝着这个方向努力。事实上,我们相信很快会出现整整一代只负责编写业务逻辑而从未接触过服务器的开发人员。原因很简单。无论您是构建新应用程序还是迁移旧版本的应用程序,使用无服务器原语进行计算、数据处理和集成,您都可以确保每个人都能从云环境提供的敏捷性优势中获得最佳收益。

过去,许多企业认为安全性是一种神奇的“调味品”——在准备发布后抛出一些应用程序。然而,这种方法在持续的发布周期中显然是不服从的,所以组织必须采用新的安全方法并在整个应用程序周围建立防火墙。然而,这也带来了新的挑战:在过去,我们只需要为集成应用程序建立一个安全设置;然而,面对微服务架构中成千上万个独立的进程,以前的安全思想根本无法解决问题。

有鉴于此,在现代应用程序中,我们将安全功能构建到应用程序的每个组件中,并随每个版本自动测试和部署。这意味着安全不再是安全团队本身的责任——相反,安全被深深地融入到开发生命周期的每个阶段,在这个阶段,工程、运营和合规团队将发挥他们的作用。

安全性将被集成到代码库、构建管理器甚至部署工具中。这适用于分发管道本身和通过管道分发的软件。此外,当使用无服务器服务时,维护安全状态的难度较小,因为底层基础架构的安全操作包括系统版本更新、软件修复和监控等。,以内置形式存在于各种服务中。

那么,有多少客户实施这些更改来实现其应用程序的现代化呢?必须承认,没有统一的路径,但是有许多常见的模式,包括我们在亚马逊采用的方法。

当我们决定专注于创新并大幅扩展Amazon.com时,我们重组了集成应用程序,重新安排了组织结构,然后使用自动化和抽象来促进云资源的优化。Yelp和其他客户采用了类似的现代改造方法。

对于从内部托管应用程序开始的客户,最常见的方法自然是重新托管,即“将应用程序直接迁移到云”此后,许多客户开始进一步探索云环境中的托管服务,并试图将数据库和api管理等任务迁移到aws,以确保他们的工作重点是业务逻辑。

如今,越来越多的客户走上了重塑之路,将新应用构建成无服务器的微服务,旨在充分发挥云服务的优势。没有统一和正确的现代化方法,因为在aws平台上,各种应用程序可以在不同的状态下共存,并通过任何路径成功交互。

但是我们也看到了其中的一个重要共同点,即构建现代应用程序的客户可以检查他们的整体业务优势,尤其是时间和资源的最佳分配。他们花更多时间定义业务逻辑、扩展系统以轻松满足高峰客户需求、提高敏捷性,以及更快、更频繁地向市场发布新功能。

以向汽车购买者提供最新汽车信息的edmunds.com网站为例。他们将新功能的启动时间从六个月缩短到一周。bynder的初创公司也将产品发布周期从一年缩短至一个月。通过改变技术的使用方式,企业可以显著改善其业务交付渠道和相关经验。

这是现代应用的力量。

原始链接:

http://www . all things distributed . com/2019/08/modern-applications-at-AWS . html

编辑

快乐十分钟开奖结果 福建快三投注 广西快3 甘肃11选5

相关文章
整站热门


整站最新


栏目最新