Deployment Cells: A Cellular Architecture for Multi-Cloud Service Delivery¶

What is a Deployment Cell?¶

Deployment cells are the foundational building blocks of Omnistrate's cellular architecture, designed to help SaaS Providers deliver and manage services across multiple clouds and customer environments. Think of deployment cells as isolated, self-contained units of compute infrastructure where your services run. Deployment cells leverage Kubernetes allowing you to leverage existing operational tools and practices while providing a robust framework for scaling, isolation, and operational efficiency.

A deployment cell maps to a Kubernetes cluster plus the supporting network, system add-ons, and Omnistrate agents in a specific account and region. It is the data-plane location where your instances actually run.

A deployment cell is not the Omnistrate control plane, SaaS portal, or API layer.

Why Cellular Architecture?¶

In traditional monolithic infrastructure, a single failure can cascade across your entire service delivery platform. Cellular architecture compartmentalizes your infrastructure into independent cells, providing:

• Blast Radius Containment: Issues in one cell don't affect others
• Scalable Growth: Add new cells as you grow without impacting existing deployments
• Geographic Distribution: Deploy cells close to your customers for better performance
• Multi-Cloud Flexibility: Mix and match cloud providers based on customer needs

Key Concepts¶

Cell Types and Use Cases¶

Dedicated Customer Cells¶

• Single-tenant infrastructure for enterprise customers
• Complete isolation for compliance and security requirements
• Custom configurations and deployment constraints
• Ideal for: Regulated industries, high-security workloads, custom SLAs

Shared Multi-Tenant Cells¶

• Cost-effective infrastructure shared across multiple customers
• Resource optimization through workload consolidation
• Standardized configurations
• Ideal for: SaaS Products, development environments, cost-sensitive workloads

Adopted Cells¶

• Bring-your-own-infrastructure model
• Leverage existing customer Kubernetes clusters
• Maintain customer's existing security and compliance postures
• Ideal for: Enterprise customers with existing infrastructure investments

Deployment Cell Lifecycle¶

How a cell is created and reused depends on the deployment model:

• Hosted: Omnistrate provisions the deployment cell in one of your cloud accounts and can place multiple instances there based on your tenancy and placement rules.
• BYOC: Omnistrate provisions the deployment cell in the customer account. The first deployment in an account and region usually creates the cell, and later deployments in that account and region typically reuse it.
• Adopted: The deployment cell is an existing Kubernetes cluster that you register with Omnistrate.

Because cells are cluster-scoped infrastructure, not every operational dependency should be coupled to an individual instance lifecycle.

Cell-wide prerequisites belong at the cell layer¶

Install components that should exist once per cluster, such as shared Operators, Prometheus stacks, ExternalDNS, CSI drivers, ingress controllers, or policy controllers, at the deployment-cell layer. Use Deployment Cell Amenities for these prerequisites instead of treating them as manual post-install steps on each instance.

This keeps cluster-wide dependencies upgradeable independently from any single tenant instance.

Geographic Distribution¶

Deployment cells naturally support geographic distribution:

• Deploy cells in regions close to your customers
• Maintain data residency compliance
• Optimize for latency-sensitive applications
• Enable disaster recovery through geographic redundancy

Scaling Patterns¶

Horizontal Scaling¶

• Add new cells as customer base grows
• No need to resize existing infrastructure
• Zero-downtime expansion

Customer-Driven Scaling¶

• Start customers on shared cells
• Graduate to dedicated cells as they grow

Operational Benefits¶

Isolation and Security¶

• Network Isolation: Each cell has its own network boundaries
• Resource Isolation: CPU, memory, and storage are cell-specific
• Failure Isolation: Problems don't cascade across cells
• Security Isolation: Compromised cells don't affect others

Maintenance and Updates¶

• Rolling Updates: Update cells independently
• Canary Deployments: Test changes on specific cells first
• Maintenance Windows: Schedule per-cell maintenance
• Version Management: Different cells can run different versions temporarily

Multi-Cloud Strategy¶

Deployment cells enable true multi-cloud operations:

Cloud Provider Flexibility¶

• Run cells on AWS, Google Cloud, or Azure
• Mix providers based on:
• Customer preferences
• Regional availability
• Cost considerations
• Feature requirements

Hybrid Deployments¶

• Combine cloud and on-premises cells
• Support air-gapped environments

Conclusion¶

Deployment cells provide the architectural foundation for building scalable, resilient, and flexible service delivery platforms. By embracing cellular architecture, SaaS Providers can offer better isolation, performance, and reliability while maintaining operational efficiency across multiple clouds and customer environments.