Is layered architecture style inherently monolithic?

Question

Overall cost and simplicity are the primary strengths of the layered architecture style. Being monolithic in nature, layered architectures don’t have the complexities associated with distributed architecture styles, are simple and easy to understand, and are relatively low cost to build and maintain. However, as a cautionary note, these ratings start to quickly diminish as monolithic layered architectures get bigger and consequently more complex.

- Fundamentals of Software Architecture,\ Mark Richards, Neal Ford, chapter 10. "Layered Architecture Style".

In "Fundamentals of Software Architecture" they imply that layered architecture style is inherently monolithic.

Which to me seems like a questionable statement:

1. When you use microservice-based architecture it's still useful to split each microservice's code into layers and have business logic, storage and communication as separate layers. Simply because it encourages separation on responsibilities, modularity.
2. Ultimately - even if you write a layered monolithic application - nothing prevents you from deploying it as many different separate microservices.

I'm looking for answers supported by references to authoritative sources.

Answer 1

The purpose of creating layers in an application is to separate technical responsibilities from each other. An application with a layered architecture typically has a presentation layer, a service layer and a data access layer, but there could be more.

When systems grow bigger they become harder to maintain. A change in one part could have unintended consequences in another. To solve this, modules can be incorporated into the system architecture. Each module in the system is responsible for a particular piece of functionality. Within a module, we often still need the same technical capabilities, so we can again apply layering to separate these technical concerns.

When teams grow bigger, it becomes harder to work on the same application. In order to deploy a new version, all modules have to be in a stable state. This slows down the release cycle. In order to solve this, microservices were invented, so that teams could be split into several smaller teams.

To summarize the above: layers, modules and microservices solve different problems.

The author quoted in the question compares layers with ‘distributed architecture’. This implies that the technical concerns are distributed to separate services.

Building systems like that is not a good idea. Several services, possibly maintained by different teams, have to cooperate to get new versions out for a single piece of new functionality.

Teams and microservices are better formed around separate functionalities. This enables teams to have their own release cycle and make their own technical decisions. And surely separating technical concerns into layers is one of those decisions.

To answer the question: ‘Is layered architecture style inherently monolithic’. I would say: yes, any (part of/microservice) application that uses layers should be deployed as a single (monolithic) unit.

Answer 2

I don't have the book you cited from at hand, but from the excerpts I could find by googling, I am sure the authors were talking about the specific horizontal layering

Presentation Layer / Business Layer / Persistence Layer / Database Layer

and about software architectures which use this as its primary-and-only architectural style. The cite seems to be ripped out of context.

So when we add the missing context and ask instead "Is an exclusively horizontally layered architecture inherently monolithic", then the answer is clearly "yes" - when we find the above layers in one application system, none of them maps to a "use case" on its own, they will usually have to work together to create something useful for a user. But the real point is the attribute "exclusively", which excludes "vertical layers" like micro services.

As soon as you introduce additional structure elements into your architecture, you are most probably leaving the ground of what Richards and Ford were describing - which I guess should answer your question:

• sure micro services can have horizontal layers inside (which may pay off at a certain size)

• using horizontal layers in a micro service does not make the system a monolith.

Answer 3

No.

How do I know?

• People wrote monoliths before layers were a thing
• A layer is a collection of modules/classes with similar responsibilities
• Plenty microservices have layers

Now all that said, layers give you the ability to easily grow your codebase. Once it gets so big that it's hard for one person to maintain then it's hard to call it a microservice. But that's not inherently monolithic. That's just letting it grow.