云计算集成问题日益突出 如何解决

    任何事物的发展最终都倾向于融合。云计算也不例外，融合是一个非常泛化的词汇，但是诠释了其中复杂的关系网。之所以众多厂商追捧混合云解决方案也是这个原因。不管对于云厂商而言，还是云服务用户而言，集成问题会越来越复杂，而且直接导致的结果就是用户会觉得云变得越来越难做，而且其成本远超过自己的预期。

    当然也并不是没有办法解决云集成的问题。用户需要时刻谨记在心的在于要让自己的云服务提供商以免费的形式提供集成的服务，或者是作为一种附加的服务提供。但这并不是一蹴而就的事情，企业本身也要单独的同第三方的提供商或者就自己单独的来解决一些集成问题。

    自定制集成代码

    现在有相当多数量的saas集成还停留在点到点的集成，通过自定制编写代码实现。有调查显示，接近40%的saas和云厂商在企业内部开发一种点到点的自定制集成，从而为客户实现同其他应用和系统的连接。如果企业自身有这种能力，也可以自己动手丰衣足食。但基本上，集成的实现都是通过调用saas厂商的 api，随后厂商将会将数据作为一种消息传送回来。

    我们可以通过访问saas厂商的api调用我们的数据，但这种调用通常都基于一些协议，比如http、rest、soap和json。不过由于在不同平台使用的语言的差异也存在一些问题，比如force.com就支持java、。 net、php、objective c、ruby等等语言。

    不过现在最现实的问题在于很多企业并没有自己构建自定制代码的能力，而且这项工作非常耗时。如果任何事情发生一点变化，点到点的集成就被破坏了，而且api也要跟着变化。所以要时刻关注云服务提供商的api升级信息。这里有一点小建议，如果说企业能够自己手动编写多种云集成的api调用，最好考虑在api管理工具上花点钱。另外，不得不说的是其实自定制集成代码的可扩展性并不好。

    开箱即用连接器

    除了自己动手之外，还可以选择所谓的开箱即用的连接器。现在这种连接器很多都提供了非结构化数据的支持，比如视频、图像、音频、xml，甚至是地理数据。而且企业也更倾向于这种方式进行云集成。这个领域的厂商特别多，很难一一罗列出来，基本上包括了大部分的垄断解决方案提供商。很多集成厂商都开始用自己已有的连接器产品给客户实施云集成，而且其形式要比自定制代码更加的灵活易用。不过要提醒的是，大多数厂商都关注在能够在自己的云平台上运行的连接器，现在厂商将这种服务叫做“集成即服务。”

    本地的这种连接器就像是软件一样，可以在企业的服务器上运行。很多传统的中间件厂商现在都支持saas集成，比如informatica、ibm和甲骨文。ibm的_castiron专注在设备层级的方案，打包一系列saas集成连接器到一个设备上，这样就能够优化整个的集成过程。当然这种方法也不是没有问题，因为业务流程的变更依赖于这种集成。虽说随着it发展，这种方式的价格也不那么贵了，但是也不是非常省钱的解决方案。saas厂商可能会在每访问一次服务适时就收费，或者说有数据传输的时候就收费。

    提醒一点，第三方解决方案其实现在也是依赖于连接器，只不过是运行在企业自己的基础架构上而已，集成实际上在云端发生。和本地的连接器一样，这些开箱即用的集成更加的灵活可扩展，而且非常适合在多种云之间进行集成。最省心的在于都是第三方在维护。

    像ibm、informatica、甲骨文和微软这样的产同企业中间件厂商在云集成领域都有所建树，当然还有很多小型的服务提供商。提供集成即服务的厂商都在云端来跑集成，有些公司可能处于政策原因不能频繁访问外网。而且这种服务会随着用例和容量的上升，费用也发生变化。这一点上就要考虑集成多少saas服务，和访问数据的频率问题。而且还得小心自己的厂商会被收购，现在云计算领域发生一起收购案太平常了。

在不久的将来，云计算一定会彻底走入我们的生活，有兴趣入行未来前沿产业的朋友，可以收藏云计算，及时获取人工智能、大数据、云计算和物联网的前沿资讯和基础知识，让我们一起携手，引领人工智能的未来！

标签： 大数据 代码 服务器 云服务 云计算

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