适用于DevOps就绪企业的云迁移清单
遵循本清单以准备进行云迁移并优化DevOps实践。这些步骤包括有关工具和实践的建议，以支持向IaaS模型或更高级别的AWS产品过渡。
每个应用程序迁移都是不同的，但是每个过程都遵循相同的基本步骤。使用此AWS迁移清单来确保在发布当天及以后都能准备就绪。
亚马逊的许多云服务涵盖各种存储级别和实例大小，托管应用程序环境，无服务器计算等。 AWS迁移需要正确的服务以适应工作负载，并且这些服务应解决应用程序的架构，业务环境，资源需求和安全风险。云的采用和优化也是通过DevOps和敏捷流程进行现代化的好时机。
IT服务提供商Flux7的首席DevOps解决方案架构师Matthias Buchner说，文化是成功的另一个主要组成部分。
Buchner说：“当公司准备迁移时，他们会低估学习曲线。”我们都被告知，云将很容易，但是开发人员，运维，安全和业务主管都需要学习很多东西。
当浏览本AWS迁移清单时，请注意既困难又不适用于给定工作负载的任务。这些步骤基于实际经验，分为五个部分-应用程序评估，托管选择，应用程序部署，IT运营和应用程序支持，最后是项目管理。在移至AWS之前，请打印此清单，并在完成每个迁移步骤时选中相应的框。
1.应用架构准备
一个好的AWS迁移清单从应用程序审查开始。迁移团队必须确定应用程序是否支持云。此外，它必须建立业务约束和成本估算。
列出将该应用程序移至AWS的利弊。业务和技术驱动因素是什么？与参与迁移决策的所有适当领导者联系。
评估应用程序的云就绪状态。它是否设计为可灵活缩放，具有单独的组件，还是整体式的？迁移之前是否需要重构？整个应用程序是否可以在AWS或仅某些组件（例如前端）上运行？
描述哪些应用程序组件需要保留在内部。定义不迁移的技术和/或业务驱动因素。制定计划，以便将来将这些内部组件迁移到公有云。评估云提供商的托管本地基础架构产品AWS Outposts是否适合这些组件。Outposts将于2019年底启动，并为AWS迁移增加了另一层决策。
评估应用程序数据库。数据库会迁移到Amazon Relational Database Service还是Amazon Aurora，还是组织应该将Oracle或Microsoft SQL Server部署移植到EC2？或者，迁移团队将数据库保留在本地还是仅将处理或应用执行移至AWS？
安全数据。计划应用程序将如何通过公共Internet或通过专用光纤将数据安全地输入和输出到这些云端点。确定如何保护静态和动态数据，并与安全团队一起审查此设计。
映射应用程序组件的集成和依赖性。迁移团队必须了解工作流如何遍历各个组件以及潜在的问题所在。 AWS提供了一个应用发现服务来运行本地部署，或者组织可以依靠其数据中心中已经存在的应用依赖关系图和资产跟踪工具。
预估费用。云并不一定便宜，团队必须考虑数据传输，存储，计算使用和扩展的成本。 AWS通过示例应用程序部署为各种服务（例如EC2实例，Elastic Load Balancing等）提供了简单月度计算器。组织还可以使用第三方成本管理工具。
组织可以陷入应用程序迁移的单一路径-例如，重构所有内容以实现最佳的云计算使用。要真正成功，需要将云，敏捷和DevOps相结合，但是任何技术动作都必须根据项目目标进行评估，Buchner说。 如果应用将在两年内终止，请根据需要提起并转移。 但是，如果应用程序是企业的一项投资，则需要花费额外的时间对其进行优化。
2.在AWS上托管
一旦迁移团队了解了其资源和运营需求，便可以确定应如何在云中托管其应用程序。使用AWS迁移清单的此部分评估AWS托管选择。
定义基础架构策略。该应用程序是否需要专用的Amazon VPC，还是应部署到多租户实例？ AWS建议为多个用户设置一个AWS Landing Zone帐户以启用迁移。
设置应用程序实例类型。这些实例必须符合应用程序的资源要求和扩展要求。示例包括低成本的T3可突发VM，通用M5实例以及为计算，存储或其他方式优化的其他EC2实例类型。迁移团队还可以转向更高级别的AWS选择，例如Elastic Beanstalk甚至AWS Lambda，以实现无服务器执行。
内置可伸缩性。管理员可以将应用程序配置为通过AWS Auto Scaling自动扩展，但是他们需要注意任何增加的资源消耗所带来的成本影响。通过手动调整或基于缩放策略实施限制。结合内容交付网络（例如AWS CloudFront）或另一个第三方工具（例如CloudFlare）来规划应用程序扩展。
设置存储以满足各种数据需求和冗余需求。AWS提供了S3对象存储，Elastic Block Store和其他存储服务，包括用于归档的S3 Glacier。实施存储生命周期管理，以在热存储层和冷存储层之间移动数据。要将大量数据迁移到AWS上，请考虑Snowball，Snowball是交付给用户并将应用程序数据携带到AWS的物理设备。
分配托管环境以适合地理限制或要求。例如，为了减少延迟，应用程序应部署在靠近主要 的AWS区域中。或者，为了遵守数据居住法律，应将存储绑定到一个区域。
Buchner警告说，习惯于在本地调整硬件资源大小的组织可能会因实例规划而变得过于精确。 那是一种古老的思维方式。 他说：“在云中，可以在几分钟内更改[资源分配]，因此只需做出最佳猜测，然后运行并从那里进行优化即可。”
3.应用程序部署
当服务器的维护和管理被标准化的云实例所取代时，组织应该转移到自动化操作和基础架构作为代码（IaC）。 精心计划的部署工具包和流程结合了敏捷和DevOps方法，使云迁移值得。
将应用程序和相关组件迁移到AWS上。 亚马逊提供了一系列本地迁移服务，包括AWS数据库迁移服务，AWS服务器迁移服务，CloudEndure迁移和VMware Cloud on AWS。
配置CI/CD流水线。这些流水线部署应用程序并更新到AWS资源。AWS本地提供CodeBuild和CodePipeline，并支持独立的管道，例如由Jenkins连接的集成工具套件。
创建用于应用程序基础结构配置的IaC模板。 将本机CloudFormation与CloudFormer模板一起使用，或将第三方工具（例如HashiCorp的Terraform）使用。 这些使快速部署和标准化成为可能。
如果仍在进行Waterfall开发，请不要让Agile和DevOps实施对云迁移造成障碍。Buchner说，DevOps在本地的采用难度更大，并且其工具与基于云的管道不同。 因此，与其重复学习DevOps，不如从云计算步骤入手，并用它来推动公司内部的敏捷和DevOps增长。
4.运营与支持
成功的云迁移是应用程序生命周期的开始，而不是结束。生命周期的其余部分（监视，事件检测和响应以及资源管理）是团队可以防止性能和安全性问题以及调整DevOps流程的地方。
更新应用程序性能监控。通过云操作监控来完成DevOps反馈循环。为应用程序建立新的基准性能指标，尤其是为云服务重新构造组件时。设置警报的新阈值，并研究第三方监控工具与AWS CloudWatch的对比。
根据共享责任模型监视基础结构资源。物理基础架构的性能和可用性现在是AWS的责任，但是最重要的是您的IT运营团队。他们必须知道应用程序何时遇到问题，实例的配置错误或出现瓶颈以及何时应归咎于AWS的数据中心。在AWS Service Health Dashboard页面上跟踪问题。
制定预防性安全措施。将应用程序移至公共云时，安全范围会更改。有哪些防火墙？虚拟防火墙可以有效控制实例流量吗？花时间阅读有关重大IT安全漏洞以及如何避免相同命运的信息。
启用安全监视和强化。使用渗透测试，漏洞扫描和其他侦探工作。具有多个AWS账户的企业应研究治理选项，例如AWS Control Tower。
设置日志聚合和存档。由于日志信息的来源不同，具有混合云应用程序的组织发现集中式日志管理很困难。他们可能需要单独的工具来汇总来自AWS和本地设置的日志。
记录并实践事件响应程序。云管理与本地任务有很大的不同，在本地任务中，管理员控制服务器，甚至可以对其进行物理故障排除。将按需资源用作登陆位置，以立即回滚任何有问题的更新。
重新访问应用程序备份和灾难恢复过程。可以将灾难恢复站点放在另一个AWS区域或可用区中，或者确保该应用程序可以故障转移到本地服务器。
遏制蔓延。在AWS上进行配置比在本地进行配置更容易，因此在迁移后定期跟踪部署大小和扩展限制。根据需要进行调整以满足需求并保持预算不变。 AWS的自动资源扩展可以掩盖应用程序性能问题，因此请检查账单以防意外使用。
对于大多数将应用程序从本地迁移到AWS的组织而言，安全性是一个问题。 从简单的检查开始，例如使用AWS Trusted Advisor工具，以捕获Buchner所谓的“明显的安全漏洞”。也有完善的商业安全审核工具。下一步是根据AWS架构完善的框架进行大约三个小时的评估，该框架可衡量卓越运营，安全性，可靠性，性能效率和成本优化。 对于高安全性应用程序，组织可以请安全专家来审核应用程序，网络，访问控制和其他攻击面。
5.项目管理与费用
当你项目托管在云上时，AWS迁移清单不会结束。 即使迁移后，项目管理注意事项（例如应用程序评估和团队决策）也很重要。 经常对他们进行重新访问，以确保项目按计划进行，并记住要进行培训，再培训和再培训。
定义长期迁移的目标和范围。一旦迁移了更多应用程序，公司将如何管理AWS账户和支出？每个部门都将管理自己的AWS部署，还是将采用云技术置于集中控制之下？为该项目制定的决策将如何在整个组织中传播？
根据迁移计划建立时间表。考虑假期和相关的业务计划，以创建切合实际的时间表。
评估员工的AWS技能并进行相应的培训。确保技能开发与团队成员的日常任务特别相关。捕获培训课程，以备将来使用和不断改进。
选择正确的工具和服务。工具应符合组织的要求，并且公司需要培训管理员以使用它们。随着新功能的出现和供应商格局的变化，应经常重新评估工具。轮询用户以确保工具能够按预期工作并得到充分利用。
正式进行组织沟通和知识共享。每个人都必须在同一个页面上–应用程序架构师，开发人员，管理员和安全操作专家，以及应用程序所有者和业务领导。在Wiki或其他存储库中集中项目的运行手册文档，IaC模板和其他相关知识。
使用成本估算和模拟来设置迁移后预算。云支出会很快失去控制。确保预算考虑到可变和周期性的需求，并且有一种方法可以在应用偏离规范时敲响警钟。
当企业迁移到云中时，他们必须预测一段时间内的帐户管理。Buchner说，起初很少有人解决此问题，中型企业可以轻松拥有120个AWS账户。更多的帐户意味着更多的密码，更多的开销，更大的预算额度以及潜在的不必要的复杂性。 企业可以与AWS Organizations重新组合帐户，并且可能需要在成功地进行一些早期的成功尝试之后花一些时间在云上。
Buchner建议在以下三种情况下分离账户：如果账户属于不重叠的独立团队或业务部门，则企业必须知道与不同工作负载相关的确切成本，以及当在AWS上运行各种应用程序时出于安全和合规目的。
页:
[1]