Brokers support multiple services and multiple plans of each service. If
you have multiple services, you may want to use one broker for all of them,
or a broker for each. Depending on your service, it may make sense to have
everything run on the broker or use nodes. However, this doesn't make sense
for persistent storage services; what do you do when the service running on
the broker runs out of capacity, create another broker offering a second
service? Not a good solution. Better for the broker to handle orchestration
for an expandable pool of nodes. This also allows you to horizontally scale
the broker as traffic requires.
Take the v1 MySQL service as an example. The broker offers a single
service, supporting multiple plans. In the past these plans have included a
database on a shared server, a database on dedicated server running in a
warden container on a multi-tenant vm, and a database on a dedicated server
running in a warden container on a dedicated vm. Each of these plans can be
backed by multiple nodes. The combination of resources reserved by the plan
and the resources allocated to your node equal the instance capacity of the
node. Multiply this by the number of nodes and you have the instance
capacity of the plan. The broker asks the nodes about their instance
capacity and using a simple placement algorithm decide which node to put
the next instance on.
The v1 services were written with stateless brokers, and as we're writing
the v2 services API and new MySQL service, we think we're going to keep
that model. But depending on your service, you could decide a stateful
broker makes sense. Processes on each MySQL node are responsible for
keeping track of which instances the node is responsible for (the sqlite db
you've seen), and for monitoring the health of those instances. But these
are implementation details and may not make sense for every service.
A service being built by another Pivotal team will do something very
similar with a multi-tenant, clustered service. In their case, a "service
node" equates to a cluster of many vms with different roles. Having the
broker as an independent component gives them the flexibility to have
multiple clusters, all supporting the same or multiple services plans;
dedicated clusters or clusters offering more/less features.
On Wednesday, August 21, 2013 10:48:03 AM UTC-7, Dr Nic Williams wrote:
Shannon/DaveS/NickK et al, what is the history of the gateway/broker and
service node separation? Why is there a node, with its own sqlite DB (I
think) on each VM running the actual service; rather than the gateway doing
We haven't done anything with the "node" part of services. We haven't had
a need to since we're integrating with existing services Oracle, LDAP, etc.
so we don't need to have a node to run our services. If you're integrating
with Elastic Search, I don't see why you need a node for that either. You
could have your service gateway/broker so all the work setting up the
Elastic Search service with Amazon. Does that make sense? Am I missing
On Wed, Aug 21, 2013 at 12:49 AM, Francois Hensley <
I have been looking through the repo athttps://github.com/cloudfoundry-community/cf-services-contrib/tree/master/elasticsearchwhat
would be the a similar implementation to the eleasticsearch_node in
java? I get that the gateway service contains the provisioner. I'm just
unclear about the node.
On Thursday, August 15, 2013 2:04:37 AM UTC+10, Mike Heath wrote:
I haven't put up an example yet. It's definitely something I'm planning
on getting out this week. I'm pretty swamped this week so it might not
happen until the weekend. If you don't see anything by next week, please
feel free to bug me about it. :)
Thanks for your interest!
On Tue, Aug 13, 2013 at 8:58 PM, wrote:
I've checked out your source code, have you had any chance to create a
simple echo service example using your code?
On Friday, December 28, 2012 4:51:11 AM UTC+11, Mike Heath wrote:
I'm not much of a rubyist either so I started working on a framework
for building vcap components on the JVM. It's definitely in the very early
stages so don't get too excited. (I'm also the author of one of the Java
NATS clients already mentioned.)
I'm just getting into providing support for services. It's not
something I work on full-time so progress is slow but I hope to have
something that works by the end of January.
On Tuesday, December 25, 2012 9:42:30 PM UTC-7, man...@gmail.comwrote:
Its been a steep learning curve for those who don't know ruby since
Cloud Foundry being written in ruby, some times it becomes difficult for
people who're new to ruby. I know ruby is a excellent language and provides
lot of features from other languages but is there a way I can write a
service in java and make it work in cloud foundry
To unsubscribe from this group and stop receiving emails from it, send
Dr Nic Williams
Stark & Wayne LLC - consultancy for Cloud Foundry usershttp://drnicwilliams.comhttp://starkandwayne.com
cell +1 (415) 860-2185
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.