43 - A Decentralized Reference Architecture for Cloud-native Applications
Asanka Abeysinghe from WSO2 joins Chris Reddington to introduce the cell-based architecture — a decentralised, API-centric reference architecture for cloud-native applications, intentionally designed to be vendor and technology neutral.
Key Topics Covered
- Why a new reference architecture? Most published reference architectures are really reference implementations tied to specific vendors or products. The cell-based model aims to be genuinely technology-agnostic and reusable across organisations.
- Microservices governance challenges: As the number of microservices grows, coordinating them becomes complex. Without clear domain boundaries, teams accumulate technical debt and federated governance becomes unmanageable.
- Domain-Driven Design (DDD): Scoping microservices by business domain — not arbitrary size — is the foundation. A cell groups related microservices under a single, well-defined boundary aligned to a business capability.
- Cell-based architecture: A cell is an independently deployable unit that exposes a well-defined API surface outward while managing its own internal microservices privately. Analogous to biological cells — self-contained, composable, and independently scalable.
- API management and identity: API management, integration middleware, and identity & access management (IAM) are the glue between cells — WSO2 provides these as open-source components.
- Aligning architecture, development, and DevOps: The three disciplines have historically operated in silos. The cell-based model provides a common unit of work that spans all three, enabling the iterative architecture approach teams need to keep up with evolving systems.
- Organisational alignment: Cells map naturally to autonomous two-pizza teams structured around business domains, making the architecture a reflection of real team ownership and accountability.
Related Content
29 - The Sidecar and Ambassador Patterns
When modernising a legacy application, rewriting everything from scratch is rarely feasible. The Sidecar and Ambassador cloud design patterns offer a pragmatic alternative — attach a companion process to offload cross-cutting concerns like retry logic, circuit breaking, and protocol translation without modifying the application itself. Chris and Peter explore both patterns in depth, covering when to use each, how they relate to service meshes, and their role in Kubernetes-based architectures.
16 - The Backends for Frontends and Strangler Pattern with Peter Piper
Managing APIs across web, mobile, and multiple consumer types creates tight coupling that slows modernisation and makes versioning painful. In this episode, Chris Reddington is joined by Peter Piper to explore the Backend for Frontends (BFF) pattern — creating dedicated backends tailored to each consumer — alongside the Strangler Fig pattern for incrementally migrating legacy monoliths without disrupting existing clients. The Façade pattern also features as a key decoupling mechanism for smooth API migrations. Part of the "Architecting for the Cloud, One Pattern at a Time" series.
34 - The Bulkhead Pattern (Isolate your components to prevent failures)
The Bulkhead pattern takes its name from the watertight compartments in a ship's hull. Just as those compartments prevent a single breach from sinking the whole vessel, the Bulkhead pattern isolates components of a cloud application so that failures or resource exhaustion in one service cannot cascade to others. This episode covers partitioning strategies, connection pools, Kubernetes resource limits, and multi-tenancy considerations.