* Developers write their code thinking of services, not machines. * De-coupled meaning that w/ config management, you say ”give me a machine, and then configure it this way”, where as with coupling you say ”Give me a service configured this way, and put it on these machines” * Loose coupling with a two way comm channel lets us write formulas without having to assume anything about related services.. we can learn the answers from the other service's configuration. * ./configure && make && make install is more powerful for custom work, but packaging gives you the benefits of repeatability and portability
* Ensemble is mostly about using IaaS * EC2 only right now – This includes Eucalyptus and OpenStack * Deploy fast, add new infrastructure fast, and repeat over and over. * Pay for what you use * Invest in infrastructure only when it makes sense for YOU
* Open source makes it easy to solve your problems without having to appropriate and get locked in to software with a purchase. * Utility computing is similar.. running things on computers doesn't necessarily mean you need to own computers. * Currently marrying the two, opensource and ”the cloud”, is a fairly manual or custom operation.
* Deploys existing open source solutions fast - ”apt-get for the cloud” * Also deploys YOUR app fast. * Makes it easy to define how your application relates to existing opensource services. * Helps you manage those relationships in ”The cloud” * Tightly integrated with Ubuntu – A leader in the cloud space.
Some yaml metadata – lists relationships that it understands and config options A few scripts that run at the right time – configure service based on relationships and config settings Well encapsulated – MySQL formula is generic, and usable by any application that can speak to MySQL
* Wikipedia's architecture has a lot of relationships * Adding 100 of each type isn't hard anymore – thank you config management. * Getting them to work together is still a challenge.
* demo-wiki PHP layer and memcached both scale out with 'add-unit' (can scale back with remove-unit). * Eventually this will be presentable not as commands in serial, but a ”stack” which will be loaded into the environment, and dumpable from a running system
* These commands add a slave instance, and relate it to the master * They also tell the demo-wiki service to use it as a slave * add-unit wiki-slave-db would provide even more read scale out * Write scaling is a bit more tricky * Adding slaves gets us to the subset of the wikipedia graph above.. still lots of relationships to define
Generated by ensemble's ”dot” output format
* There are some options that are unknowable, like the wiki's name * config-changed hook is executed every time a config is actually changed, not every time 'ensemble set' is called.
Ensemble oscon 2011
Ensemble – Welcome to Service Orchestration <ul><li>OSCON 2011
https://code.launchpad.net/principia </li></ul>ensemble : formula name : mediawiki revision : 84 summary : "website engine for collaborative work" description : | MediaWiki is a wiki engine (a program for creating a collaboratively edited website). It is designed to handle heavy websites containing library-like document collections, and supports user uploads of images/sounds, multilingual content, TOC autogeneration, ISBN links, etc. requires : db : interface : mysql slave : interface : mysql cache : interface : memcache provides : website : interface : http
Relationships <ul><li>Various strategies </li><ul><li>- Assumptions in code