Blazing iconBlazing

Organizational Hierarchy

Edit on GitHub

Understanding organizations, projects, and clusters in Blazing

Blazing Core Compose uses a hierarchical organizational model to manage infrastructure at scale:

Plain Text

Overview

Organization

The top-level entity representing your company or team.

YAML

Characteristics:

  • One organization per company/team
  • Contains multiple projects
  • Shared billing and access control
  • Organization-wide policies

Use Cases:

  • Company: "Acme Corp"
  • Team: "Platform Engineering"
  • Department: "Data Science"

Project

Logical grouping of related clusters within an organization.

YAML

Characteristics:

  • Groups related infrastructure
  • Separate billing tracking
  • Project-level policies
  • Resource quotas per project

Use Cases:

  • Environment: "production", "staging", "development"
  • Product: "mobile-api", "web-backend", "ml-pipeline"
  • Customer: "customer-acme", "customer-beta"

Cluster

A deployment unit with its own regional infrastructure and services.

YAML

Characteristics:

  • Contains multiple services
  • Deployed across multiple regions
  • Isolated network and security
  • Independent scaling and updates

Use Cases:

  • Service cluster: "api-backend", "data-processing"
  • Application: "mobile-app", "admin-portal"
  • Version: "api-v1", "api-v2"

RegionSet

Geographic distribution of your cluster infrastructure.

YAML

Characteristics:

  • Automatic region selection by server
  • Provider-specific distribution
  • Geographic constraints
  • High availability zones

Services

Individual application components running within a cluster.

YAML

Characteristics:

  • Docker container-based
  • Independent scaling
  • Service-level configuration
  • Inter-service networking

Complete Example

Here's how all levels work together:

YAML

Resource Hierarchy

API Paths

Resources are accessed via hierarchical API paths:

Plain Text

Example API calls:

Bash

CLI Commands

The CLI respects this hierarchy:

Bash

Access Control

Organization-Level Permissions

| Role | Permissions | |------|-------------| | Owner | Full access to all resources | | Admin | Manage projects and clusters | | Developer | Deploy and manage clusters | | Viewer | Read-only access |

Project-Level Permissions

Permissions can be scoped to specific projects:

YAML

Cluster-Level Isolation

Each cluster has:

  • Isolated network (separate VPCs/VNets)
  • Separate service accounts
  • Independent secrets management
  • Per-cluster encryption keys

Billing and Quotas

Billing Hierarchy

Plain Text

Resource Quotas

Set limits at organization and project levels:

YAML

Multi-Tenant Patterns

Pattern 1: Project Per Customer

Isolate customers at the project level:

Plain Text

Benefits:

  • Strong isolation
  • Per-customer billing
  • Customer-specific policies
  • Easy offboarding

Pattern 2: Cluster Per Environment

Separate environments within projects:

Plain Text

Benefits:

  • Environment isolation
  • Shared project policies
  • Unified billing per product
  • Progressive deployment

Pattern 3: Cluster Per Service

Microservices architecture:

Plain Text

Benefits:

  • Service isolation
  • Independent scaling
  • Service-specific configuration
  • Team autonomy

Best Practices

Naming Conventions

Use consistent naming:

YAML

Organization Structure

For small teams (1-10 people):

Plain Text

For medium teams (10-50 people):

Plain Text

For large teams (50+ people):

Plain Text

Migration Strategy

Start simple and grow:

  1. Phase 1: Single project, single cluster
  2. Phase 2: Add staging project
  3. Phase 3: Split into multiple clusters
  4. Phase 4: Organize by product/team

Next Steps

Architecture Overview