Architecture on Simple Enough Blog

How to create a security group that allows only traffic coming from CloudFront?

Thu, 05 Mar 2026 17:52:00 +0100

How to create a security group that allows only traffic coming from CloudFront?

Why this question keeps coming back

In the AWS world, some questions come up again and again.
Not because they are poorly phrased, but because they point to a real friction between security, networking, and application architecture.

ADR (Architecture Decision Record): documenting decisions that matter

Mon, 23 Feb 2026 11:00:00 +0100

Engineering teams spend a lot of time discussing, arbitrating, choosing… and then forgetting why they made certain decisions.
The outcome is familiar:

the same debates come back every three months,
decisions get challenged without the original context,
onboarding depends on “the people who know,”
and unnecessary migrations are born from a simple loss of memory.

An ADR (Architecture Decision Record) exists to avoid that. It’s not a “big architecture doc,” nor a requirements spec: it’s a short note that captures an important decision, with just enough context to keep it understandable and reusable.

AWS multi-accounts: architectural solution or disguised organizational debt?

Wed, 18 Feb 2026 17:30:00 +0100

I. Introduction

Creating multiple AWS accounts is now widely presented as a near-universal best practice.
It is often introduced through simple, console-oriented tutorials that give the impression that the problem boils down to a few clicks.

This view is misleading.

Multi-account is not an implementation detail, but a fundamental architectural choice.
It directly impacts:

how teams work,
how security is enforced,
cost visibility,
the ability to automate,
and organizational resilience to human error.

When misunderstood, it creates organizational debt just as costly as traditional technical debt.

Entering the Cloud: The Gates of Hell

Wed, 04 Feb 2026 09:10:00 +0100

Entering the cloud is rarely experienced as a simple infrastructure change.
For many organizations, it is a brutal—almost violent—break with their habits, tools, and mental models.

What was supposed to bring simplicity instead reveals a complexity that had long been hidden.
And this complexity is not only technical.

I. The Call of the Cloud

The cloud always begins with a seductive promise.

Latency: Understanding, Perceiving, and Mastering an Invisible Delay

Wed, 28 Jan 2026 09:00:00 +0100

Latency is one of those ubiquitous terms in computing, often used to explain a negative feeling — “it lags”, “it’s slow” — without its real meaning being clearly understood.
Yet latency is neither a bug nor a simple performance issue: it is a structural constraint of modern computer systems.

This article offers a comprehensive view of latency:

what it is from a general perspective,
its technical definition,
how it is perceived by users,
the trade-offs it imposes,
and above all, how to master it architecturally.

I. What Is Latency?

1. General definition

In its simplest sense, latency refers to the waiting time between an action and the system’s first reaction.

Test-Driven Infrastructure: Applying TDD to Infrastructure as Code

Wed, 14 Jan 2026 13:45:30 +0200

Test-Driven Infrastructure

Applying TDD to Infrastructure as Code

Test-Driven Development (TDD) is now well established on the application side.
However, when it comes to infrastructure, many still consider TDD unnecessary, too complex, or unsuitable.

That is a mistake.

TDD applied to infrastructure already exists, often without being named as such. When properly understood, it becomes a major lever for securing, structuring, and evolving a cloud platform.

“It’s slow”, “it lags”, “it bugs”: but in the end, what does it really mean?

Tue, 30 Dec 2025 10:00:00 +0100

Introduction

In a family, at work, or within a technical team, it is very common to hear: “it’s slow”, “it lags”, or “it bugs”. These expressions are often used interchangeably… wrongly. They mix together problems that actually have nothing to do with each other.

Understanding the difference between these three situations makes it possible to explain what is happening more clearly, to react more quickly, and above all to avoid bad solutions. A performance issue is not solved like a bug, and a bug never disappears just because the machine has been made more powerful.

Using Constants in TDD with Go

Tue, 23 Dec 2025 10:08:49 +0200

Best Practices, Pitfalls, and Design Signals

Test-Driven Development (TDD) is not only about writing tests.
Its primary purpose is to design software.

In Go, the use of constants is often misunderstood in TDD:

should they be exposed?
tested?
injected?
avoided?

This article proposes a pragmatic and idiomatic Go approach, based on real-world experience, to understand when a constant represents good design… and when it hides a deeper problem.

Interfaces, Functions and Modules in Go: Structuring Your Code for TDD Without Adding Unnecessary Complexity

Mon, 15 Dec 2025 10:08:49 +0200

I. Introduction

Go is a minimalist language, but this simplicity can sometimes make developers feel like something is “missing” — especially when dealing with more advanced architectures, Test-Driven Development, or the need to mock dependencies. Developers coming from Java, C#, or Python often ask the same questions:

Should I turn all my functions into structs + interfaces to test them?
How should I organize my packages to keep them modular and testable?
Where should interfaces live — in the provider or the consumer?
How do I isolate a package that only exports functions?
How does Go automatically detect signature changes?

II. Go’s Model: Simple, Modular, but Different

Unlike Java or C#, Go does not rely on inheritance, classes, or heavy dependency injection frameworks.