The API space is continuously evolving, increasing options, and changing paradigms to suit specific use cases. This evolution is driven, at least in part, by the continued adoption of API technology in the enterprise space. That being said, enterprise demands are unique, and these specific caveats to traditional use cases have created new solutions and paradigms to address the ever-evolving complexity.

Cell-based architecture is one such solution. What is this architecture, and what, specifically, is a cell? Today, we’re going to dive into the cell-based approach, define what a cell is in this context, and look at a hypothetical use case. We’ll also outline the difference between a cell-based architecture and service-oriented architecture.

Keep in mind this is a top-level overview of this approach; the solution itself is rather complicated. For real-world cases, one can dive into documentation here.

The Rationale of the Cell-Based Approach

As more enterprises create more microservices, new needs arise. Composition, security, discoverability, governance, consistency, and unification have all become larger issues for enterprise users. Additionally, continuous development and other agile paradigms have significantly shortened the lead time to develop and release, resulting in fragmentation and greater complexity occurring with higher speed and frequency.

The cell-based approach was explicitly designed to respond to these issues and mitigate those concerns. Per the documentation, cell-based architecture is meant to address this changing paradigm, and address future challenges that derive from it.

The general idea behind the cell-based architecture is to take microservices design one step further. By leveraging cells, which are application component and resource units made up of multiple APIs, services, policies, etc., cell-based architecture aims to reduce unit complexity, and thereby provide more granular control and increased ability to function.

At its most basic level, cell-based architecture is designed to answer four chaotic realities in the enterprise architecture:

• Agility, or the ability to quickly act and meet challenges without significant lead-time;
• Scalability, the ability to leverage versioned replicable, and well-defined interfaces to meet changes in demand;
• Modularity, or the ability to use uniform, defined structures to quickly change resource allocation and affect the overall platform in a well-documented and understandable way; and
• Governance, or the management, monitoring, and control of organizational policies in practice across the service in totality.

To manage all of this, the architecture argues for the movement of resources into a “cell.” But what, in this context, is a cell?

What is a Cell?

Cell-based architecture is built around the idea of groupings of services and data around a gateway associate with a collection of components. This total collection is then referred to as a “cell.” Each cell is independent of other cells and can be deployed or managed as separate entities from other cells. These cells communicate with one another via a set of network endpoints, much like a microservice API collection would, with the caveat that the policies and frameworks for those communications are built into each cell separately.

Each cell is thus responsible for providing its own definition and documentation for communication. The contents of those cells (which the documentation states can have 1:n components grouped) are designed to be reusable and instantiable across multiple cell instances.

In practical application, what this means is that each cell is its own microservice or microservices, with their interactions governed by their policies and settings as defined per business logic and enterprise governance. This data is then taken from the cell and pushed externally to either other cells or the requesting endpoint.

This interaction can be RESTful, allowing an abstraction that is queryable and toggleable. It can be event-driven, allowing for changes to trigger actions in the cell. Or, it can be stream-driven, allowing for pattern matching and analysis based upon dynamic behaviors. Ultimately, the cell relationship is a situation in which the theory looks like an application in practice, but in actuality, it can be quite abstracted depending on the final implementation. Let’s look at a theoretical application to see what this looks like.

Cell-Based Architecture in Action

Let’s assume we run a hotel with an online reservation system. The hotel used to run on a legacy booking system, but as we’ve developed new systems, we’ve moved away from the monolith and into microservices. The hotel also uses a collection of APIs to handle room service, media rental, and other activities.

In the cell-based architecture paradigm, what this would practically look like is a set of cells, each self-governed but understandable through other cells. We would separate the components into related cells, typically related by their form of action or instantiation. For instance, everything to do with hospitality is likely event-driven (when a guest requests turndown, a wakeup call, etc.). These events would then trigger something within that cell. Thus, it would make sense for the hospitality cell to exist as its own entity, with a set of ambassador, adapter, and sidecar endpoints to handle external cell communication.

Our hotel has three general domains that need to be put into cells:

• Cell-1:Reservations will handle all reservation data and activity and be driven by RESTful Web APIs. This cell will leverage a sidecar gateway to tie into the overall data systems. It will also have a specific policy governance system to ensure that we are adhering to PCI DSS, reporting, and other standards.
• Cell-2:Hospitality will utilize events to trigger actions and support LaundryServices, MediaServices, and FoodServices. As each of these events is driven from other interfaces, we will use brokers to identify whether the request is from a user or a staff member.
• Cell-3:Legacy will be stream-driven, so when a user uses an old reservation code or attempts to retrieve data about an old stay pre-cell implementation, that data can be extracted from the proper resources. This will require both a sidecar to tie into the data, and a broker to negotiate whether or not the data is legacy.
• Cell-4:Data will be our final cell. It will host all relational databases and be internally queryable using GraphQL endpoints and various sidecar integrations to ensure adequate data service.

