Description

Cloud architecture represents a real infrastructure that is either deployed or to be deployed.

• It is the container and the graphical face of your cloud resources.
• Architectures are located within an environment inside a project.
• In terms of Terraform, it has its own Terraform state file.
• It supports modules and private git repository natively.
• It has its own CI/CD pipelines to allow you to check its security posture, pricing, policies...before introducing any change.

Components

Think of the architecture as a git repository containing all cloud resources of your infrastructure.

1. Architecture information

All high-level information related to the architecture are accessible from the list of projects, environments and architectures.

Here is the explanation of all fields:

a. Name of the architecture.

b. Status of the architecture:

c. Description of the architecture.
d. Tags: list of tags.
e. Created at is a read-only field. The creation time stamp is in UTC.
f. Updated at is a read-only field. The last time this architecture has been updated in UTC format.
g. UUID: architecture unique identifier. This number is useful when you reach out to support.

2. Nodes

The node is a fundamental component of the architecture, it represents (in most cases) a cloud resource of a given cloud provider.

• Every node has an identity card that contains its cloud configuration.
• This identity card represents the Terraform configuration parameters of the node. Eg: azurerm_lb aws_instace google_app_engine_application

You can connect nodes by using the connectors from any selected node.

There are 5 types of nodes:

1. Cloud resource: this resource will be created when you provision the infrastructure.
2. Data source: it refers an existing cloud resource.
3. Module: Terraform module.
4. Container: it can contain other resource and give them its properties. For e.g. AWS VPC, or Azure virtual network.
5. Icon only: this resource is just graphic and has no Terraform representation.

3. Variables

These are Terraform variables and locals that you can define and use both on the design and during deployment.

4. Output

This is Terraform output that you can define and use both on the design and during deployment.

5. Readme file

You can write documentation for your infrastructure in markdown, and Brainboard generates the HTML version of it.

6. Versions

You can track every change you do to the infrastructure by creating as many versions as you want.

Design your cloud architectures here 👉 https://app.brainboard.co