技术是手段，想法是策略。如果没有想法，光知道怎么去完成和实现，那不是Architecture，而只是个Engineer。
所以这篇博，主要想讨论一下，当用户理解了AWS的好处，希望将自己的On-Prem环境迁移到AWS时，我们可以有哪些大策略。
Re-Host
Re-Host就是换个主机。用户的主机或者服务器，对应到AWS就是台EC2。用户主机上的所有东西，都原封不动地迁移到EC2上。就完成了从On-Prem到Cloud的迁移。
我只能说，这样做能享受到AWS的好处是有的，但是是有限的。因为能享受到的只有EC2上的好处，比如snapshot啊，灵活部署啊，auto-scaling啊等等。
而这种用法，第一个好处是简单、复杂度低、人工成本低，第二个好处是快，第三个好处是保留了原本主机上的一些需要license的软件，在新的EC2上仍然可以使用（我的意思是同样的方法还可以使用，有的license是针对CPU的，CPU换了原license就失效了。但是仍可以在EC2上使用新的license，方法还是一样的）。
Re-Platform
Re-Platform就是使用AWS的组件，来对应地替换On-Prem上的组件。比如On-Prem数据库使用的是MySQL，那能不能使用AWS上的RDS来替换。
本地的AD能不能换成AWS的AD？本地的DNS能不能换到AWS的Route53？等等。
这种方法能够更多地享受到AWS的好处，尤其是后期的replica和scaling等。这也是AWS希望看到的。而在我看呢，这也是能够更充分享受AWS价值的方法。
这种方法，需要的大量的数据迁移，或者说数据跨平台迁移。花费的时间和人力物力要远远大于Re-Host的方法。Migration-tool 那些工具就是为了这时候准备的。最后还要有大量的测试保证服务的正确性和完整性。
由于这个过程的时间较长，因此也要考虑在迁移过程中，能够保证持续提供服务的问题。如果保证在Cloud没有准备好前，On-Prem的服务器仍在提供服务，那如何保证在首次迁移后产生的数据持续同步到Cloud，而不是一次性做完了就完了。
还有服务切换时，出现问题如何roll-back。不过这个问题每一种方法都会有，以后再说吧。
Re-Purchase
Re-Purchase我的理解呢，相当于你重新买第三方服务。比如你原来用本地的Confluence来管理文档，现在要挪到Cloud，你不需要自己重新搭建EC2上面跑Confluence，你可以直接去Atlassian买Confluence的云服务。把On-Prem的license升级成Cloud的，就OK。
这个和AWS没什么关系，也挺容易理解的（如果我的理解是对的话），所以我就不多分析了。
Re-Architect
恩…Re-Architect呢，比Re-Platform更…多一点。
如果说Re-Platform是将一个一个服务迁移到AWS对应的新服务上，在这个操作中，你的数据库还是数据库，你的AD还是AD，你的DNS还是DNS。Re-Architect所说的，是动了你产品的架构。
举个例子，原来公司的产品可能是个三层结构，React+Nginx+MySQL。如果我们把这三层照搬到AWS上，React+Nginx放在EC2，MySQL放到RDS，那就是Re-Platform。而如果我们把它改成一个Severless的新架构，那就是Re-Architect了。
可以说，Re-Architect是希望产品能够充分享受到AWS的服务优势，相当于在AWS上重新编写了代码。那么与之相应的人力物力时间成本就不可避免。
付出更多，享受更多吧。
Retire
Retire说的是”舍“，精简，没必要移到AWS的就别移了，你在迁移的过程中很容易发现有些服务你很久没用过了，而且…它宕机了你都不知道。
Retain
Retain说的是”没法动“。有些东西，比如说非常敏感，那不能够放到Cloud中，那么压根儿就别想。
或者说，”先不动“，细水长流，以后再说。
总结一下。
不同的策略有不同的付出和获得。你可以通过Re-Architect的方法充分享受AWS的优点，但是你需要付出大量人力物力来做。所以你的策略很可能是阶段性的，一步一步来实现的。
看我现在公司的产品，其实就是在做Re-Architect。但是不同的公司有不用的情况吧，还是具体情况给具体的策略为好。
