forked from mboldt/docs-tiledev
-
Notifications
You must be signed in to change notification settings - Fork 0
/
stages.html.md.erb
78 lines (55 loc) · 3.48 KB
/
stages.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
---
title: Types of Integration
owner: Services
---
## <a id="levels"></a> Integration Levels
A service can integrate with <%= vars.app_runtime_full %> at four levels, shown here in order of increasing
integration. In general, user-experience and production-readiness improves as the
integration level increases. But none of the higher levels is required. You can
stop service integration and declare it complete (enough) after any of these:
When integrating third-party software with Cloud Foundry, the effort
typically progresses through increasing levels of integration. <%= vars.company_name %> recommends
this staged approach because it enables early feedback on the value and the
design of the integration, which helps make better decisions about future
stages.
For non-service integrations (such as applications or buildpacks), a similar
staged integration approach is often possible and desirable.
## <a id="ups"></a> Level 1. User-Provided Service
The service runs external to <%= vars.app_runtime_abbr %> and has no service broker or tile. To use a service
with an app, the developer creates a service broker by running
`cf create-user-provided-service` from the Cloud Foundry Command-Line Interface
(cf CLI).
Configuring, running, upgrading, and paying for a user-provided service are all
up to the developer.
## <a id="broker"></a> Level 2. Brokered Service
A brokered service runs external to <%= vars.app_runtime_abbr %>, but has a tile on [VMware Tanzu Network](http://network.pivotal.io).
VMware Tanzu Network designates brokered services by including "Service Broker for VMware Tanzu" in the name.
Operators install, configure, and upgrade the tile through the Ops Manager
Installation Dashboard. Developers can then see your service plans and create
service instances in Apps Manager, or by running `cf marketplace` and
`cf create-service` from the command-line.
The [Brokered Service](./brokered.html) topic has more information about brokered
service tiles and how to create them.
## <a id="managed"></a> Level 3. Managed Service
With a managed service, both the service broker and the service itself run within
<%= vars.app_runtime_abbr %>. This enables <%= vars.app_runtime_abbr %> to manage, monitor, and increase service performance.
As with the brokered service, the service has a service broker and a tile listed
on VMware Tanzu Network. VMware Tanzu Network lists managed services as "for VMware Tanzu," without
"Service Broker" in the name.
When the operator installs the tile, they allocate a block of VMs to run service
instances and provisions their CPU and memory resources uniformly.
The [Managed Service](./managed.html) topic has more information about managed
service tiles and how to create them.
## <a id="dynamic"></a> Level 4. On-Demand (Dynamic) Service
As with a managed service, an on-demand service and broker both run within <%= vars.app_runtime_abbr %>,
and VMware Tanzu Network lists the service tile without "Service Broker" in the name.
But unlike a managed service, an on-demand service does not limit the number of
service instance VMs.
The operator does not have to pre-allocate and provision VM resources for the
service.
When a developer creates an instance of an on-demand service, they provision its
resources (within an allowed range) and BOSH dynamically creates a new, dedicated
VM for the instance.
The [On-Demand Service](./on-demand.html) topic has more information about
On-Demand service tiles and how to create them.