什么是开放式服务代理者(Open Service Broker)?
使用Cloud Foundry还是Kubernetes？如果有点纠结，那请先了解开放式服务代理者(Open Service Broker)。前几天Spring Cloud Open Service Broker已经被加入了 http://start.spring.io，这说明它离我们越来越近了。服务代理者是指云平台提供商和Spring cloud应用之间的接口，开放式服务代理者标准是一家开放组织，其中也有一家国内云计算公司参与了，但是好像没见大厂。
本文作者Matt是Cloud Foundry Services API项目的项目负责人，该项目旨在增强开发人员体验配置和管理服务。Matt还是Open Service Broker API的联合主席，这是Pivotal，Google，IBM，Red Hat等公司共同组成一个标准项目，它允许开发人员为运行在多个平台上的应用程序提供服务，这些平台包括Cloud Foundry和Kubernetes。在过去的一年里，Matt在各种会议上提出了服务和服务代理者的演讲，包括CF Summit EU，VMworld和SpringOne Platform，Spring的老板Pivotal公司赞助了这篇文章。
为了提高企业自身的数字财富，他们正在拥抱Cloud Foundry和Kubernetes，这些平台为应用程序和容器提供坚如磐石的抽象底层，最近，第三个抽象也正在成为行业标准：Open Service Broker API（OSBAPI）。
OSBAPI诞生于一个简单的事实：自定义的应用程序需要各种支持服务来做任何有趣的事情。伴随着Spring用户扩大，Cloud Foundry地位上升，PaaS平台社区正在考虑平台提供商和服务提供商应该如何互动。
Cloud Foundry Service Broker API项目于2014年启动，目标是提供各方可以使用的简单而稳定的API合约。几年后，当Kubernetes流行时，K8s社区立即看到了这份合约为整个生态系统提供的价值，从而也采用了相同的模型。为了更好地符合OSBAPI项目将开发人员连接到全球服务生态系统的目标，该项目更名为Open Service Broker API，并获得了新的治理模型，从而更好地反映其意图。
跨项目的共享工具是一个大问题。它使独立软件供应商（ISV）更容易以最小的开销向两个社区提供他们的技术，IT从业者也受益，因为他们只需要掌握一套工作流程和API。
IT行业采用OSBAPI标准为三个关键：
1. OSBAPI是多云multicloud的。
应用程序及其相关服务必须能够轻松跨数据中心移动，包括从内部部署到公共云。OSBAPI规范是一个可靠的抽象，可以处理底层资源。它提供了一致的开发体验 - 这在这个多云世界中是一个非常重要的属性。
2. OSBAPI可以连接任何东西。
无论你选择的平台会运行数百个 - 最终成千上万个 - 应用程序。这意味着需要支持令人难以置信的附加服务。从DB2和Oracle等企业系统到Spring Cloud Services（SCS）等流行的微服务管理工具，OSBAPI规范是提供了一致的接口，允许ISV专注于构建功能强大，可伸缩和安全的服务，并为开发人员提供一致的自助服务体验，以获取其应用程序所需的任何服务。这为ISV提供了一个新的可落地市场，其中包括数千名使用云原生平台的开发人员。
3.OSBAPI可以满足常见的信息安全(InfoSec)要求。
使用OSBAPI规范绑定（和解除绑定）到服务实例时，您的应用程序或容器会收到可用于访问服务的唯一凭据。这意味着你可以随时撤消一个应用程序的访问权限。OSBAPI项目还具有Cloud Foundry和Kubernetes的独特凭证管理挂钩，像CredHub这样的开源项目使平台到服务的集成更加安全。
鉴于所有这些，企业如何将OSBAPI与现代平台结合使用？我们来看看常见用例。
OSBAPI用例和最佳实践
现代应用程序与遗留系统进行交互，许多公司拥有大量遗留系统，这些系统可能在自定义硬件上运行，这就是难题：现代的云原生应用程序和服务需要与存储在老系统中的有价值数据进行交互。然而，授予开发人员访问这些系统的速度通常很慢，需要通过支持tickets进行人工干预。
值得庆幸的是，OSBAPI提供了一个解决方案。当您构建服务代理者来处理现代云平台与旧服务之间的交互时，管理负担就会急剧下降。你的开发团队现在可以更快地进行创新。
这种方法也具有长期效益，一旦中间件到位，这种一致的界面能让其他开发团队开始规划将遗留系统迁移到云，而对现有应用程序或团队的影响微乎其微。
轻松访问公共云服务
超大规模云提供商拥有广泛的API来与他们的服务进行交互，这些公司使用Open Service Broker API在其服务组合和平台之间创建了一个简单的接口。（有关更多信息，请参阅Amazon Web Services，Google Cloud Platform和Microsoft Azure）。因此，无论你在何处托管应用，开发人员都可以轻松利用任何特定公共云服务的强大功能。
企业安全与合规性
当平台和服务代理相互通信时，需要进行基本的访问认证。这适用于许多云平台服务提供商,他们可以使用身份验证的头部里的凭据来了解他们的客户与他们的代理器产品是如何交互的，也可以实施审计和计费工作流程。
最近，Open Service Broker API规范已更新，以允许更安全的身份验证流程，如OAuth，当然，这可能涉及平台和服务代理之间的一些带外通信，但作为交换，它可以提供更高级别的安全性和可审计性。我们已经看到许多“托管”或“托管”服务代理选择此模型，尤其是已提供托管服务套件的基于云的提供商。
如上所述，只要应用程序或容器尝试通过服务绑定访问服务实例，服务代理就应生成唯一的凭据。这提供了两个关键的好处，首先，你获得严格控制的安全/访问模型；其次，这允许立即撤销访问，而无需重新部署任何代码。
这种快速且受控的安全模型对许多行业至关重要，许多服务代理商今天已经提供这种开箱即用的服务。
对于专注于为业务应用团队提供服务的大型企业而言，服务代理模型可以是一项重要资产，该模型能让团队配置指定的代理者提供的服务和计划，从那里，他们可以根据性能、合规性或成本原因定制服务以满足不同应用程序的需求。你的应用程序团队就可以放心地构建，知道他们正在使用安全、合规和可维护的服务。
灵活的部署选项
有许多不同的部署方法可用于构建服务代理，正确的选择取决于你的服务代理会在何处部署以及如何访问它。
许多服务代理者打包成可下载的软件包，其他服务提供商（例如提供托管API或基于云的服务的服务提供商）通常更喜欢选择“托管”或“托管”服务代理模型。在此部署方法中，服务提供商负责部署，维护和升级自己的服务代理。提供商还必须向客户分发访问详细信息。该模型允许服务提供商不断创新其服务并随时更新。（请注意，通常需要互联网连接。）
还有一类服务代理可能希望以某种方式偏离Open Service Broker API规范。例如，Google Cloud Platform Service Broker需要Cloud Foundry并不支持“开箱即用”的特殊OAuth安全流。为了缓解此问题，可以使用专门的服务代理代理（例如Google Cloud Platform Proxy Service Broker）。
OSBAPI：将选择的一致、安全的方式将任何服务连接到云平台，分布式系统经常变化，底层技术也在不断发展，在此背景下，Cloud Foundry和Kubernetes是企业IT的基础技术，现在是时候将OSBAPI视为类似的基础构建块了。