PCF - Managed and User Provided Services

What is a service? Can you name some examples?
Services are cloud native apps dependencies. Consider Service as a factory that delivers service instances.

Two types:

1. Managed services
Cloud Foundry offers a marketplace of services, from which users can provision reserved resources on-demand. Examples of resources services provide include databases on a shared or dedicated server, or accounts on a SaaS application. 

Example: my-sql, rabbitmq, redis etc...

2. User provided services

User provided services provides the metadata to connect to the system outside the cloud. These services are not available in market place. This are custom services i.e. connecting to your own external DB or any other service outside the cloud i.e. erp etc..

Command to list the service instances in your space:

cf services

To see details of particular service

cf service SERVICE_INSTANCE_NAME

What is the “marketplace”? Does it show all services? 

The Pivotal Cloud Foundry (PCF) Marketplace provides users with on-demand provisioning of platform add-on services to enhance, secure, and manage applications. The catalog includes add-on solutions from Pivotal, our Partner, and the Cloud Foundry community providing a curated selection of add-on services from data persistence, caching, messaging to continuous integration, and much more.

To list all the services associated with your org/space.

cf marketplace 

To see details of particular service
cf marketplace [-s SERVICE]

What is the difference between a managed and user-provided service? 

Refer to #What is service.

How would you create a managed service? 

cf create-service SERVICE PLAN SERVICE_INSTANCE

SERVICE: name of the service

PLAN: service plan

SERVICE_INSTANCE: name of the service 

Eg: cf create-service rabbitmq small-plan my-rabbitmq

How would you use a managed service? 

To use a service you bind the service instance created with your application using 

1. 'cf bind-service APP_NAME SERVICE_INSTANCE_NAME'

Note: Use 'cf restart' to reflect yout changes to VCAP_SERVICES environment variables.

2. using application manifests

services:
 - test-mysql-01

One can bind the services to a route using below cli:

'cf bind-route-service SHARED-DOMAIN --hostname APP-NAME SERVICE-INSTANCE_NAME'

Additional configurations for binding:

cf bind-service rails-sample my-db -c '{"role":"read-only"}'

cf bind-service rails-sample my-db -c /tmp/config.json

Unbind a service instance:

cf unbind-service APP_NAME SERVICE_INSTANCE_NAME

Unbind the service instance from route:

'cf unbind-route-service SHARED-DOMAIN --hostname APP-NAME SERVICE-INSTANCE_NAME'

Renaming the service instance:

'cf rename-service OLD_SERVICE_INSTANCE NEW_SERVICE_INSTANCE'

To delete a service instance:

cf delete-service SERVICE_INSTANCE_NAME

How would you create a user-provided service? 

cf create-user-provided-service SERVICE_INSTANCE [-p CREDENTIALS] [-l SYSLOG_DRAIN_URL] [-r ROUTE_SERVICE_URL]

Or

cf cups

User-provided service instances enable developers to configure their applications with these using the familiar Application Binding operation and the same application run-time environment variable used by Cloud Foundry to automatically deliver credentials for marketplace services (VCAP_SERVICES).

cf cups SERVICE_INSTANCE -p '{"username":"admin","password":"pa55woRD"}'

Stream Application Logs to a Service:

cf cups SERVICE_INSTANCE -l syslog://example.log-aggregator.com

Proxy Application Requests to a Route Service:

cf create-user-provided-service my-user-provided-route-service -r https://my-route-service.example.com

How would you use a user-provided service? 

Once user provided service is available. It can be bound to any existing app. Binding the user-provided service to an app will cause CloudFoundry to inject service details into each app instance.

What is VCAPS_SERVICES? Why is it important?

For bindable services, Cloud Foundry adds connection details to the VCAP_SERVICES environment variable when you restart your application, after binding a service instance to your application.

The results are returned as a JSON document that contains an object for each service for which one or more instances are bound to the application. The service object contains a child object for each service instance of that service that is bound to the application.

How do services interact with spaces?
Services are integrated with Cloud Foundry by implementing a documented API for which the cloud controller is the client; we call this the Service Broker API.



Service brokers advertise a catalog of service offerings and service plans, as well as interpreting calls for provision (create), bind, unbind, and deprovision (delete). What a broker does with each call can vary between services; in general, ‘provision’ reserves resources on a service and 'bind’ delivers information to an application necessary for accessing the resource. We call the reserved resource a Service Instance. What a service instance represents can vary by service; it could be a single database on a multi-tenant server, a dedicated cluster, or even just an account on a web application.

Implementation & Deployment

How a service is implemented is up to the service provider/developer. Cloud Foundry only requires that the service provider implement the service broker API. A broker can be implemented as a separate application, or by adding the required http endpoints to an existing service.

Because Cloud Foundry only requires that a service implements the broker API in order to be available to Cloud Foundry end users, many deployment models are possible. The following are examples of valid deployment models.

• Entire service packaged and deployed by BOSH alongside Cloud Foundry
• Broker packaged and deployed by BOSH alongside Cloud Foundry, rest of the service deployed and maintained by other means
• Broker (and optionally service) pushed as an application to Cloud Foundry user space
• Entire service, including broker, deployed and maintained outside of Cloud Foundry by other means