maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Introduce the notion of a Clusters

Browse source 
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.
This commit is contained in:
joeduffy 2016-11-03 12:13:51 -07:00
parent fe2f52c436
commit 969294aad6
2 changed files with 15 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/architecture.md
View file

@ -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.

10
docs/metadata.md
View file

@ -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