云资源内部隔离
您需要一个基于公共云的关系数据库来支持新应用程序。 您不直接向特定的云提供商提交请求,而是向内部云代理提交请求。 这是一个系统,可以查看您提交的需求,并以最低的成本和最高的SLA(服务水平协议)选择最佳的关系数据库。
而且,这些代理系统可以在API级别上运行,从而允许应用程序通过简单调用API即可通过代理提供粗粒度或细粒度的资源。 这可以在应用程序内部即时完成。
简而言之,内部经纪人通过多家公共云提供商进行筛选,以最优惠的价格,最好的业绩找到最佳的云服务。 怎么会更好呢?
现实情况是,尽管如果您要迁移到多云模型,则内部逻辑代理是下一个合乎逻辑的步骤,但是最佳实践,工具和IT部门的接受程度总体上还是会受到打击。 我发现了一些原因:
- 直接进入云原生系统并绕过内部代理系统对您施加的一些限制的愿望。 这包括访问使用内部云代理时不可用的子系统。
- 经纪人专注于价格而不是表现。 许多使用内部经纪人的人抱怨说,尽管他们获得了高昂的价格,但他们认为通常不考虑性能和可靠性。
- 许多人声称经纪人不是最新的,并且经常列出旧的或过时的服务。 正如我所描述的,这几乎就像是从在线商店订购商品,几天后又收到一条通知,指出该商品已脱销。
我对此的看法是,云代理本身可能正在按功能运行,但是cloudops无法正确维护它们。 确实,许多活动是由不断前进的临时团队设立的,这些团队抛弃了关键因素,这与管理需要大量维护和更新的经纪人的任务不符。
有几种选择。
首先,要求每个人都通过代理访问云,而不是直接访问本机云。 考虑到有时使用公共云服务的人们有时需要访问本机云接口,我怀疑这种方法行不通。
其次,鼓励仅使用代理来提供长期资源,例如绑定到特定应用程序的存储和数据库。 这意味着应用程序所有者和开发人员可以将本机云用于所有小的内容。
第三,摆脱经纪人。
内部云代理扮演着一个角色,但至少在目前看来,它比生产力引起更大的挫败感。 我怀疑我们将不得不Swift解决一些问题,否则我们将继续前进。
翻译自: https://www.infoworld.com/article/3393975/why-you-likely-dont-need-an-internal-cloud-broker.html
云资源内部隔离