迁云的那些事

云的时代：
云时代已经到来，在选择云以后，企业首要的问题是选择什么样的方式迁移上云？这会影响企业的迁移周期和迁移后的业务服务品质，因此迁移时必定要按照必定的方法论和流程，而不是盲目的迁移。最基本的也要遵照这五个过程：计划，设计，迁移，运营及优化，在这套方法论里面您能够按您们的实际业务状况进行微调。
全部云厂商里面，AWS拥有最完善的迁移方法论。例如：CAF（采用云框架），LandingZone，Well-architected（良好的架构）和三天迁移培训课程，这些能使您意识到使用云会是一种什么样的模式，解决您在使用过程当中的疑问。我的认为一个AWS初级用户学习CAF的方法论更为关键，这样可让您对云有更深次的使用体验。

借鉴咱们过往的经验，咱们建议客户在AWS上有小量的应用后，再来研读Well-architected，Well-architected中的专业术语较多，建议能够进行初步的了解后，进行简单的应用实践，后期在实践过程当中不断的巩固知识点，以掌握该部分的精髓。固然也有缩短学习时间的方法，那就是选择有经验的AWS Partner作一次详细的讲解以及陪您们一块儿上云实践，他们会根据您企业的业务运行情况告诉您们什么是最佳实践。

实践分享：
根据咱们经历过大量迁移的实践总结，让咱们一块儿分享在迁移过程当中，最为关键的两个阶段，分别是计划和设计。它们是整个迁移中最为基础的部分，就像一栋大楼的地基，如何详细地作好这两个阶段的工做，咱们一块儿来探讨，但愿能对您及您的企业有帮助。

1) 计划：
建议在作计划前，先作一个迁移优先级列表，里面必须包含几个核心的字段，例如：操做系统版本/实际数据量/应用提供商/业务依赖服务/技术复杂度/RTO/RPO等，这些是决定您选择什么样的迁移模式（平滑/替换/重构），什么样的迁移工具，由于它们会影响您迁移周期长短和效果（固然也有一些企业也有一些特别的指标，例如：兼容性（迁到其余云的可能性））。请把这个表填完整后，再作总体的迁移计划，而不是在没有任何依据的状况下作计划。

按以上指标来看，也许大家会感受操做系统版本并不重要，实际上很是重要，首先要清楚AWS支不支持这种AMI，若是AWS不提供，Marketplace和社区有没有？（若是您对安全很注重，建议不要使用社区的AMI）您也能够选择本身制做AMI（选择Vmware方法制做），而咱们的建议是采用AWS提供的AMI，这样无论理是性能，稳定性，功能和故障排查都会较为可靠。举一个咱们实践过的通信行业的案例：客户在上AWS前，有对AMI进行简单的功能测试，并无针对他们在On-premises修改内核的CentOS的AMI进行性能测试。在实际迁移后进行性能测试时就发现各类故障，此时AWS的售后技术也没法解决。根据咱们的经验建议您尽可能采用AWS提供的AMI，若是对AMI确实有很是严格的要求，那么请作好全部必要的测试。应用提供商，这是对应用能不能迁移起到决定性的做用，例如：License，版本以及软件提供商是否还存在？业务依赖服务，这个指标描述的是业务之间的数据交互，业务之间的紧耦合关系，它们之间有多少服务数据存在交互或者它们仅是其余业务的数据提供商，请注意“实际上有时其余业务只是依赖这个业务的数据库的数据，并不依赖于业务自己“，因此业务存不存在并没有关系。RTO/RPO，这个指标会决定迁移成本，要保持业务不中断，迁移成本就越贵。根据咱们实践过的经验，RTO/RPO更合适在容灾和备份场景，在迁移场景咱们更认为业务可中断的时间更为关键，由于这是用来作数据同步和业务切换的时间，最重要的是：“请别认为本身的业务永远不可中断”（这样形成迁移成本浪费，甚至不可迁移）。决定迁移时间的长短还有三个相关的因素分别是：数据同步技术、网络带宽与数据量大小。
把以上指标，还有客户本身要求的指标，作相关评估与验证（下一个阶段的“设计”是此阶段“计划”最重要的验证测试）才能决定业务迁移的优先级、业务迁移的模式、业务迁移的工具、业务迁移的时间。

2) 设计：
拥有以上已完善的迁移优先级列表后，此阶段将进行架构设计与验证测试，以致确保迁移模式，迁移工具与迁移优先选择正确，这也说明设计与计划是承上启下的做用，并非各自独立。经过计划阶段的业务分析与评估，您已经能够进行相应的架构设计，同时进行相关验证测试（在云的时代，这个很是重要），以便调整迁移的优先级与迁移模式。在这此阶段验证的业务越多，迁移阶段的风险就越小，时间就越短。例如咱们的一个高新制造行业客户，他们在上AWS前跟咱们一块儿对现有在某云厂商的业务架构进行详细地评估与分析后，在采用替换迁移的模式下得出他们最关键的验证测试是以EC2为基础的K8S和网络VPC，因此对这两样进行充分测试，例如： K8S的License有效期，K8S的Autoscaling，K8S分红不一样业务组以及K8S的网络测试，还有作一些关键业务迁移测试。因为设计阶段充分测试使得正式迁移时节省两周时间。若是有可能的话，建议采用与生产环境1:1的验证测试环境，在验证完成后，能够把资源Stop，这时只收取部分资源的费用例如：EBS、EIP、S3等。对于那些必须删除的资源，可选择先作备份为正式迁移作准备，还有可使用Cloudformation作好模板，这样能够减小正式迁移的准备工做。

实践总结：
不少企业都喜欢经过少许验证或不验证，就开始执行迁移，在执行过程当中遇到各类各样的问题，有些问题以至他们没法继续，必须从头开始。从咱们过往的经验来说，建议最好先把简单的业务迁移上云，最好都是平滑迁移，最好在前两个阶段作好充分验证测试准备。对一些确实没法中断的业务（实际上DNS域名切换仍是须要中断几分钟的）设计好数据同步的方式（主要仍是数据库数据的同步，能够利用AWS DMS或专门针对数据库实时同步的第三方软件），这里的数据同步会存在必定延迟，要考虑业务可承受的时延范围。必定记住和理解每一个阶段之间是存在严格的关联关系。

迁移，运营，优化这三个阶段也很是关键，而在迁移的前两个阶段作好了充分准备，到迁移阶段会相对轻松，只需注意风险评估和人员工做分配，运营和优化属于高级阶段，对迁移后的业务在稳定性，性能，安全，可用性和成本等方面进行逐步优化。（此文章如有错误，请指正，谢谢！）

参考学习地址：
https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf
https://aws.amazon.com/cn/architecture/well-architected/

【关于博思云为】

做为一家专业的云计算服务型企业，博思云为专为客户提供 AWS 上的运营服务：包括架构咨询服务、迁移服务、云安全集成服务、混合云管理服务、大数据服务以及 DevOps 服务。目前，博思云为在大数据、DevOps、架构、数据库以及操做系统等都已取得厂商认证，在上海、南京、杭州、武汉等地设有分公司。为创新服务模式、引领 IT 服务业的发展，博思云为将持续投入资源开展智能混合云管理平台、图数据库的研发等。