Turbot Guardrails Enterprise - Architecture

Turbot Guardrails Architecture

Collectives

A Collective defines the networking and compute components that will be shared by all tenants. This type of infrastructure sharing provides safe reuse (e.g. VPC, EC2 instances) while supporting isolation of data.

Collectives should be configured with 1 to 3 geographically and politically similar regions, allowing free and fast movement of data.

Collectives are deployed and managed via the Turbot Guardrails Enterprise Foundation (TEF) product in the AWS Service Catalog. At Turbot, collectives are typically named after a famous bridge or tunnel (connection) in the area.

Collective NameRegionsNotes
brooklynca-central-1, us-east-1, us-east-23 regions, low latency, crosses US/CA political boundary
queensboroughus-east-1, us-east-22 regions, low latency, all data in US
towereu-west-1, eu-west-2, eu-west-33 regions, low latency, all data in EU

Most Turbot Guardrails Enterprise customers require only a single collective.

Hives

A Hive defines the physical data storage and caching resources used in Turbot Guardrails Enterprise.

A hive may be shared by multiple workspaces, but a single cannot span multiple hives. Within each hive (physical database), workspaces are separated into different logical schemas to support data isolation and movement between hives if required.

Hives are deployed and managed via the Turbot Guardrails Enterprise Database (TED) product in the AWS Service Catalog. At Turbot, hives are named after a famous scientist in the area(e.g. newton, edison -- as in “hive mind”.)

Multiple hives may be used to create physical data separation (e.g. isolate critical tenants) and for scalability through physical sharding, but most Turbot Enterprise customers will start with a single hive.

Versions

Each Collective has zero or more Versions of Turbot installed. Each version is installed separately and immutable. For example, versions 5.1.0, 5.1.1 and 5.2.0 may all be installed and in use simultaneously. All changes are done through installation of new versions - existing versions are never updated.

Each Version in the Collective may be used for zero or more Tenants at any time.

  1. 1-Nov: v5.1.0 is installed.
  2. 1-Nov: Tenant A is upgraded to use v5.1.0.
  3. 2-Nov: Tenants B, C are upgraded to use v5.1.0.
  4. 5-Nov: All Tenants D-Z are upgraded to use v5.1.0.
  5. 8-Nov: v5.0.0, with zero remaining tenants, is uninstalled.

Versions define the majority of their own infrastructure in a standalone, reproducible manner. For example, load balancers, IAM roles, Lambda functions and container instances are all defined separately in each version. This separation improves reproducibility and accuracy while reducing the risk of installations and upgrades.

Versions are deployed and managed via the Turbot Guardrails Enterprise (TE) product in the AWS Service Catalog. Versions are immutable – as Turbot releases new versions, you should install them via a new instance of the product, not an update to the previous version.

Workspaces

A Workspace is an independent tenant of turbot, with its own version and its own schema (logical shard) in a hive. Each Workspace has its own Turbot root, its own set of mods, and its own web console endpoint.

Workspaces may be hosted in the same collective, and share the same hive, but are independent of each other. Each workspace can be upgraded or downgraded independently, and no data is shared across workspaces.

Workspaces are deployed and managed using Turbot Workspace Manager, implemented as a CloudFormation custom resource.

Customers may have multiple workspaces. For instance, you may wish to separate a development instance of Turbot Guardrails Enterprise from the production instance, in order to test new Turbot versions, modules, etc.

Workspaces per lifecycle phase for the brooklyn collective for vandelay.com :
  • dev.brooklyn.vandelay.com
  • qa.brooklyn.vandelay.com
  • prod.brooklyn.vandelay.com