From 969294aad6599dd73667df2e75095cbea0ddaf9d Mon Sep 17 00:00:00 2001 From: joeduffy Date: Thu, 3 Nov 2016 12:13:51 -0700 Subject: [PATCH] Introduce the notion of a Clusters Simple developer scenarios can be done solely in terms of Stacks. However, to support more sophisticated cases -- where multiplexing many Stacks onto a shared set of resources is preferred (for cost savings, provisioning time savings, control, etc) -- we need to introduce the concept of a Cluster. Each Cluster has a fixed combination of IaaS/CaaS provider, decided at provisioning time. --- docs/architecture.md | 6 +++++- docs/metadata.md | 10 ++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/architecture.md b/docs/architecture.md index 94727fe54..f9f1d6fbe 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -11,10 +11,14 @@ The three top-level architectural abstractions in Mu are: * **Stack**: A static blueprint, or "type", that describes a topology of cloud resources. * **Service**: An instantiation of a Stack, grouping zero to many services, each with an optional API, together. -* **Workspace**: A static collection of one or many Stacks managed together in a single source repository. +* **Cluster**: A dynamic collection of zero to many Stacks deployed together into a shared hosting environment. +* **Workspace**: A static collection of zero to many Stacks managed together in a single source repository. In an analogy with object-oriented systems, a Stack is akin to a class and Service is akin to an object. +Although a Cluster and Workspace both can contain many Stacks (dynamically and statically, respectively), there isn't +necessarily a one-to-one mapping between them. Of course, management from the Marapongo console is easier if there is. + Many concepts that are "distinct" in other systems, like the notion of Gateways, Controllers, Functions, Triggers, and so on, are expressed as Stacks and Services in the Mu system. They are essentially "subclasses" -- or specializations -- of this more general concept, unifying the configuration, provisioning, discovery, and overall management of them. diff --git a/docs/metadata.md b/docs/metadata.md index 93a5a1eba..fd08aae08 100644 --- a/docs/metadata.md +++ b/docs/metadata.md @@ -134,6 +134,16 @@ AWS will leverage CloudFormation as the target metadata. In certain cases, we a Refer to [marapongo/mu#2](https://github.com/marapongo/mu/issues/2) for an up-to-date prioritization of platforms. +## Clusters + +A Stack is deployed to a Cluster. Any given Cluster is a fixed combination of IaaS and CaaS provider. Developers may +choose to manage Clusters and multiplex many Stacks onto any given Cluster, or they may choose to simply deploy a +Cluster per Stack. The latter is of course easier, but may potentially incur more waste than the former. Furthermore, +it will likely take more time to provision and modify entire Clusters than just the Stacks running within them. + +Because creating and managing Clusters is a discrete step, the translation process will articulate them independently. +The tools make both the complex and simple workflows possible. + ### IaaS Targets This section describes the translation for various IaaS targets. Recall that deploying to an IaaS *without* any CaaS is