brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Re: Brooklyn: does it fit in?
Date Mon, 08 Dec 2014 11:56:16 GMT
Hi Jeroen,

On 7 December 2014 at 23:38, Jeroen van der Wal <> wrote:
> I hadn't heard of Apache Brooklyn before ApacheCon and out of curiosity I
> attended the presentations: it was love on first sight. But falling in love
> is easy, before getting into a relationship you have to know each other
> better. And there's the family too ;-)

Welcome to our group :) and I'm glad that you found the ApacheCon
presentations valuable - it was a key aim for my talk to introduce
Brooklyn to more people who knew nothing about it, so I am glad that
it has worked on at least one person!

> I'm PMC member of the Apache Isis project, a Java framework for rapid
> Domain Drive application development. A typical Isis application is
> perfectly fit to be provisioned through Brooklyn so in the next months I'm
> going to experiment with that.

We'd love to hear how your experiments go! Of course you can drop in
to here or to our IRC channel at any time to ask questions or explore
how this might work.

> Now the sysadmins of my most friendly
> customer are getting aware that they must start implementing some DevOps
> practices. They're at the stage of looking at Chef or Puppet and have a
> steep learning curve ahead of them so I was playing the idea of introducing
> Brooklyn to them and hit two flies at once (a Dutch expression maybe not
> proper English..). They don't have an urge to go to the cloud but have a
> myriad of internal (Java) applications and also OTS things like OpenLDAP,
> JIRA, Confluence, Nexus, Jenkins, Zabbix, etc.
> My question is: would Brooklyn fit in landscapes similar to my customer or
> should I not bother them and leave them with Chef, Puppet or whatever and

I always explain that Brooklyn has two halves to it (the two pillars
of Brooklyn that I referred to in my talk) - the first half is the
deployment and wiring. This could be seen as being quite similar Chef
or Puppet - and in fact Brooklyn is able to delegate the installation
to Chef, allowing Chef cookbooks to be named in the blueprint and a
runlist given (Puppet is something we'd like to support, too).

The second half - runtime management by policies - is what sets us
apart from the deployment/configuration management tools like Chef and
Puppet. Once the application is deployed, it is monitored
continuously, and the policies can take actions such as
restart/replace failed nodes, and add/remove nodes to match
requirements of demand.

Brooklyn was built from day one to be a "cloud" application, and many
of the policies take full advantage of the ability to start up new
machines and throw them away when no longer needed. We do have the
facility to use a "BYON" location - "bring your own nodes", where you
supply a list of IP addresses and SSH credentials of ready-to-use
machines, and Brooklyn manages it a bit like a cloud provider. It does
have disadvantages compared to a pure-cloud solution though.

If all of these points align with what your customer is thinking, then
Brooklyn could be a very good match. If it doesn't align, then your
customer could proceed with Chef (or Puppet, or an alternative) at
this time, and come back to Brooklyn in the future, and know that
their investment in Chef is re-usable in the Brooklyn world.

Hope this helps - please feel free to ask more questions!


View raw message