-
Notifications
You must be signed in to change notification settings - Fork 1
CAM Model
The CAM model stands for Cluster, Application, Mixin. We wish to gracefully handle the non-trival task of describing a generic cloud deployment. Other attempts at this have gotten lost in non-human-readable amounts of configuration and are not very approachable. CAM offers a much more lightweight solution without loss of generality.
Each component of the model is the child of the one named before it. Applications are children of Clusters and Microservices are children of Applications. Each level is self describing and observes a scoped configuration. This avoid collisions and unexpected configuration effects.
The Cluster is the platform we're running on. The physical machines as configured on the cloud platform. For now that's CoreOS on EC2, but the CAM model doesn't require it. It could be any Linux cluster.
The Application is the full description of what the user wishes to deploy. It is represented by a repository on the user's local machine and can be deployed to the cluster(s) of the user's choosing. An Application is the sum of its mixins (see below), which are the launch descriptions of a single Application component. While on the user's local machine, the Application is composed of only templates.
On the Cluster, as the Application is launched, the Application is instantiated as a Deployment. Mixin templates are rendered and the Deployment begins its lifecycle as a child of the Cluster.
The Mixin is the smallest unit of the deployment. Mixins are represented by their subdirectory within the Application's launch/ directory. Mixins start out as templates, but are rendered with their configuration when they are deployed as containers on the Cluster. Mixins are children of their Application Deployment in the sense they are all deployed together and share a "global" configuration scoped at the Application-level. We care about their deployment status as a group, however we don't restrict how they are connected. The Kick server allows us to establish an arbitrary network topology among containers, with each Mixin self-describing how it would like to be connected to the container network. At the moment we are using Docker containers, but the CAM model just requires Mixins run in Linux containers, of which there are several competing offerings.