当前位置:云计算行业动态 → 正文

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

责任编辑:editor006 作者:谢涛 |来源:企业网D1Net  2017-04-17 16:13:27 本文摘自:it168网站

从上个月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的特定供应商解决方案。使用微服务架构或至少符合其原则。始终保持你的撤退战略,你就会与你的云供应商拥有一个非常有利于自己的关系。记住,你的云供应商永远会想着如何让你离不开他们。

关键字:供应商Kafka

本文摘自:it168网站

x 云供应商总想"锁住"你 如何能安全撤离? 扫一扫
分享本文到朋友圈
当前位置:云计算行业动态 → 正文

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

责任编辑:editor006 作者:谢涛 |来源:企业网D1Net  2017-04-17 16:13:27 本文摘自:it168网站

从上个月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的特定供应商解决方案。使用微服务架构或至少符合其原则。始终保持你的撤退战略,你就会与你的云供应商拥有一个非常有利于自己的关系。记住,你的云供应商永远会想着如何让你离不开他们。

关键字:供应商Kafka

本文摘自:it168网站

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^