亚马逊AWS官方博客

应成文规定企业文化和聘用与企业文化相契合的人才的 3 个理由

“公司刚成立时,我们没有太多地讨论企业文化。根本没有任何成文规定。我们只是成立了一家自己感觉工作氛围良好的公司。在那时看来,这很不错了。但当我们开始进行更深层次的思索时,意识到企业文化是必不可少的。我们需要把它写下来,共同讨论。分解,精心讨论细节,再融合在一起。如此反复。一遍又一遍。” — 史蒂夫·乔布斯 大多数高管都认同“人才使组织变得独一无二”这句话。高绩效者的加入可以形成推动力,加快其参与的计划的进展,同时改善他人的成果。相反,如果缺少高绩效者,可能会形成“真空环境”,不能正常完成相关计划,同时降低组织的士气。无论哪种方式,团队增加或减少的每一个人都会影响组织的 DNA 或文化 — 这种影响有时微妙,有时深远。 在过去的几十年里,我有幸在几个具有高绩效文化的公司里工作过。 我花了 11 年时间从适应 — 到拥护 — Bloomberg LP 的企业文化,从工程师、工程经理一步步成长为业务负责人。在随后的 3 年里,我以首席信息官的身份在道琼斯内部推行了企业文化变革。在过去 3 年里,我作为 AWS 全球企业战略主管,四处推广 Amazon 强大的企业文化,帮助世界上一些最大的公司变革其企业文化。 通过这段经历,我发现,具有高绩效企业文化的组织在招聘人才时,对文化契合度的要求不亚于对专业领域和/或专业知识的要求。坚实的专业知识 — 无论是工程、销售、市场营销还是其他领域 — 不应忽视,但并非全部。 在我所经历的每一个高绩效企业文化中,组织对企业文化所扮演的角色都有其目的性,得益于它产生的上升力,有助于员工更快地发挥个人潜力。因此,在说明为什么我认为组织的聘用决策考虑文化契合度会对组织有益之前,您的组织需要明白自己的企业文化是什么,最好把它记录下来。 每一家公司 — 不管其规模、行业、资历如何 — 都有自己的企业文化。 企业文化是公司现状的结果 — 而不是其成因 。 并非每一家公司都会以书面形式记录其企业文化。 如果没有明确成文的企业文化,员工可能会猜测自己该以何种方式工作,这对企业来说是一种风险。因此,就算有很多员工向生产力低下的方向发展或与工作环境格格不入,也不足为奇。 例如,我在彭博工作期间 (2001 年到 2012 年),我们的部分企业文化是有成文规定的,有些更像是“部落文化”。每个部门都有一系列明确的指标 (如所有权、技术能力、沟通度),公司会对员工开展测评以强化某些行为;此外,公司还有一项隐含指标,我们简单地称之为“彭博价值观”(如勇往直前、不屈不挠、完成工作 (GSD)),这是需要随着时间的推移才能慢慢感受和体会到的。事后看,我发现有一些貌似高绩效者 — 特别是具有很多以往经验的人士 — 因为抵触“彭博价值观”而成长较慢 (稍后再详细说明这一点)。 同样,Amazon 也将我们的部分企业文化以 14 条领导准则 (在 Amazon 内部,我们将其简称为 LP) 的形式记录了下来。每条 LP 都在我们的日常工作中发挥着巨大的作用,它们是在 Amazon 做任何工作 (从招聘、绩效管理到业务决策) 的关键因素 (稍后详细说明)。 在一篇相关文章中,我在 AWS 的一位同事 Joe Chung (我很荣幸认识他,我从他身上学到了很多东西) 介绍了制定明确的准则在任何大型云项目期间帮助指导决策的重要性。Joe 的许多观点适用于任何大型变更管理或企业文化原则制定活动。 不管组织有没有明确的“准则”或“价值观”,或者以其他形式描述企业文化,历史经验表明,以成文形式规定企业文化优于什么都不做 (至少对 […]

Read More

将 AWS 认证工程师的数量从零增加到数百个的 12 步计划

“不要总希望得到您还未得到的;这会使您看不到目前拥有的可能性” 作为 AWS 企业战略家,我拥有与全球各地面对着各种业务和技术难题的高管们会面的特权。每个客户都是独一无二的。但是,许多难题,如同历史一样,往往具有规律性。 其中一个规律是,市场中的技能难题以及“不在相应岗位上配备合适的人员就会妨碍您提高行动速度、节省资金和在云上拓展业务”这一想法。可以肯定的是,随着人们认识到让 AWS 完成基础设施领域的无差别的繁重工作的好处,包含单词“AWS”和“云”的招聘广告显著增加了。但是,我认为这种不断增加的需求或者您没能获得所需人才的感觉并不会阻碍您的企业在云方面获得成功。 AWS 企业战略部主管 Stephen Orban 在一篇最新文章中就这一问题有力地指出,“您已经拥有成功实现云迁移所需的人才。”而且,为了加强这一说法的说服力,我想要分享我本人遇到一个主要技能难题时发生的故事。事情要追溯到 2014 年,我的云之旅才刚刚开始。 当时我在英国的 Capital One 担任首席技术官,然后,我发现自己在深入思考我在我的工程师身上发现的技能差距。这些工程师确实很有才华,但他们只是精通传统的内部技术;因此,他们掌握的大部分是孤立的基础设施技能。 为了寻求改变,我随后又犯了一个经常犯的错误:创建一个独角兽式的工作规范并自以为是地将它应用于外部就业市场。当我发现在收件箱中没有收到任何对这则招聘广告的回应时,我感到十分惊讶和失望。 很明显,我漏掉了一个重要的事实。 我拥有的技能高超、积极主动且全心投入的团队就是我需要的团队。只不过,团队成员们需要一个途径、一个动机以及一个善于倾听和帮助他们消除自身与生俱来的对未知技术恐惧的人。 有关人才转型的这种认识和企业云之旅为我积累了大量最佳实践,也让我更深刻地了解人类。但我必须说实话;在这个过程中,我们犯了很多错误并且浪费了很多时间。但是我们还是找到了一条途径,最终发挥了作用并且为 Capital One 在英国的成功做出贡献。这帮助 Capital One 将全球的技术人才提升到了极高的水平。实际上,所有 AWS 认证开发人员中现在足足有 2% 的人在 Capital One 工作。 在说明优势之后,下面将介绍适合我们的 12 个步骤 — 步骤 1 — 接受 心理健康专家们表示,接受是走向恢复的第一步;这种说法在此处也完全适用。您的工程师们必须接受他们有能力学习 AWS 云技能并成为专家的事实。接受这一事实对于您组织内的技术主管来说也同样非常重要。正如 Stephen Orban 在文章中所述以及我在 Capital One 任职期间的经历所表明的那样,您拥有的人才就是您需要的人才。这些是在开发和运行您的现有系统方面拥有多年的重要经验的人员。 步骤 2 — 培训 在接受之后,您应该迅速开始 AWS Technical Essentials […]

Read More

结合深度学习网络 (GAN 和 Siamese) 生成逼真的高品质图像

由于深度学习依靠用于训练它的数据的数量和质量,因此公司花费了大量资金来获得良好的图像数据。通常,公司会使用昂贵的人工注释或其他劳动密集型任务,如拍摄大量产品或人员照片。这种方法的成本高昂且不能扩展。训练计算机以生成高品质图像可大大降低成本并推动业务增长。 在这篇文章中,我用简单的术语解释由我的一些 Amazon 同事共同撰写的标题为“从语义上分解生成式对抗网络的潜在空间”的学术论文中介绍的概念。本文介绍了生成式对抗网络 (GAN)、Siamese 网络 (SN) 的实际应用,以便能够从语义上分解 GAN (SD-GAN)。 GAN 和 SN 是相对高级的深度学习符号,您可以单独使用 GAN 和 SN,也可以将其与其他深度学习符号结合使用来解决实际问题。通过将这些符号结合使用,AI 应用程序能够解决更多的难度更大且更复杂的业务问题。例如,面向 AI 的主要难题之一是缺少带注释或标记的数据。高品质的、带注释的数据的成本非常高,因此仅大型公司或资金充足的公司能够获得此类数据。通过使用深度学习方法 (如本文中介绍的那些方法),可让更多的公司从几个示例生成高品质数据。 我将说明作者如何使用 GAN、SN 和 SD-GAN 分析实际图像,并使用它们生成带同一人员或对象的受控变体的“假”图像。根据您设置的参数或“观察属性”,这些假图像可能看起来像是从不同的视角拍摄的、使用了不同的光照或具有更高的分辨率或其他类似变体。通过使用本文中介绍的图像分析方法,您可以创建出非常真实的图像,这些图像看起来像已使用 Photoshop 专门处理过或是使用 3D 模型创建的。 图 1:使用本文中介绍的方法生成的示例。每行均显示同一面部的变体。每列均使用相同的观察属性。 什么是生成式对抗网络? 生成式对抗网络 (GAN) 是适用于神经网络的相对较新的深度学习架构。它们是由蒙特利尔大学的 Ian Goodfellow 与其同事在 2014 年共同开发的。一个 GAN 训练两个不同的网络,二者彼此针对,因此它们具有对抗性。一个网络通过拍摄一个实际图像并尽可能多地修改该图像来生成图像 (或任何其他示例,如文本或语音)。另一个网络尝试预测图像是“假”还是“真”。第一个网络 (称为“G 网络”) 学会生成 更佳的图像。第二个网络 (称为“D 网络”) 学会辨别 真假图像。其辨别能力随时间的推移不断增强。

Read More

Apple Core ML 和 Keras 支持现适用于 Apache MXNet

我们对于 Apache MXNet 版本 0.11 的可用性感到很兴奋。利用此版本,MXNet 在社区发展以及酝酿 Apache 项目方面都达到了重要里程碑。参与者 – 包括来自 Apple、Samsung 和 Microsoft 的开发人员 – 向此版本提交了代码。到目前为止,该项目已有 400 多名参与者。该项目现已将其代码库完全迁移至 Apache,并且已使其首个正式版本成为孵化项目。我们在上一篇博客中讨论了此版本的一些重要功能。本博客文章将简要回顾这些重点内容。 使用 MXNet 模型将机器学习构建到适用于 iOS、macOS、watchOS 和 tvOS 的应用程序中 利用 Apple 在 WWDC 2017 上发布的 Core ML 版本,开发人员现在可以轻松地将机器学习模型集成到其应用程序中,这使得他们只需编写几行代码即可为用户带来智能的新功能。我们已开始了解这些功能 (如增强实境) 将如何改变我们体验周围环境的方式。随着快速发展的 AI 空间中的功能的扩展,开发人员将有权访问新的机器学习模型,这些模型能够开启用于增强体验的新功能。 Apple 已将代码提交至 Apache MXNet 项目,以方便应用程序开发人员使用一流的模型。MXNet 现在与 Core ML 结合在一起,使开发人员能够利用 MXNet 在云中构建和训练机器学习模型,然后将这些模型导入 Xcode 中,以便您能够在应用程序中轻松构建智能的新功能。您可以从适用于各种应用程序的预训练模型的 MXNet Model Zoo 中选择,也可以构建您自己的模型。此版本为您提供一种用于将 MXNet […]

Read More

在云中自动实现合规性的 3 个好处

“建立声誉需要 20 年的时间,而毁掉声誉只需 5 分钟。” — Warren Buffett 在我的技术生涯中,我一直支持遵从性和安全需求。在某些情况下,这些要求是极其苛刻的 - 例如,当我的团队为国防部审核做准备时,花费了几个月的时间,超出了我们时间的 50%。但是,在几乎所有的情况下,我都能够促进使用自动化的解决方案来使我们的生活更轻松,同时提高我们的安全性和遵从性水平。现今,移至云为您提供了明显改善合规性工作的可能性,而不需要在人力和成本上有同样的显著提升。 我来解释一下 – 合规官通常负责评估和管理企业财务、组织和声誉的风险。在企业环境中,这是一项艰巨的任务,因为人员、流程和技术的复杂性,加上跨行业和地理区域的监管差异。 企业和合规性之间也存在着一种天然的紧张关系。企业必须进行产品创新并改善客户体验。另一方面,合规性团队专注于限制或防止风险暴露,这可能与引入新产品和新特性相冲突。这就是合规性团队经常寻求维持现状的原因。底线是企业和合规性之间的自然紧张关系 - 有时运行状况 - 可能会导致关系紧张并经常导致成本增加,以及减慢上市速度。 通常,合规性团队会进行年度合规性评估、撰写报告和设定补救目标。随后,为业务和技术团队提供对任何发现结果进行补救的时间安排。产品经理和技术领导者了解合规性的重要性,但他们通常将评估视为“练习”并且从价值生成中分散注意力。对他们来说,企业领导者担心年度合规性报告的结果,因为他们认为这些“非功能性”要求会将资源重定向到未来几个季度的战略路线图中未包含的事情上。此外,在开发过程中,合规性常常被作为事后的补充。但遗憾的是,经验告诉我们,如果放任不管,合规性问题最终可能会转化为技术债务。 尽管合规性过程通常被认为是繁重的,但结果可以为客户增加有意义的价值。实际上,根据法律和道德的考虑,合规性应该被看作是一种质量的度量,确保了良好的客户体验,特别是在审查包含了安全性、可靠性和响应性的情况下。您的云策略可在这里扮演重要角色 - 方式是转化企业和合规性利益相关者之间的关系,从而改善企业及其客户的结果。更具体地说,通过在产品或服务生命周期的早期包含合规性要求,您可确保您满足政策和法规目标,同时改善您的价值主张。 方法如下 – 首先,迁移到 AWS 是一种直接的节省。在我自己的云之旅中,我发现 AWS 责任共担模式可让我们获益。以前,我们必须管理物理基础设施才能确保法规遵从性。当我们不得不采购硬件以支持技术计划时,这就造成了额外的延迟。它也总是增加我们的运营负担,因为它通常意味着基础设施团队的工作更多,而不需要额外的人员。通过将我们的工作负载迁移到云,我们将维护一个安全的、合规的物理基础设施的责任转移给了 AWS,从而带来了我们永远无法提供的资源和专业知识。换句话说,我们能够提升我们的能力,同时减少我们必须自己保护的表面积。这为我们的运营团队腾出了时间来专注于其他的增值工作,例如,创建其他自动化。 AWS 责任共担模型 其次,将工作负载转移到云可鼓励更大的自动化。可以基于标准化的和经过批准的模板部署环境,然后可以进行版本控制。此概念称为“基础设施即代码”,安全性和合规性的好处是深远的。在将基础设施作为代码进行管理时,可使用脚本自动验证基础设施来确保遵循安全最佳实践。AWS 还支持在 AWS Config 中定义可自动验证的合规性规则。因此,在使用自动化时,合规性团队可在每次系统更改时验证法律和安全需求,而不是依赖于定期的系统审查。此外,合规性和安全性测试自动化可推入软件开发过程中,并有可能在部署到生产环境之前防止策略违规。最后,可以在每日的报告中捕捉到这些发现,并发送到一个将问题分配给某个特定个体的票证系统,甚至可以触发一个自动修复响应。例如,Capital One 已开发出名为云 Custodian 的规则引擎,此引擎用于在其云平台中定义策略并以编程方式强制实施策略。 第三,当自动化过程或手动审查发现问题时,可更轻松地部署补救措施。例如,在基础设施存在漏洞的情况下,基础设施模板可在代码中进行修改并将自动应用于所有未来的实现。如果应用程序中存在此问题,则可通过将修复部署到应用程序,或通过实现补偿控件 (例如,将规则添加到 AWS Web 应用程序防火墙) 来缓解风险。 随着时间的推移,您的云策略可形成一种积极的合规性文化,将合规性和安全性作为增值的以客户为中心的活动。当您的产品团队在产品待办事项列表中将合规性要求作为用户案例包含时,或当开发人员定期向其软件开发过程添加与合规性相关的测试时,您将实现此里程碑。 如果您已在 AWS 中实现合规性过程的自动化,或者您想要了解有关此主题的更多信息,请告诉我。与此同时,这里还有一些其他的资源可能会有所帮助 – 自动在 AWS 上执行管理 如何监控 AWS 账户配置更改和对 Amazon EC2 安全组的 API 调用 AWS 上的 DevSecOps […]

Read More

使用AWS Lambda和AWS Step Functions轻松构建Serverless应用

作者: Vivian Zhang(张芸) Serverless(无服务器)应用可以说是当前的行业热点,用户无需预配置或管理服务器,只需要部署功能代码,AWS Lambda会在需要的时候执行代码并自动缩放, 从每天几个请求到每秒数千个请求,轻松地实现FaaS (Function as a Service)。无服务器应用的使用场景非常广阔,从微服务架构,到批处理、流处理、运维自动化和移动计算。 实现Serverless应用,除了AWS Lambda还需要什么? 我们来看一个典型的基于Lambda的无服务器应用。 当我们将作为计算和存储实体的Lambda函数、消息队列、DB去掉,可以看到下面这张图。 这张图上的箭头,就是上一张图里Lambda函数之间的流程,或者可以称为Lambda函数之间的“胶水”,它们起到了编排协调各个Lambda函数的作用。通常在应用中,我们会需要有这样的一些流程: 我想要顺序地执行方法。 我想要并行地运行这些方法。 我想要基于数据选择执行方法。 我想要重试某些方法。 我想要try/catch/finally。 我想要代码运行一定时间或者等待一段时间…… 通常我们可以通过方法调用、函数链、DB和消息队列来协调这些函数,实现流程。但是对于所采用的协调机制,我们都希望它具有以下功能: 可以自动伸缩; 不会丢失状态; 可以处理错误和超时; 可以简单的搭建和运维; 可以审计。 这里我们介绍一种方式,采用AWS Step Functions协调Lambda函数之间的流程。 AWS Step Functions AWS Step Functions是一个可视工作流服务,可用来轻松协调分布式应用程序和微服务的各个组件。用户从单个组件构建应用程序,每个组件都执行一个特定的功能,也就是Task(可以采用Lambda函数实现)。Step Functions提供了一种可靠的方法来协调这些组件并逐步完成应用程序中的这些功能,并且 提供了一个图形控制台,将应用程序的组件可视化为一系列步骤,它可以自动触发并跟踪每一个步骤,并在出现错误时重试,这样应用程序就可以每一次都按照预先设定的顺序执行。Step Functions会记录每一步的状态,因此当事情出错时,用户可以快速地诊断和调试问题。 要使用Step Functions构建应用,首先我们需要在Step Functions里创建State Machine(状态机),也就是对应每一个应用的工作流程。可以采用以下8种蓝图,包括7种预定义好的状态机和1种自定义的。创建好的状态机用JSON描述。 在每一个状态机里,我们需要定义一系列的State(状态),用来完成不同的功能: Task:在状态机中完成特定的功能,可以采用Lambda函数实现。 Choice:在各种执行分支中进行选择。 Fail和Success:停止一个执行,并设为Fail或者Success。 Pass:简单地将输入传给输出,或者注入一些数据。 Wait:提供一定时间的延迟,或者等待到特定的时间/数据。 Parallel:并行地执行分支。 可以看出,上一节中我们所需要的协调和流程在这些状态中都得到了支持。其中的Task状态是用来真正实现应用的功能,而其他状态用来处理功能之间的流程。比如说,下面是一个名为HelloWorld,执行Lambda函数的状态。 下图是一个拥有所有状态的状态机: 在Console里看到一个创建好的状态机是这样: 我们点击New Execution并且传入input数据,就可以启动该状态机的一次执行,并且可以从界面上查看执行的情况。 […]

Read More

新增 – 适用于 Windows 的 Amazon EC2 Elastic GPU

作者:Randall | 原文链接 今天,我们高兴地宣布,适用于 Windows 的 Amazon EC2 Elastic GPU 正式推出。Elastic GPU 是一种 GPU 资源,可以挂载到 Amazon Elastic Compute Cloud (EC2) 实例来提升应用程序的图形性能。Elastic GPU 提供 medium (1GB)、large (2GB)、xlarge (4GB) 和 2xlarge (8GB) 几种大小,可以作为 G3 或 G2 等 GPU 实例类型 (用于 OpenGL 3.3 应用程序) 的成本更低的替代方案。您可以将 Elastic GPU 用于多种实例类型,灵活地为应用程序选择适当的计算、内存和存储资源,使之达到平衡。您现在就可以在 us-east-1 和 us-east-2 区域预配置 Elastic GPU。 对于 eg1.medium,Elastic GPU 的起始价仅为每小时 […]

Read More

Amazon Aurora 数据库快速克隆

作者:Jeff Barr | 原文链接 今天,我想快速展示一下 Amazon Aurora 中我认为非常有用的一项功能:数据库快速克隆。利用 Aurora 的底层分布式存储引擎,您可以快速、经济地创建数据库的写入时复制克隆。 在我的职业生涯中,我经常需要花时间等待一些有代表性的数据样本,以便用于开发、试验或分析。如果我有一个 2TB 的数据库,则在执行任务之前,等待数据副本准备就绪的时间可能长达几个小时。即使在 RDS MySQL 内,我也仍需花几个小时等待快照副本完成,然后才能测试架构迁移或执行某些分析任务。Aurora 以一种非常有趣的方式解决了这个问题。 借助 Aurora 的分布式存储引擎,我们可以完成一些使用传统数据库引擎通常不可行或成本高昂的操作。通过创建指向各个数据页面的指针,存储引擎可实现数据库快速克隆。然后,当您更改源或克隆中的数据时,写入时复制协议会为该页面创建一个新副本并相应地更新指针。这意味着,以前花 1 小时才能完成的 2TB 快照恢复任务现在只需大约 5 分钟即可完成 – 其中大部分时间用于预配置新 RDS 实例。 创建克隆所花的时间与数据库大小无关,因为我们指向同一存储。这样还可让克隆操作变得非常经济实惠,因为我只需为更改的页面 (而非整个副本) 支付存储费用。数据库克隆仍是一个常规的 Aurora 数据库集群,具有所有相同的持久性保证。 接下来,我们克隆一个数据库。首先,选择一个 Aurora (MySQL) 实例,并从“Instance Actions”中选择“create-clone”。 接下来,将克隆命名为 dolly-the-sheep 并对其进行预配置。 大约 5 分 30 秒后,我的克隆已变为可用状态,然后,我开始进行一些大型架构更改,但发现性能未受到任何影响。由于 Aurora 团队做出了一些改进以支持更快的 DDL 操作,因此,与传统 MySQL 相比,架构更改本身的完成速度更快。如果我想让其他团队成员对架构更改执行一些测试,则随后可以创建克隆的克隆,甚至是三次克隆,依次类推,同时我还能继续更改自己的克隆。这里需要注意的是,从 RDS […]

Read More

新增 – 通过 IP 地址在 AWS 和本地资源间实现应用程序负载均衡

作者:Jeff Barr / 原文链接 去年,我介绍了有关新型 AWS 应用程序负载均衡器的信息,并展示了如何针对 EC2 实例以及在容器中运行的微服务,用它进行第 7 层 (应用程序) 路由。 在向 AWS 迁移的这个漫长过程中,有些客户会构建混合应用程序。这些客户告诉我们,他们希望使用单个应用程序负载均衡器,在现有本地资源以及 AWS 云中运行的新资源组合中分配流量。其他客户则希望将流量分配到分散在两个或多个 Virtual Private Cloud (VPC) 中的 Web 或数据库服务器中,在同一实例上托管 IP 地址不同但端口号相同的多项服务,并为不支持服务器名称指示 (SNI) 的客户端提供基于 IP 的虚拟托管支持。还有一些客户则希望在同一实例上 (或许是在容器内) 托管某项服务的多个实例,同时使用多个界面和安全组来实施精细访问控制。 这些情况会出现在各种混合、迁移、灾难恢复和本地使用情形及场景中。 路由到 IP 地址 应用程序负载均衡器现在可以将流量直接路由到 IP 地址,以满足这些使用情形。这些地址可以与 ALB 位于同一 VPC 中、位于同一区域中的对等 VPC 中、位于与 VPC 连接的 EC2 实例上 (通过 ClassicLink),或者位于 VPN 连接或 AWS […]

Read More

使用云伙伴系统,让您的迁移之旅不再孤单

Edmunds.com 全面迁移到 AWS 的相关经验 伙伴系统这个概念已经使用了数十年,应用范围涵盖生活的许多方面,包括学习、工作和探险。无论涉及哪一方面 (比如大学新生与其学长配对、空军飞行员与其僚机驾驶员或者您的周末潜水伙伴),大多数伙伴系统不外乎两个目的。一个是安全性,通常出现在需要双方相互照顾的体育或危险活动中。另一个是新入学的学生或新来的员工与经验更丰富的伙伴配对以便获得培训和指导,以免出现常见的新手错误,从而自信满满地快速进步。 就我个人来讲,如果 2012 年在我开始全面向云迁移时拥有云伙伴,一定能帮我解决不少难题并省去实验的麻烦。当时,我是北美地区最大的汽车购物网站之一 Edmunds.com 的首席信息官。 但与现在不同的是,当时很难从正在成功迁移的其他公司找到大量伙伴系统资源。如果具备大规模全面的参考案例 (除 Netflix 之外)、托管迁移计划或成熟的咨询合作伙伴生态系统,则迁移工作会容易得多。幸运的是,现在有大量专注于云迁移的人员、流程和技术,这意味着,组织再也不用像我们当时迁移 Edmunds.com 那样孤军奋战了;而且,加快云使用率和更大限度节省成本的相关专业技术水准也在不断提升,这使全面迁移战略变得比以往更加可行。 作为一名终身冲浪爱好者,我可以告诉您,如果有伙伴系统的帮助,即使在危险条件下,冲浪也不是什么了不起的事情。单打独斗被认为是终极精神追求。而如今,如果我要去世界上的陌生地方冲浪,则更愿意采用更加实用的方法。在登上冲浪板之前,我会试着找一位曾经去过那里的“伙伴”,从他那里了解所需的所有海浪相关信息。例如,珊瑚礁有多浅?有鲨鱼出没吗?哪种潮汐状况最适合冲浪?听取了这些方面的建议并学习了别人的经验后,我心中的疑虑通常会打消不少,而且冲浪体验也会得到提升。 最近,我加入了一个前任首席信息官 (他们构成 AWS 企业战略团队) 团体。我们的目标是帮助技术高管思考和拟定其云优先策略,为此我们所采取的一种方法是:制定和简化新型迁移加速计划,以利用我们所积累的知识 (经验是没有压缩算法的)。作为前任首席信息官和 AWS 客户,我们曾经负责过自己的云迁移工作,并在此过程中帮助过各种类型和规模的企业完成了转型,我们的经历就像我到一个新地方冲浪时从伙伴那里获得提示和建议一样。 回想一下,我从 Edmunds.com 迁移经历中得到了三点重要启示;正如您将看到的,即使我们在 2016 年初关闭了最后一个 Edmunds.com 数据中心,我们经历的过程也仍然与大部分企业迁移当前所经历的云采用阶段非常接近 — 我们将完全停止运营这个高性能数据中心 实际上,这不是当时的确切想法。作为当时的首席信息官,我的主要目标是交付技术能力,以超前满足业务需求。在进行云迁移前的 7 年里,我们不知疲倦地工作,开发出了一种被认为极其高效的基础设施运营和 DevOps 实践。但是,这种效率需要企业付出代价,尽管它提供了每日自动发布能力和前所未有的可靠性。这种代价就是,公司需要将越来越多的有限资源分配给支持代码 (私有云和 DevOps 工具集),从而导致没有足够的资源用于面向客户的应用程序代码 (新的客户功能和服务)。我们需要一种新的模式来控制支持代码与客户代码的比率,而不用牺牲任何功能。 2011/2012 年出现的新兴云趋势为企业提供了一种备选方案,它强调与单个公司孤军奋战相比,公有云 (尤其是 AWS 的规模) 能提供更好的基础设施和更优质的服务,而且价格更具竞争力。然而事实却不容乐观,围绕它的新闻层出不穷,报道内容无外乎:与成熟的本地安装相比,云更加昂贵且不太稳定。Netflix 早期曾采用 AWS,当时的情况有力地证明了这一论点:较成熟的大型企业可以在云中运行关键操作;但当时,我们无法为 Edmunds.com 业务找出更类似的参考实施。 同行参考在当时对我们来说极其重要,因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。 […]

Read More