Microservices is a Deployment Model, not an Architecture

There are many articles that have been written about how to build a microservices architecture or whether to go with a microservices architecture or a monolithic architecture. Since architecture is an issue that needs to be addressed early in a project’s lifecycle, these articles imply that the decision regarding microservices vs. monolith is one of the first ones we have to make. Actually, the microservices vs. monolith decision should be one of the last ones we make.

How is that possible? Doesn’t the choice of microservices or monolith have such profound implications on the software architecture that once having made that decision you have chosen your software path and have passed the point of no return? Not at all, because the way a software system should be architected and designed is the same regardless of which choice you make. Microservices is not an architecture, it is a deployment model.

The decision on whether to deploy a system as microservices or as a monolith comes down to criteria such as whether individual parts of the system will have different release cadences, have different scalability requirements or will need to be deployed in different places such as on-prem vs. cloud due to security requirements. If I know in advance that one or two sets of services will need to be released more often or will have to be scaled up and down more often than the others, I can make a case for a microservices deployment model early in the project. If I’m not sure, I will recommend starting with a monolithic deployment model. I can defer the final decision on the deployment model until later, if the software system is architected correctly.

What does it mean for the software system to be architected correctly? Let’s answer this question using an example. Say we’re designing a ticketing services application. There are some fundamental concepts that this app will deal with, such as tickets, purchases of tickets, events for which tickets will be sold, and customers. A package or namespace hierarchy for this app may look something like this:

com.acme.ticketapp
    .ticket
    .purchase
    .event
    .customer

Each of those four top-level packages represents a part of the system that is independent of and decoupled from all of the others. We can think of them as bounded contexts in Domain-Driven Design parlance, but I’m going to use the more generic term subsystem. Each has a well-defined API, which could be a REST API or a service facade, and each has a client for communicating with the other subsystems through their APIs. For example, the ticket subsystem’s API will be provided by a class called TicketServiceAPI or TicketRestAPI, depending on how that subsystem is deployed. (The former will be an implementation of an interface called TicketAPI.) If a class in the purchase subsystem needs information from the ticket subsystem, it will get that information through the TicketClient interface, which is implemented by a class called TicketServiceClient or TicketRestClient, depending on how the ticket subsystem is deployed. Thus, all interactions between subsystems are accomplished through APIs using clients. No code in any subsystem has any knowledge of, nor direct interaction with, any code in any other subsystem. Each subsystem’s architecture is an instance of a Clean Architecture.

If the application is composed of a set of independent, decoupled and well-architected subsystems, we have a lot of flexibility. We can start with a monolith: one shared database, service facades as subsystem APIs and clients that call methods in the service facades. If we decide later that we want to deploy the subsystems as microservices, we can replace the service facades with REST APIs, replace the client implementations that call the service facades with implementations that call REST endpoints, split up the shared database, make required configuration changes, and even split out each subsystem into its own source code repository. None of these actions will have any impact on code executing business or domain logic, so no changes need to be made to that code. Thus, we can make a deployment model decision at any point during the project.

This idea is not new. It’s the way we should always architect software systems. And it allows us to defer the decision on whether to deploy as microservices or as a monolith until we have enough information to make the right decision.