Check-In Codeflow

Let’s assume a person is staying at the hotel for one night. They first make their reservation on the Web API, which is the first transit point into our network. This reaches the Cell Gateway for Cell-1, which interprets the data and uses the internal API to reach Cell-4, which then stores this reservation data. Later, when the customer checks in, this data is recovered using a GraphQL request by the Reservation system to validate that the data held in Cell-1 and Cell-4 match the data provided by the customer (license plate for car parking, ID for identity, etc.)

Now that the user has checked in, their status within Cell-2 is updated to reflect that the room is “active.” This is done by having the Reservations Cell API update the Data Cell API, which is a triggering event that Cell-2 monitors. From here on out, any request made through the web API in the Reservations cell (which is the transit point that the customer interacts with) will be handled as an event forwarded to Cell-2.

Requests such as room service can be made either via an automated phone teller or an online portal. Either way, this request is communicated through Cell-2’s Cell Gateway, which prompts the event tracker to print a command to the relevant station (such as a food order to the kitchen or a turndown request to the sanitation department).

Legacy Conversion

The customer is a long-time user and has stayed at the hotel many times previously. Because of this, they have significant Rewards points that can be used in the reservation system. Because Cell-1 is very new, however, these points must be migrated. When the customer logs in, they use a number format that the Reservations system has flagged as a legacy number.

At this time, Cell-1’s Gateway notifies the user and redirects them to Cell-3, the legacy system, via a cell gateway broker. From here, the customer can authenticate and opt to migrate the data to the modern system. Once this choice is made, the Legacy system adds a flag via the sidecar on Cell-4 (data) to update the account status to “migrated,” preventing any further need to access the legacy systems.

Checking Out

Once the customer is finished with their stay, they make their way downstairs. They request a check out at the desk, and everything that happened when they checked out is done in reverse.

Iteration and Development

Our hotel example is one typical flow for this kind of architecture, but we can take it one step further. One could imagine an authentication system to enable remote access to a hotel’s gym. This added functionality would likely require a new cell.

While other architectures would require the reservation system to be updated, and the databases to be changed, within cell-based architecture, we can build the entire solution within a new cell, and simply leverage the existing systems for checking that the registration number is valid. This extensibility demonstrates the power of cell-based architecture. In essence, cell-based architecture is a microservice of microservices, and by abstracting these concepts away from each other and categorizing them into business, logic, and function, agile and scalable development is made easier.

We should note here that the organization in this hypothetical implementation is quite wide-ranging. In a completely cell-based architecture approach, each element would likely be its own cell. Rewards, reservations, and check-in/check-out would likely be their own cells, or at the very least organized into smaller cells, as opposed to the singular cell presented here for simplicity

Comparing Service-Oriented and Cell-Based

Of course, those familiar with service-oriented architecture (SOA) may see cell-based architecture as simply a rebranding of that approach. The reality is that the two concepts are related, but occur at different levels. Service-oriented architectures separate components based on their purpose in service to the user, and in many ways, cell-based architecture does that as well.

However, cell-based architecture is an even more specific separation in that each cell is built not only to house the specific components for that function, but also to facilitate and control the brokered interactions per policy statement and purpose. Additionally, these cells are designed and built to expand and scale.

For instance, in service-based architecture, if another rewards system was put in place, this would (in theory) either sit outside of the cluster of services or just be a secondary server within the core service collection. In the cell-based approach, as everything is abstracted into unique entities, the solution would simply be to create a new cell, state what the brokered communication looks like, enable the various gateways and brokers needed to carry this out, and finally enable the cell.

In the cell-based architecture approach, things are broken down to a smaller level, with each cell representing an aspect or fundamental group of a larger collection of cells that in totality represent the service.

Final Thoughts on Cell-Based Architecture

The cell-based architecture paradigm is an interesting one, but it does require some specific conditions to be worth the investment in time and resources. Cell-based architecture is very good for enterprise implementations, especially when there is a large amount of governance or policy baked into each interaction. Truthfully, the effectiveness of a major selling point scales down the smaller scale of the implementation.

When you have many different microservices, all interacting in a specific, limited way, this is the right solution. If you have one set of services, all of which are related and work on the same materials, and you don’t intend on scaling, this might not be a great solution, and a more traditional microservice (or even monolith) approach may be more beneficial.

What do you think of this approach? Are there use cases for smaller implementations? Let us know below.