智狼动态

客户:simajie

行业:未知

项目内容:

服务内容分类

推荐资讯

上海营销策划公司带你走
营销策划公司分享,营销
上海营销策划公司带您走
上海销售技巧培训课程教
上海智狼营销带您走进乐
享受无限人生,营销策划
销售技巧培训分享:准客
营销策划公司分享:强生
上海智狼营销每日分享:
营销策划公司每日分享|缺
上海营销策划公司分享帕
销售人员管理培训:管理
冬季护肤新体验,营销策
几分钱的饮料也能引爆全
销售人员培训班分析失败
上海营销策划公司带您走
销售技巧培训课程:销售
上海智狼营销每日分享:
销售技巧培训助你做高效
想要精品阅读,上海营销

营销策划咨询公司讲述亚马逊快速创新的秘密之一



日期:2019-09-09 14:58
  创新一直是亚马逊DNA的一部分。大约20年前,为了使我们的创新迭代过程 - “发明,释放,重新发明,重新释放,重新开始,冲洗,重复,一次又一次” - 更快,我们经历了一场彻底的革命。这种变化不仅影响了我们开发产品的方式,也影响了我们组织公司的方式。
 
  二十年前,Amazon.com仅为我们今天服务的用户提供了一小部分服务。但那时,我们知道如果我们想扩展Amazon.com提供的产品和服务,我们就必须改变整个网站的应用程序架构。
 
  当时,Amazon.com网站由一个大型的单一“在线书店”程序和相应的大型单一数据库驱动。这种情况限制了我们的速度和灵活性。因为主程序最初是为我们的第一个产品 - 在线书店开发的,每当我们想要添加新功能或为客户提供新产品时,例如视频流,必须重写整个程序的代码。重写整个程序代码的过程漫长而繁琐,需要复杂的业务和部门人员协调流程,这些流程会影响我们快速创新和扩展的能力。
 
  因此,我们将“分布式计算宣言”作为公司寻求变革的蓝图。在本内部文档中,我们描述了新的系统应用程序体系结构。然后,在此声明之后,我们开始重构整个系统应用程序并将其拆分为称为“服务”的模块,以促进亚马逊规模的扩展。
 
  改变整个系统的应用程序架构,只是亚马逊变化的一半(另一半是公司组织的调整)。早在1998年,所有亚马逊开发人员都在维护相同的程序,这意味着每个新版本都需要协调所有开发团队。
 
  为了支持新的应用程序架构,我们打破了功能层次结构,并将团队重组为小型自治团队。每组都足够小,只能喂两个比萨饼。我们让每个小组专注于特定的产品,服务或功能集,使他们能够更多地访问整个应用程序的特定模块。通过这样做,我们的产品开发人员成为产品的所有者,他们可以更快地做出影响他们自己产品的决策。
 
  打破我们的组织结构和应用程序架构是一个大胆的想法,但幸运的是,这个想法终于成功了。因此,我们可以更快地为客户带来创新:随着亚马逊的发展,我们每年都会部署数十种新功能,而今天我们每年可以部署数百万种新功能。更为显着的是,我们在创建高度可扩展的基础架构方面的成功不仅成为亚马逊的新核心竞争力,而且为我们在2006年推出AWS云服务奠定了基础。
 
  到现在为止,我们仍然坚持将团队分成“两个比萨饼可以喂养”的团队来工作。
 
  在追求快速创新的道路上,我们并不孤单。为了保持竞争力,许多公司希望提高灵活性,以继续发现新的机会并开发更好的产品。许多公司开始与亚马逊一样的旅程,转向现代应用程序开发模型。这种新的开发模型要求将传统应用程序的单一体系结构转移到更小的组件集体系结构或微服务体系结构。对于现代应用程序的最佳实践,变更不仅涉及改变设计和应用技术的方式,还涉及重新思考人员的管理方式。
 
  任何希望在新的程序开发模式中取得成功并提高公司敏捷性和创新速度的公司都应该使用以下五种基本技术:微服务,专用数据库,自动化软件发布管道,无服务器操作模式,自动化和整个安全。
 
  架构模式:微服务
 
  与亚马逊一样,大多数公司最初都是单片应用程序,因为它们是最快,最容易开发的。但是,这种将所有进程绑定在一起作为整体服务提供的方式存在一个问题:如果其中一个模块遇到峰值需求,那么为了应对该模块的高负载,整个架构需要扩展计算能力。
 
  此外,随着代码库的增长,程序特征的添加和改进变得更加复杂。因此,实验和实施新想法更加困难。这个单一程序的体系结构也增加了整个系统的可用性风险,因为所有进程都是相互依赖和紧密耦合的,如果其中一个进程失败,它会影响整个系统。
 
  这就是为什么随着公司的发展,每个人都会开始考虑“微服务”架构。公司采用微服务架构后,软件系统由独立组件组成,每个进程作为服务存在。每项服务代表一种业务能力,例如购物车。由于每个服务独立运行并由单独的开发团队管理,因此开发团队可以独立地升级,部署和扩展服务,以满足特定服务模块的整个系统的需求。在购物车的情况下,当举行促销时,可以单独扩展购物车以满足大量用户的临时需求。
 
  许多开发人员发现,随着公司的程序架构从大型单程序模式转变为微服务模式,他们希望通过管道管理每个服务之间的依赖关系。因此,开发人员必须采用新的解决方案来打包程序并运行代码。使用新的解决方案,过去创建虚拟机实例的方式不再是唯一的选择。
 
  开发人员可以使用软件容器或AWS“Lambda函数”。软件容器是最流行的代码打包选项,也是传统应用程序现代化的重要工具,因为软件容器提供了出色的可移植性和配置灵活性。使用AWS Lambda,操作更加简单,开发人员只需编写业务逻辑代码。
 
  最后,如何在微服务之间进行“通信”是另一个需要考虑的问题。许多应用程序继续使用API??进行连接,但有许多方法可以在微服务之间传递数据。例如,实时数据处理所需的流模式。例如,在数据更改后触发响应的事件模式。另一个例子是App Mesh服务网格,它控制应用程序之间的通信以实现可观察性。开发人员可以根据业务需求选择最合适的集成方法。
 
  数据管理:专用数据库
 
  现代应用程序基于“计算和存储解耦架构”。在解耦之后,专用数据库与微服务一对一映射,而不是大型单个数据库。计算和存储解耦是传统程序架构的一个非常重要的变化。因为就像传统的大型单一程序一样,由于业务扩展会遇到容量扩展和容错的挑战,数据库也是这样的:单个数据库意味着所有错误都丢失了,而且很难建立单个数据库满足许多不同类型的微服务的具体需求。通过存储计算解耦,开发人员可以根据需要选择最合适的数据库。
 
  对于大多数程序,最佳选择可能仍然是关系数据库,但有许多程序具有不同的数据要求。例如,如果您需要处理高度相关的数据集,例如在开发推荐引擎时,您可以选择图形数据库(如Amazon Neptune)来存储和查找数据之间的连接。
 
  或者,如果您的程序需要实时访问数据,您可以选择内存数据库,例如Amazon ElastiCache,它通常用于游戏和物联网(物联网)。通常,完全满足微服务需求的数据库是最好的数据库。
 
  软件分发:自动软件发布管道
 
  我们删除了Amazon.com网站使用的单程序架构,并将员工重组为“两个比萨饼”组。与此同时,我们不再使用单一的软件发布管道,而是开始允许组独立发布自己的服务。
 
  在允许团队独立发布服务之后,我们消除了在开发和发布软件升级时遇到的人力和业务协调挑战。然而,这种开发和发布过程的分散化也带来了一系列新的挑战:所有团队都难以确保发布流程和质量的稳定性。特别是,如果发布过程的每个步骤都是手动的,则会增加人为错误的可能性。
 
  我们的解决方案是双管齐下的:标准化和自动化。首先,我们将软件交付流程定义为最佳实践模板,该模板提供了在云环境中建模和配置基础架构资源的标准。该模板利用“基础架构作为代码”服务,这意味着模板通过代码为程序提供整个技术堆栈,无需手动流程,因此团队成员可以更快地开始。在亚马逊,最佳实践模板可确保团队根据需要配置和部署自己的业务流程。
 
  其次,我们取消了软件交付过程中的手动步骤,并用自动化方法替换它们。通过自动软件发布管道,我们实施了持续集成(CI)和持续部署(CD),不仅可以快速发布测试版本,还可以最大限度地减少出错的可能性。通过持续集成(CI),我们的团队可以随时将代码合并到一个中央代码库中,然后执行自动创建和测试以及早发现问题。通过持续部署(CD),我们的团队可以每天多次提交代码更改,无需任何人为干预,并可自动在线部署。
 
  最初,我们认为缺乏人员参与的产品部署可能会出现问题。但是,在我们花了大量时间测试和部署故障安全解决方案之后,我们终于发现自动发布不仅大大提高了我们的速度和灵活性,而且还提高了代码的质量。
 
  操作模式:使用尽可能多的“无服务器”架构(无服务器)
 
  现代应用程序有许多移动部件,不仅包括单个程序和数据库,还包含数千个服务,每个服务都有一个专用数据库,以及一个不断发布新功能的配套团队。
 
  这些运动部件可分为两类:
 
  一个是公司的核心竞争力(秘密sause),这就是公司在市场上取得成功的原因,例如创造独特的用户体验或开发创新产品。
 
  我们通常称之为不加区分的一种常规,必须完成这些任务,但它们不会带来竞争优势。对于大多数公司而言,这些任务包括服务器管理,负载平衡和系统安全补丁。
 
  2014年,我们通过发布AWS Lambda引入了无服务器的概念。 AWS Lambda是一种计算服务,可让您无需事先准备或管理服务器即可运行代码。这样做符合我们的最终目标:帮助我们的客户围绕他们的核心竞争力优化他们的资源,并将他们的日常事务交给AWS。这一概念已成为现代应用发展的关键原则。如果您的公司切换到无服务器模型,您可以专注于使您的公司更加出色的事情,例如产品创新。
 
  当我们说“没有服务器”时,我们指的是一种不需要关注基础设施的使用和扩展的服务模型。该服务具有内置的可用性和安全性。此模式仅使用“按次付费”(按值付费)定价模型。最终的“无服务器”架构不仅计算出这部分是无服务器的,而且整个应用程序的技术堆栈都是无服务器的。
 
  应用程序的技术堆栈通常由三个不同的组件组成:
 
  计算服务(如AWS Fargate)用于运行程序逻辑。
 
  用于存储数据的数据库,例如MySQL和PostgreSQL关系数据库,或Amazon Aurora
 
  集成层负责在两者之间传输数据,例如Amazon EventBridge
 
  您可以在所有三个组件上使用“无服务器”架构,以便开发的程序可以最大限度地发挥无服务器架构的优势。
 
  在亚马逊,我们目前在所有组件中都没有“无服务器”架构。但是,我们正朝着这个方向努力。亚马逊的许多客户公司也是如此。实际上,我们预测很快就会有一代开发人员:他们从未接触过服务器,只是编写业务逻辑代码。原因很简单。无论您是在开发新程序还是移植旧程序,您都可以从一开始就在计算,数据存储和集成层中使用无服务器模式,从而最大限度地提高灵活性。这是本机云计算的优势。
 
  安全:每个人的责任
 
  在过去,许多公司将安全视为一种神奇的尘埃 - 等到产品发布后再将其洒在产品上。但在持续释放的循环中,这种情况不起作用。因此,许多公司已经部署了新的安全策略来为整个程序创建防火墙。但是,还存在一个挑战:如果整个程序的每个模块使用相同级别的安全设置,那么当其中一个模块需要不同级别的安全性时就会出现问题。
 
  因此,在现代应用程序中,每个模块都内置了安全功能。并且可以使用每个服务版本自动测试和部署这些安全功能。这意味着安全性不再是安全团队的唯一责任,而是深深融入产品开发周期的每个阶段。需要参与工程,运营和合规团队。
 
  就像代码库,构建管理和部署工具一样,安全性也集成到工具中。安全工具适用于软件发布管道和通过管道发布的软件。使用“无服务器”服务,安全状态更易于维护,因为底层基础架构安全操作(例如操作系统版本更新,软件修补和监视)已内置到每个服务中。
 
  转型之旅
 
  我们的客户公司如何转型以及如何开始部署现代应用程序?虽然没有单一的成功路径,因为每家公司都不同,我们仍然会看到几种常见的转型模式,包括我们在亚马逊的转型模式。
 
  在亚马逊,当我们决定专注于创新和扩大Amazon.com时,我们重构了单片系统程序架构,重新组织了公司的组织结构,然后通过自动化和抽象优化了云计划架构。 。我们的一些企业客户,如Yelp,采用了类似的转型路径。
 
  一些客户公司之前已部署了内部部署服务器,因此他们选择重新托管并“将整个程序”提升并转移到云端。迁移到云之后,许多客户公司可以将数据库和API管理等内容交给AWS云服务,从而使他们能够专注于公司的核心业务逻辑。
 
  如今,越来越多的客户公司正在走向“再生”,他们使用无服务器的微服务架构来开发新程序,使公司能够利用云。
 
  虽然在AWS平台上,每个公司都可以找到最适合其状态的实现,但不同体系结构的应用程序可以共存并通过多个路径进行交互。但我们经常看到,在客户公司部署了一个现代应用程序之后,它很快就发现了新架构对整个企业的好处,特别是在如何分配时间和资源方面。他们可以将更多时间花在业务逻辑的定义上,可以轻松扩展以满足用户的高峰需求,并且可以提高敏捷性,以更快,更频繁地向市场发布新功能。
 
  例如,Edmunds.com为汽车购买者提供最新的车辆信息,他们网站推出新功能的时间从过去六个月减少到一周。同样,创业公司Bynder的新产品进入市场所需的时间也从一年减少到一个月。这些公司通过改变他们使用技术的方式来提高他们的业务能力。
 
  这是现代应用的力量。
 
关闭
17317364699