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

2020-04-20    来源:多智时代

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

从上个月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
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:浅谈OpenStack平台的安全问题及应对措施

下一篇:会议直播可实现的功能