云供应商总想"锁住"你 如何能安全撤离?

从上个月AWS服务器宕机事件中，我们应该可以看出，只有一个云是不够的。所以笔者现在希望讨论一个稍远一点儿的话题，关于如何更好地完成云转型，而避免孤注一掷。

除了防止宕机事件对你造成过大的影响之外，你也应该知道，任何拥有你的数据的供应商，都会想方设法榨取这段合作关系中的最大利益，他们绝对不希望你从他们的云中撤离。“战略撤退”有时候也是一段业务关系中最重要的部分，以下是笔者的一些建议。(已经根据云的类型进行了分类)

适用于IaaS

1、使用Docker或一个类似的解决方案。你应该拥有可浮动的容器，让你能够在突发情况下进行重建和部署。这是一个非常关键的应急办法，让你能够避免被供应商“捆绑”。

2、避免直接进行数据库集成。是的，你的App需要一个存储空间，但是两个App不应该访问同一个操作存储区。这种类型的连接和协议更像是建了一栋纸牌搭的屋子，很不牢靠。在你移动数据库之前，无法移动任何其中的任何东西——当然，如果你按照正常流程处理，不会有什么大问题。与之相反的，你就会在一个非常让人头疼情况中结尾。

适用于IaaS/PaaS

3、实施API/REST集成。Rest架构能让你更容易通过HTTPS进行连接、制定标准和更容易重新定位的网络电话。

4、外部化配置。不要将方案、服务器或域名硬式编码到你的URL中，其他与环境有关的都应被外部化。

5、使用常见的API。如果你正在使用NodeJS、Express或其他类似的著名API，那么你就是安全的，不必担心供应商“捆绑”的问题。而如果你开始使用平台提供的服务，那么你就有大麻烦了。

适用于SaaS

6、确保有一个标准的数据导出步骤。这里的意思是，你能轻松地将数据导入另一个系统。

7、测试数据导出步骤。理论上他们不太有可能会让你抓取数据的转储，笔者曾经见过提供这种功能的供应商，但实际上转储功能并没有按照合理的时间表进行工作，而且那时的数据已经成为了垃圾。

8、倾向于著名的解决方案，稳固Rest API。事实上，你无法一次性完成转储、导入和移动的工作。你可能需要一些定制的中间代码，在你抓取和传输的位置。

适用于关于云的任何方面

9、倾向于开源技术。如果你的核心技术、API和功能是由一个健康的开源项目提供的，那么在你需要脱离供应商时，你就会有很多更好的机会。这里说的是架构的选择，举个例子，你可以考虑用Kafka代替Kinesis。

10、避免依赖于看起来独一无二的云供应商技术。有时候你的架构连结更多的是处理而不是编码，这些倾向于漏入API调用或其他操作管理程序。例如，也许你不使用AWS的Elastic Map Reduce，不过坦白来说它不是最好的财务分析产品，而且多少有点儿古怪。它与你曾使用过的任何云平台都不相同，从这方面来说，你或许不该选择它。

11、使用固定的IP和DNS名称，并绑定到你的公司，而不是供应商。使用一个IP和DNS名称一定程度上是互联网101。虚拟主机失灵重启并产生一个新的IP，这样不是很有弹性，更不用说重定位了。

12、尽可能地使用信息传递。如果你能够在信息基础上做得更多，那么服务的宕机就能在一定程度上接受了。这意味着，当你选择移动云服务时，仍可以在其他的地方继续运行你的业务。

13、选择两个云。正如笔者之前所说，如果你一开始就选择了至少两个云供应商，那么在移出时就会更简单。在SaaS中可能会有点困难，但是在IaaS/PaaS中可操作性很强。

总的来说，你至少应该倾向于开源、开放标准和开放API的特定供应商解决方案。使用微服务架构或至少符合其原则。始终保持你的撤退战略，你就会与你的云供应商拥有一个非常有利于自己的关系。记住，你的云供应商永远会想着如何让你离不开他们。

标签： 供应商 解决方案 数据 

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。