You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Richard Downer <ri...@apache.org> on 2014/11/25 10:45:04 UTC

Brooklyn @ ApacheCon Europe

All,

Last week, I presented Apache Brooklyn at ApacheCon Europe. You can
find my slides in any of these locations:

http://events.linuxfoundation.org/sites/events/files/slides/Apache%20Brooklyn%20-%20what%20it%20is.pdf
http://www.slideshare.net/richarddowner/apache-brooklyn-what-it-is-and-why-you-might-use-it

The audience was almost entirely made up of people who had no
experience of Brooklyn. I would estimate about 30 people in the room.
(There were a total of 8 tracks at the conference, and given my
understanding of the number of people at the conference, about 30 is a
fair share of the available audience.)

The talk seemed to go very well, some good questions afterwards and a
few individuals contacted me afterwards with further questions.

Some key concerns that I picked up on as a result of questions and follow-ups:

- Accessibility for non-Java programmers. In response I pointed to the
VanillaSoftwareProcess entity and Chef integration, and use of entity
initializers to perform customisations without requiring Java edits.
We have come a long way from the Java-only view but we need to keep
this up and keep Java as a secondary technique.

- The blueprints looked nice and simple, until the $brooklyn:...
things crept in - they are harder to understand and looked like they
didn't "fit". One quote was "I liked it until all the Java stuff
appeared in the blueprint"

- Sensors. A number of questions about how sensors work, push/pull
etc. Although our current directly-polled sensors work well, I could
sense concerns about scalability. I'd like to see our story develop in
this area about use of agents for metric collection, and sensor data
being pushed to Brooklyn instead of pulled by Brooklyn, and for us to
come up with some load tests which explore how much sensor data we can
collect. For example, one person indicated that their Riemann+Graphite
setup provides 400 data points per machine per second - can Brooklyn
collect this scale of data efficiently?

- Some people were asking about Windows support

- Chef support. In a later discussion with Ignasi Barrera
<na...@apache.org> from the jclouds community, he asked why we weren't
using jclouds-chef. From the sounds of it we could improve our user
experience here a lot (removing the dependency on the "knife"
workstation tools)


All in all, I'd consider this a very successful session. All of the
questions asked were relevant and interesting, and combined with some
followups, suggest that many people got what Brooklyn was about. Since
many came in to the session with little knowledge about Brooklyn, I'm
confident that we've done well to get awareness of Brooklyn raised.


Richard.