Microservices Architecture

Roncajolo Gerald
Software Architect @ Softway Medical
t/ 06 71 50 61 53
grc@necol.org
Dec. 2025
ressources:
https://microservices.necol.org

What is "Software Architecture"?

"Architecture is about the important stuff. Whatever that is." — Ralph Johnson

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." — Grady Booch

Evolution of Application Architectures

Historical perspective

Mainframe Era

(1960s-1980s)

Characteristics:

  • Centralized processing
  • Single large computer handling all operations
  • Dumb terminals for input/ line printer for output
  • Batch processing dominant
  • Limited user interaction

Client-Server Architecture

(1980s-1990s)

Also called 2-tier architecture

Characteristics:

  • Two-tier architecture
  • Business logic split between client and server
  • Increased processing power on client side
  • Introduction of GUI applications
  • Reduced mainframe dependency

N-Tier Architecture

(1990s-2000s)

Characteristics:

  • Advent of the internet
  • Multiple logical layers
  • Separation of concerns
  • Presentation, business, and data layers
  • Introduction of middleware
  • Component-based development

Service-Oriented Architecture

(2000s-2010s)

Characteristics:

  • Service-based components
  • Enterprise Service Bus (ESB)
  • SOAP/XML dominant
  • Complex orchestration
  • Enterprise-wide services

Microservices Architecture

(2010s-present)

While there is no precise definition of this architectural style, there are certain common characteristics

-Martin Fowler

  1. Componentization via Services (Not libraries)
  2. Organized around Business Capabilities (Not technical layers)
  3. Products not Projects (You build it, you run it)
  4. Smart endpoints and dumb pipes (No ESBs)
  5. Decentralized Governance (Pick the right tool)
  6. Decentralized Data Management (Polyglot persistence)
  7. Infrastructure Automation (CI/CD is mandatory)
  8. Design for Failure (Chaos Monkey)
  9. Evolutionary Design (Replaceable parts)

Componentization via services

  • Components in microservices are primarily implemented as loosely coupled services rather than libraries - independently deployable units of software
  • Services communicate via web service requests or RPCs, unlike libraries which use in-memory function calls

Key benefits:

Independent deployment of individual services
Explicit interfaces reducing unwanted coupling
Better component encapsulation

Main trade-offs:

Performance overhead from remote calls
More complex refactoring across service boundaries

Organized around technical layers ❌

  • Traditional teams split by technical layers (UI, server, database) lead to slow changes and scattered business logic.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

-- Melvin Conway, 1968323

Organized around business capabilities

  • Microservices organize teams around business capabilities instead:

    • Cross-functional teams with all necessary skills
    • Each service owns its full technical stack (UI to database)
    • Team boundaries align with service boundaries

  • Team sizing follows the "Two Pizza Team" rule:

    • Teams range from 6-12 people
    • Each team manages one or multiple services

  • Benefits over traditional approach:

    • Clearer organizational boundaries
    • Better business context retention
    • More natural enforcement of modularity

  • Some teams can be oriented around technical capabilities (e.g. platform teams)

Team organization

Recommended reading to lean more about organizing software development teams

team-topologies

The Monolith Misconception

Monoliths are NOT inherently bad

The Problem: The "Big Ball of Mud"

Common issues:

  • Tightly coupled code
  • Direct database access everywhere
  • No clear boundaries
  • "God objects" and circular dependencies
  • Every change risks breaking the system

This isn't about being a monolith. It's about being poorly structured.

The Modular Monolith

A well-structured monolith with:

  • Clear module boundaries
  • Public interfaces between modules
  • No shared database tables across modules
  • Independent deployability (potentially)

Benefits of Modular Monoliths

  • Simpler deployment - Single artifact, no distributed system complexity
  • Easier debugging - Stack traces, local debugging, no network hops
  • Better performance - In-memory function calls, not HTTP
  • ACID transactions - Real database transactions across modules
  • Lower operational cost - One app to monitor, one database to manage
  • Evolution path - Module boundaries become service boundaries later

"Start with a monolith, extract microservices when you need them."

Monolith vs Microservices

When to use a Monolith:

  • Early-stage products (domain still evolving)
  • Small teams (< 10 developers)
  • Performance-critical paths (low latency required)
  • Strong consistency requirements

When to use Microservices:

  • Multiple independent teams
  • Different scaling requirements per capability
  • Need for technology diversity
  • Organizational autonomy is the goal

Course Agenda

Day 1: Domain Discovery & The Modular Monolith
Creating a well-structured monolith as a foundation

Day 2: Data Decoupling
Handling communication between services synchronously and asynchronously

Day 3: Production Readiness
API Gateway, Circuit Breakers, Monitoring, CI/CD, and more

Architecture isn't about folder structure. It's about the decisions that are hard to change later. Choosing a variable name is design; choosing to split your database is architecture.