Flávio Henrique Schuindt da Silva <flavio.schuindt at gmail.com...>
I'm a beginner in using CF and I successfully deployed cf-mysql-release 
and now I can write, read, etc from the database as a service bound in my
Now, I have some questions and it would be really great if someone could
a) Ok, I have a database that works and its great. Imagine a scenario that
a lot of clients are acessing my app and now I have to scale. How CF scale
the service? I mean there must be some way to give more nodes on the maria
db cluster provided by , right?
b) If I need to save profile pictures to a user table. What should I do?
Save it as blob in the database since write data to disk is not recommended
by cf docs because apps are isolated each other in the DEA.
Thank you very much for your patient and time.
 - https://github.com/cloudfoundry/cf-mysql-release
I can't speak to a), but the general pattern for b) would be to store the
actual blob data into an object store of some sort (whether public like AWS
S3 or Azure, etc, or on a private service like Scality, EMC ECS, or
Cleversafe), and then simply store the URL / ID for that photo into the
On Tue, Jun 2, 2015 at 2:12 PM, Flávio Henrique Schuindt da Silva <
Alberto A. Flores
My 2 cents:
Your database, while it's deployed in CF, it's based on MySQL. Depending on
the configuration (YML file) you used for that release, scaling that
database is strictly based on whatever MySQL can provide. It's not CF, but
it's BOSH and the Software (in this case MySQL) that enables the "scaling"
of the software. All CF provides is the ability to connect apps to this db
service using the "service broker" model. In other words, CF does not scale
your service, but the BOSH release (e.g. cf-mysql-release) may be
configured to scale using features available in both BOSH and the software
With regards to where to save "profile pictures", I've learned that the
right answer is always driven by the "access pattern" of the data. The S3
solution may work, but if you only archiving you can certainly wonder if
it's cost effective to do it that way. The docs you suggest refers to
writing data to disk as an anti-pattern. In general, CF allows to implement
patterns described in the "12 Factor App" http://12factor.net/
With regards to scaling, there are others factors you can consider. Perhaps
putting an "in-memory" store as a service to your app that can hold certain
type of data. I think there's more than one way to skin the cat.
On Tue, Jun 2, 2015 at 5:12 PM, Flávio Henrique Schuindt da Silva <
Regarding a) you could try having your services managed by Apache Brooklyn
<http://brooklyn.incubator.apache.org/> it can auto- or manually-scale. I
wrote a Service Broker
<https://github.com/cloudfoundry-community/brooklyn-service-broker> and a CLI
plugin <https://github.com/cloudfoundry-community/brooklyn-plugin> that
let's you talk to Brooklyn in a CF native way.
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.