What Does Architecture Mean? Code, Runtime and Deployment

Objectives

By the end of the lesson, you can distinguish the code structure, the runtime structure and the deployment structure of a system, and you can tell which view someone is talking about when they say "monolith" or "microservice".

Why are several views needed?

The question "monolith or microservice?" can only be answered meaningfully if it is known which boundary is meant. The same system can be divided in three ways, and the three divisions can be fine or coarse independently of each other. If these are not separated, people often argue about two different things.

What is architecture?

The architecture of a system is the set of the important parts, the relationships between them, and the decisions that constrain later change. It is not a description of the whole code, but of what is expensive to change. That is why most architectural questions are really questions of trade-offs: what becomes easier, and what becomes harder in return.

The three views

Code structure. Which module carries which responsibility, what does it expose, and what does it use from other modules? Here the boundary is held by compile-time rules, package visibility or automated dependency checks.

Runtime structure. How many processes run, where do they keep their state, and how do they communicate? Between two separate processes there is no shared memory and no direct function call: data must be turned into a message, sent, and converted back on the other side.

Deployment structure. What can be released, restarted and rolled back independently? The deployment unit is the smallest package that can be released in a single step.

flowchart TB
  subgraph Source["Code structure"]
    A["Module A"] --> I["Its public interface"]
    B["Module B"] --> I
  end
  Source --> D["One release package"]
  D --> E["Running instance 1"]
  D --> F["Running instance 2"]
  E --> DB[("Database")]
  F --> DB

The diagram shows two modules, two running instances and a single deployment unit. The number of instances may be justified by load; it does not mean that the responsibilities were separated.

View	Question	What holds the boundary?	Common misunderstanding
Code structure	Who may use what?	Compiler, visibility, rule checks	"Separate folder = separate module"
Runtime structure	What runs separately, and how do they talk?	Operating system, network	"More instances = more services"
Deployment structure	What can be released separately?	Release process, versions	"Separate repository = separate release"

How does this relate to the other concepts?

In the following chapters every architecture is a combination of these three views:

• the monolith is one deployment unit and one running process group; its code structure can be tidy or untidy;
• the modular monolith is the same with checked internal boundaries;
• microservices are separately deployable, separately running services that manage their own data.

An application packaged into a container is not a microservice just because of that: the container is a packaging and execution tool. Neither the language nor the framework decides the architecture; both a monolith and a system split into services can be written in the same language.

Common misconceptions

Statement	Clarification
"If six instances run, it is already a distributed system, that is, microservices."	The six instances are copies of the same single deployment unit.
"If services are in separate repositories, they are independent."	If every change must be released together, the release coupling remains.
"The container is the technology of microservices."	The container is a packaging form; it can contain a monolith too.
"Architecture is the list of technologies."	Architecture is the system of the parts, the relationships and the hard-to-change decisions.

In short

• Architecture is the set of important parts, relationships and decisions that constrain change.
• Three views must be examined separately: code, runtime, deployment.
• The deployment unit is what can be released and rolled back together.
• The number of instances, the container and the number of repositories do not determine the architecture.

Review questions

1. An application runs in six identical instances behind a load balancer. What is the number of deployment units, and why?
2. Two services are in separate repositories, but they must always be released together. In which view did the coupling remain?
3. What question would you ask to decide whether a diagram shows the code, the runtime or the deployment?

Learning resources

• Architecture styles (Azure Architecture Center) — an "architecture style" as a family of architectures with shared characteristics; styles seen as constraints.
• Microservices (Martin Fowler and James Lewis) — a classic description of the microservices style; the definition of "services running in their own process".