Proposed here is a modular architecture for the simple-op-stack CLI tool that will do the following:

Gather user intent > Generate chain configuration > Create Infrastructure > Deploy chain

## Glossary
* **chainconf** - master configuration directory describing the desired layer 1 / layer 2 architecture and environment in which it should be deployed. Also includes artifacts such as keystores, contracts, certificates.
* **inventory** - part of the chainconf that lists the infrastructure components in the user's environment, e.g. AWS EC2 instances, or a GKE Kubernetes Cluster. The format of this depends on the deployment plugin being used (could be an ansible inventory, for example).

## Architecture
The simple-op-stack package is a Python CLI tool with the following modules:

1. confgen
* Generates *chainconf* based on user intent
2. provisioner
* Reads *chainconf*.
* Provisions infrastructure in the user's environment using an infrastructure plugin.
* Appends infrastructure *inventory* to the chainconf.
3. deployer
* Reads *chainconf* with *inventory*.
* Deploys to the user's environment using a deployment plugin.

### Architecture Diagram


## Confgen
Configuration generation.

* This module is responsible for generating the chainconf.
* The chainconf includes the configuration for each individual client (op-node, op-geth, etc.).
* (Optional) This module can also generate the *inventory* if the user has already provisioned infrastructure for the deployment.

## Provisioner
Infrastructure provisioning.

* This module is responsible for provisioning infrastructure in the user's environment.
* We do so by making use of an Infrastructure as Code tool (Terraform or Pulumi), but we handle the execution of this tool for the user.
* In a production environment, you would not run all of your clients on the same server, so we can provide a sensible default infrastructure here for each supported environment (see below).
* This is an optional module, in the sense that the user can instead provision infrastructure themselves and just provide us their *inventory*.
* The *inventory* is appended to the *chainconf*, so the master configuration now also includes information about the infrastructure on which the blockchain clients will run.
* The provisioner can also destroy the infrastructure to turn off the chain.

## Deployer
Deployment management.

* This module is responsible for deploying the chain in the user's environment.
* The module does this by invoking a deployment plugin: docker-compose, Ansible, or Helm.
* For any environment other than localhost, an *inventory* is necessary - the inventory lists the infrastructure components in the user's environment.
* For example, when using Ansible to deploy to AWS EC2, the inventory lists the EC2 instances and defines which instance runs which client.
* The deployer can also redeploy the chain from genesis if asked to.

## Supported Environments
* Localhost - user's machine.
* Cloud - AWS, GCP, Azure, Digital Ocean.
* BYOI - bring your own infrastructure. User provides an inventory file for the deployment plugin of their choice.

## MVP Solution
The minimum viable product would be a CLI tool that deploys a default configuration layer 2 and layer 1 on native processes (no docker).

* Only need confgen and deployer modules (provisioner not required).
* Default configuration - no user customisability.
* No inventory required, because everything is done on localhost.