# Current architectures

Let's have a quick look at some of the mainstream software architectures before we compare them to Polylith later on.

We'll describe our development and production experiences with three mainstream software architectures. But we'll start by defining our terms:

{% hint style="success" %}
**Software architecture:**

* The **high-level** structures of a software system
* Fundamental structural **choices**, which are **costly to change** once implemented
  {% endhint %}

{% hint style="info" %}
**Monolith:**

* A software architecture where the code is stored in a **single codebase** and deployed as a **single artefact**
  {% endhint %}

{% hint style="info" %}
**Microservices:**

* A software architecture consisting of **small** and **independently deployable** services
* Each service runs in a **separate process** and communicates with the others across a **network**
  {% endhint %}

{% hint style="info" %}
**Serverless:**

* A software architecture based on a **cloud-computing** execution model
* The **cloud provider** dynamically **manages** the allocation of machine resources
  {% endhint %}

### Development experience

{% hint style="warning" %}
The traffic lights are a rough summary of our personal experiences. Please take them as our subjective opinions, not as objective truths.
{% endhint %}

{% hint style="info" %}
We split the ratings into "small" and "large", because building larger and more complex systems usually gave us a different experience.
{% endhint %}

![Our subjective development experiences](/files/-LMh-s5bMJuCTQ7B9CB1)

Monoliths keep all their code in one place, which gives a friction-free development experience for code navigation, refactoring, debugging, code reuse, and testability. However, as Monoliths grow, they trend towards "big balls of mud", which become very difficult to maintain.

Working with a single Microservice is great, as it gives us the same benefits as working with a small Monolith. However, the more Microservices we maintain, the worse our development experience becomes. That's because each new service boundary increases the friction for code navigation, refactoring, debugging, code reuse, and testing.

Serverless architecture is inherently modular and functional, which gives significant advantages for simplicity and testability. However, the distributed nature of its code execution has a negative impact on our code reusability, debugging and testing.

### Production experience

![Our subjective production experiences](/files/-LMh0-8KqNHH1oouolN_)

Monolith's one artefact approach keeps operation costs low and simplifies deployment, but makes horizontal scalability difficult.

Microservices' distributed approach gives excellent scalability and robustness, but makes deployment complex and hosting expensive.

Serverless' "outsourcing" approach gives excellent scalability, reduces our ownership of deployment complexity, and keeps server costs in-line with our usage, but also gives us an air-tight vendor lock-in.

### So what's missing?

These architectures give us plenty of guidance on how to *deploy* our systems, but very little guidance on how to *structure* our code within each system. Over the years, we've tried many different approaches to improve our systems' internal structures (e.g. [DCI](https://en.wikipedia.org/wiki/Data,_context_and_interaction), [DDD](https://en.wikipedia.org/wiki/Domain-driven_design), [Design Patterns](https://en.wikipedia.org/wiki/Software_design_pattern), [SOA](https://en.wikipedia.org/wiki/Service-oriented_architecture), [SOLID](https://en.wikipedia.org/wiki/SOLID), [Hexagon](https://en.wikipedia.org/wiki/Hexagonal_architecture_\(software\)), etc.), but none of them took us all the way to development nirvana.

To get there, we realised we needed to roll up our sleeves and invent a whole new approach.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://polylith.gitbook.io/polylith/conclusion/current-arcitectures.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.