cloudControl加载项作为单独的服务

Question

我的总部设在欧洲，正在考虑使用cloudControl作为我的云托管平台。在加载项方面，我想使用IronWorker、IronMQ和Cloudant。由于使用计量的不同，我倾向于直接订阅Iron.io和Cloudant，而不是作为加载项，前提是我可以正确地将cloudControl、Iron.io服务和Cloudant连接在一起。

我设想这样做不会有任何管理障碍，也就是说，如果我单独购买而不是作为cloudControl插件(这是正确的吗？)，所有这些平台都将允许将其中一个连接到另一个平台。

不过，对于这些不同的服务作为加载项或单独使用的数据中心，我感到有点困惑。如果我订阅这些分开的服务，我担心会失去数据中心的局部性。特别是：

• 据我所知，cloudControl是在都柏林的AWS托管的。
• Cloudant的欧洲数据中心位于阿姆斯特丹的SoftLayer。cloudControl的Cloudant是托管在那里还是部署在都柏林的AWS，特别是cloudControl？如果我订阅阿姆斯特丹的Cloudant，我会输吗？
• Iron.io的数据中心位置是什么？我知道他们在AWS和Rackspace，但没有进一步的细节，我想象他们在美国。同样，cloudControl的加载项是否托管在都柏林的AWS中，特别是对于cloudControl？我可以订阅Iron.io并要求在都柏林托管我的员工和队列吗？还是“接近”Cloudant的数据中心？

最终，购买这些服务是一个可行的选择吗？

非常感谢！

Answer 1

从我们的角度(cloudControl)的规则是，延迟临界附加必须在欧洲，并优化在相同的欧盟-西部AWS地区，当他们离开贝塔状态。

通常，您可以直接“购买”服务，并与我们的平台结合使用。唯一的区别是，您将得不到统一发票和cloudControl一级支持，大多不能真正回答问题，第三方服务没有通过附加市场购买，因为缺乏信息。

Answer 2

撰写本文时，IronMQ托管在aws和rackspace-dfw上。IronWorker是在aws托管的.

我们有其他地区和云的计划，但不能提供一个明确的时间表。

您可以在我们的开发中心的以下页面找到有关云位置的信息。

• IronMQ：http://dev.iron.io/mq/reference/clouds/
• IronWorker：http://dev.iron.io/worker/reference/api/

您可以直接订阅Iron.io，尽管我们感谢我们所有的平台合作伙伴。如果您有任何问题，请随时通过我们的实时聊天室或我们的支持渠道与我们联系。

Answer 3

我就是行动。有趣的是，来自cloudControl和iron.io的答案让我意识到，我一直在做一个错误的假设，即cloudControl加载项必须在AWS West上“本地”运行。事实上，iron.io和cloudant插件运行在不同的数据中心，这是我没想到的事情。既然这一点已经很清楚了，那么单独购买它们或作为外接程序购买它们并不会改变它们的托管位置，这是非常有意义的(而支持附加功能的理由确实是支持和常见的计费)。

我认为，PaaS总体上应该明确它们的附加组件是否在“本地”运行，因为这是一个重要的选择标准。

就目前而言，IronWorker+Cloudant通过cloudControl可能不是我的应用程序中数据提升工作人员的理想组合(如果他们都在同一个地方，他们会是完美的！)所以我会以不同的方式接待工人。