Layered vs decoupled architecture

Introduction

In software design nothing is set in stone. It is a fact that the last 15 years (I can′t talk in decades here, software development ages like dogs :)) were dominated by layered architectures. All frameworks have lots of ‘sub-frameworks’ to divide your app in layers and distribute its behavior among them.

Layered Architecture

Who hasn't seen this image? A typical architecture made up of six layers that solves all our problems.

However, decoupled architecture was still there, it just was not fashionable, and deployment solutions were too complex.

But, in 2013, Docker was born and came to change a lot of things, including software architecture…

Decoupled Architecture

Decoupled architecture is where the different components/layers that make up the system interact with each other using well-defined interfaces rather than depending tightly on each other. A component could be a part of your system or an entire application in itself.

Every component has all the parts that it needs to live by its own, and communicates with other components by a predefined API.

Every component can be designed and developed separately, even with different programming languages. They are unaware of the existence of other components.

The drawbacks of this architecture can be reduced to two points:

• API definition and complexity
• Deployment complexity

Both of them have changed dramatically in the last years.

Currently, APIs are defined with Rest endpoints that are easy to develop, maintain and discover. They are also quite fast and very easy to consume.

If you start decoupling your system, you will rapidly realize that components will grow in quantity very rapidly, so application deployment becomes a nightmare. But, with Docker and some configuration management tools like Ansible, Puppet or Chef, this nightmare goes away and we can start taking advantage of decoupled architecture.

What should we do?

The first thing that I advise you is that you read and analyze the current status of your architecture. Both approaches I mentioned have existed since the dawn of software development, but surrounding tools and language ecosystems are constantly changing and, in turn, generate global tendencies on architecture design.

If you are not going to embrace Docker and at least one configuration management tool, I suggest that you stick with layered architecture. But if you decide to get onto the Docker train, please start thinking about decoupling your system.

All systems have different complexity, maturity, and needs, so it is difficult to draw the line between the layers and transform it in two or more isolated components. It is the responsibility of your technical guru to do it, and the whole team to follow.

Decoupled architecture will give your teams autonomy and power over deployment. Of course, you will lose control on standardization of development, since the only standard will be APIs and deployment recipes or Docker images.

At Intraway, we have taken note of this and we have started playing our cards...