Applications

Applications#

Application architecture is the style chosen above the infrastructure, the structure of the code that runs on the infrastructure this section builds. The full profiles live under Types of Architectures; this page places them in cloud context and traces how they got here.

The cloud reshapes the trade-offs rather than the styles themselves. Managed brokers make event-driven cheap, functions make serverless viable, and a managed datastore makes a monolith’s single store nothing to operate, while egress and cross-zone charges push back on chatty service meshes. The style a target runs also exposes where the seams are and how wide one foothold reaches.

        flowchart LR
  M[Monolith] --> S[SOA]
  S --> MS[Microservices]
  MS --> ED["Event-driven<br/>+ serverless"]
  ED --> MM["Modular monolith<br/>reassessment"]

Evolution#

Each shift was driven by a constraint that changed, not by fashion. The monolith dominated while a single team shipped a single deployable against one database, simple to build and operate until the codebase and the org outgrew one release train.

SOA answered enterprise integration. Coarse services sat behind an enterprise service bus with a canonical schema, promising reuse across the business. The bus became the bottleneck and the governance grew heavy, so the reuse rarely paid off.

Microservices arrived once containers, DevOps, and cloud made a small independently deployable service cheap to run. Smart endpoints and dumb pipes replaced the bus, teams shipped on their own cadence, and the bill came due as distributed-system complexity. Event-driven and serverless pushed further, coupling through asynchronous events and billing per invocation on managed brokers and functions.

The 2020s brought a reassessment. The modular monolith reclaims one deployable with hard internal module boundaries, for the many teams that paid the microservices tax without the scale that justifies it.

Era

Driver

Style

1995 to 2005

One team, one deployable

Monolith

2000s

Enterprise reuse and integration

SOA

2010 to 2015

Containers and DevOps make small services cheap

Microservices

2015 onward

Managed brokers and functions

Event-driven and serverless

2020s

The microservices tax without the scale

Modular monolith

Styles#

The common styles and the one-line reason to reach for each. Follow the link for the full profile, its strengths, costs, and the point at which it earns its keep.

Style

In one line

Monolith

One deployable, one datastore. The right default until scale or team size forces a split.

SOA

Coarse services behind a shared bus. Enterprise reuse paid for with a central bottleneck.

Microservices

Small, independently deployable services. Team autonomy bought with distributed-system complexity.

Event-Driven

Components react to events through a broker. Loose coupling, harder to reason about flow.

Serverless

Functions and managed services billed per use. No idle cost, cold starts and lock-in.

Layered

Presentation, logic, and data in horizontal tiers. Familiar, prone to leaky layers.

Hexagonal

Domain core wrapped by ports and adapters. Testable, swappable edges, more upfront structure.

Peer-to-Peer

Equal nodes, no central coordinator. Resilient and scalable, hard to secure and observe.

Pipeline

Data flows through staged transforms. Clear for processing, awkward for interactive work.

Cloud#

The cloud’s primitives reward some styles and tax others. The operator picks the structure the platform’s managed services and cost model actually favor, then maps the running style onto the Components it is built from.

  • Microservices, affordable once a managed Kubernetes runs the fleet.

  • Serverless, viable where functions and managed events remove the idle cost.

  • Event-driven, cheap on a managed broker, the default for async fan-out.

  • Monolith, easy again when a managed database operates the single store.

References#

Contents