liveBook · Manning

Monolithic architecture

As explained in Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform

An application whose functionality is implemented in a single large service rather than multiple independently deployable services.

A monolith runs an entire application in a single process. Instead of dividing its features among many small services, it keeps them in one large service. That can be a practical choice: a monolith is simpler to build initially and requires fewer technical and architectural skills than a microservices application. section 1.7 section 1.16

Choose the architecture for the application you need to run and change:

  • Use a monolith to test an early product idea, make a throwaway prototype, or serve an application that will remain small and stable. section 1.7
  • Plan for growth if the product is likely to evolve. A useful prototype can become difficult to discard, while converting an established monolith may be a large job. section 1.7 section 12.6
  • Do not treat monolith and microservices as the only two choices. An application can combine a monolith with helper services or use services of different sizes. section 1.13

The main trade-off is where complexity lands. A monolith is easier to start, but keeping its parts distinct becomes harder as they grow and tangle. Microservices give parts harder boundaries, at the cost of a more complicated distributed application. A monolith also commits the application to one technology stack, whereas separate services can use different stacks. section 1.10.4 section 1.4 section 1.9

A video-streaming application

A video-streaming application can be pictured either as one process containing its features or as several small processes working together. The comparison is about how those features are organized, not whether users receive a useful application. section 1.7 section 1.16

Figure 1.7 It’s not just monolith versus microservices: there’s actually a spectrum of possibilities.

Use the architecture spectrum to consider intermediate arrangements rather than forcing a choice between one monolith and only small services. section 1.13

If a running monolith needs to become a microservices application, avoid a single large rewrite. Extract small pieces, test thoroughly, and keep the product working while features and bug fixes continue. Repeat as needed; the details and duration depend on the existing application. section 12.6 section 12.6.8

How Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform covers it

How deep it goes
Defines a monolith as a single-process application, weighs its trade-offs, and outlines iterative conversion without prescribing a universal migration plan.
Examples
Compares monolithic and microservices versions of a video-streaming application and considers prototypes, small applications, and hybrid arrangements.
What it assumes
Introduces the monolith with a single-process definition and notes that building one requires fewer technical and architectural skills than building microservices.
What you can do after
Evaluate/understand when a monolith fits and why migration should proceed through small, tested changes.
How it connects
Connects monolithic architecture to microservices, distributed applications, technology stacks, and iterative refactoring.

Also explained in

Compare how 8 books explain monolithic architecture →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Bootstrapping Microservices, Second Edition: With Docker, Kubernetes, GitHub Actions, and Terraform. The section links point to the parts of the book it draws on.