向AWS迁移系统

向AWS迁移系统的考虑事项:

1.理解现在应用的架构和运行环境:

  使用的OS，软件版本，依赖库，底层硬件，数据库，资源使用用量、性能等非功能要件。

  基于这些信息设计在AWS上的架构，使用Instance的规模和大小，选择DB类型，基于系统特点设计VPC的安全策略等等。

  #硬件资源如何申请，如何设计VPC的网络结构，多备的服务节市点如何选择，由哪个团队下手创建VLAN(VPC)和开通端口等属于组织级别的方针问题，需要相关人员讨论确定。

　#需要有专业团队审核需求和成本是否是最优方案。(AWS的收费规则复杂，如果使用了不合理的方案会浪费很多资金)

2.分析数据。是否有高机密的数据，这些数据可能不适合迁移到云上。(例如，生产环境的用户信息。金融监管机构是否允许放到公有云。

3.规划好数据迁移，备份策略，考虑试运行方针，以及万一情况下的回滚策略。

4.考虑运维，监控的方式，选用哪些工具和服务。

5.考虑是否可以使用AWS的服务，通过AWS服务优化现有系统。 比如，使用Amazon Elastic Cache、ELB等

6.和相关人员讨论之后决定使用哪种系统自动化部署方式。

   可选方式有(各有优缺点)：cloud formation、BeanStalk、DevopsWorks，自己设计部署方案
   #自动化部署的技术选型确定之后，制定精细的规则和具体操体手顺，用于指导各团队作业。

7.AWS Account的IAM(权限管理：infra、架构，开发、运维客自分配到哪些权限）

 

向AWS迁移的几种类型:

1.原封不动的迁移

使用AWS提供的迁移工具(如，AWS VM 导入/导出工具)把原来部署在私有云或者物理机上的系统计移到AWS上，其实就是使用AWS上的VM(EC2)和AWS的数据库。

这种迁移的主要原因可能是原来设备老化或者到期，单纯的使用 AWS的硬件资源。

尽管没有使用AWS的服务，但是利用了AWS的稳定性高，动态扩容等优势。(毕竟AWS多节点，并且是服务器全球部署）

2.迁移伴随优化

不改变系统的业务代码和服务划分，但是会采用AWS的一些服务。比如不再自己配置LB，使用AWS的ELB，使用AWS的MQ，Redis，CioudWatch等。

 

3.系统重构

真上的云原生设计和开发