A Quick Tour of a Brooklyn Blueprint
Start by giving it a name, optionally adding a version and other metadata. The format is YAML -- a human-friendly extension to JSON -- following the CAMP standard.
Treat it like source code: use comments, version control it, test it with CI.
Choose your building blocks from a large curated catalog, and compose them together to form new blueprints you can deploy and share.
Customize with config keys, such as the initial size and, for Couchbase, the data buckets required.
Use bash, with variables supplied by Brooklyn; or Chef recipes, with attributes passed from config; or package managers, dockerfiles, etc.
Connect entities with each other using sensors published at runtime to give just-in-time resolution for shell variables, template expansion, REST calls, and any other "happens-before" or "on-change" behaviour.
Give generic VM properties or specific images and flavors. Networking topologies and geographic constraints are also supported.
Create new entities, policies, and "effector" operations using Java or JVM bridges to many languages, workflow systems, or PaaSes.
Add new blueprints to the catalog, dynamically, with versions and libraries handled under the covers automatically with OSGi.
Set up policies which subscribe to real-time metric sensors to scale, throttle, failover, or follow-the-{sun,moon,action,etc}. Cloud should be something that applications consume, not people!
Blueprints are designed for portability. Pick from dozens of clouds in hundreds of datacenters. Or machines with fixed IP addresses, localhost, Docker on Clocker, etc.
And you're not limited to servers: services, PaaS, even networks can be locations.