Hi David and Aled, Thank you for your replies, all very helpful. For now I'll leave the team with their config management solution and separately start a Brooklyn setup.
Cheers, Jeroen On Mon, Dec 8, 2014 at 5:12 PM, Aled Sage <[email protected]> wrote: > Hi Jeroen, > > For the "deployment and wiring" pillar, I'd add that another > differentiator is making it simpler to wire inter-component dependencies. > Simple examples include the database URL injected into the app-servers by > whatever mechanism the app-server expects; another example is injecting the > addresses of "seed nodes" of a cassandra cluster into all the nodes, and > continuing to maintain that list of seed nodes even as nodes are > added/removed from the cluster. As the inter-component dependencies get > more complex, it gets increasingly hard to configure that kind of thing in > Puppet, Chef, Salt, etc. It is a design philosophy of Brooklyn to allow > flexibility when injecting dependencies, to do it in the way that the > components expect (as opposed to enforcing an opinion on how dependencies > should be injected). > > We'd be very happy to discuss further what a Brooklyn solution would look > like for your use-case. If you want to have a call (as well as e-mail / > IRC) then please do let us know. > > Aled > > > > On 08/12/2014 11:56, Richard Downer wrote: > >> Hi Jeroen, >> >> On 7 December 2014 at 23:38, Jeroen van der Wal <[email protected]> >> 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! >> >> Richard. >> > >
