Pivotal Cloud Foundry-托管服务与用户定义服务 [英] Pivotal Cloud Foundry - Managed vs User Defined Service

问题描述

在过去的2-3个月里，我一直在使用Cloud Foundry，并且遇到了用户定义和托管的服务.我的理解是，如果托管服务附带了服务代理(如果需要的话)和用户定义的服务，则定义服务的人必须照顾实现.我想了解使用托管/用户定义的服务相对于定义应用程序内的连接详细信息(或在属性文件中将其外部化)的优点是什么

我相信使用服务绑定方法的总体优势在于，对于要部署到的每种可能的环境，应用程序都不必具有多个配置文件.

具体来说，如果您具有Dev，Test，Stage和Prod环境，则可能会有一组反映每个环境的自定义URL/IP/端口/凭证的配置.您还需要某种方式来触发对正确环境配置的使用.在Spring Boot方法中，通常使用Spring Profiles来定义和激活这些配置.但是，这通常意味着您的应用程序会提前与所有必需的配置文件配置捆绑在一起.

对于Cloud Foundry，连接/服务绑定详细信息是通过已部署的云平台本身注入的.这意味着您只需要定义一个云"配置文件即可在您必须支持的所有环境中使用.

可以认为这种方法有一些好处:

• 您可以建立新的环境，而不必重新构建/重新配置应用程序本身.例如，如果您短期需要Test2，则可以轻松创建和定义新的空间和服务绑定，而无需重建应用程序.从技术上讲，您可以通过其他方式实现此目标，具体方法是通过外部化配置来实现.我对CF的理解是，这实际上不是鼓励的做法(除非您将所有内容都外部化为独立的环境变量，否则可能不容易实现).

• 您不必在应用程序配置中存储凭据.可以说这是安全性的好处，因为应用程序开发人员不必知道与本地环境外部绑定的任何服务的连接详细信息.这对您可能并不重要.

• 您可能能够在整个环境中使用支持服务的不同实现方式(可能是为了避免非产品中的高额许可成本?).我不喜欢这种方法，所以我并不真正认为它有好处.

希望如果我还有其他潜在的好处，那么更多与Cloud Foundry接触的人也可以加入进来.

此外，我将看这个项目: http://cloud.spring.io/进一步了解spring-cloud-connectors/，看看您是否可以通过该方法获得任何其他好处.

I've been using cloud foundry for the past 2-3 months and have come across user defined and managed services. My understanding was that in case of managed services come along with the required implementing if service broker and in case of user defined services , the one who is defining the service has to take care of the implementation. I wanted to understand what is the advantage of using managed / user defined service over defining the connection details within the application ( or externalizing it in property files )

解决方案

I believe the overall advantage of using the service binding approach is that the application does not have to have multiple configuration files for each possible environment it will be deployed to.

Specifically, if you have Dev, Test, Stage and Prod environments, you'll probably have a collection of configurations that reflect the custom URL/IP/Ports/credentials of each environment. You'll also need some way to trigger the use of the correct environment configuration. In the Spring Boot approach, you typically use Spring Profiles to define and activate these configurations. However, this typically implies that your application is bundled with all required profile configuration ahead of time.

With Cloud Foundry, the connection/service binding details are injected from via the deployed cloud platform itself. Which means that you only really need one "cloud" profile defined that will work for all the environments you have to support.

This approach can be argued to have a few benefits:

• You can stand up new environments and not have to rebuild/reconfigure the application itself. For example, if you have a short-term need for a Test2, you can easily create and define a new space and service binding(s) without having to rebuild the app. Technically, you can achieve this other ways -- as you suggest by externalizing the configuration. My understanding of CF is that this isn't really an encouraged practice (and may not be easily achieved unless you externalize everything as independent environment variables).

• You don't have to have credentials stored within the application configuration. This can be argued to be a security benefit in that application developers never have to know connection details to any services they bind to outside their local environments. This may or may not be important to you.

• You might be able to use different implementations of backing services across environments (possibly to avoid high licensing costs in non-prod?). I'm not a fan of this approach, so I don't really see it as a benefit.

Hopefully others with more exposure to Cloud Foundry can chime in if there are other potential benefits that I'm missing.

Also, I would look at this project: http://cloud.spring.io/spring-cloud-connectors/ more closely to see if you can gain any additional benefits with the approach.

这篇关于Pivotal Cloud Foundry-托管服务与用户定义服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！