内容简介：云供应商总想"锁住"你 如何能安全撤离?
从上个月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的特定供应商解决方案。使用微服务架构或至少符合其原则。始终保持你的撤退战略，你就会与你的云供应商拥有一个非常有利于自己的关系。记住，你的云供应商永远会想着如何让你离不开他们。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- Confluent 修改许可，限制其他云供应商
- 甲骨文高管：开源供应商“从未真正开放过”
- Confluent 修改开源许可证，限制云供应商滥用
- Confluent 修改开源许可证，限制云供应商滥用
- Hadoop供应商MapR：先上市， “不久之后”就会盈利
- 超大规模云供应商占IaaS服务市场的68%
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
