liveBook · Manning

Microservice architecture

As explained in Think Like a CTO

A microservices architecture structures a system as independently deployable services that are narrowly scoped and communicate through defined interfaces.

Microservice architecture divides an enterprise system into small applications, each with a narrow responsibility. Services interact through an API, service bus, or message queue. A strong service has its own data store, execution environment, and release cycle, so it can change without requiring the rest of the system to be released with it. section 8.6

The appeal is lower change risk and the freedom to choose tools suited to each service’s role. Contrast this with a tightly coupled monolith: even a small library upgrade can have unintended effects elsewhere. The choice is not absolute. Enterprises may combine both approaches, and a monolith can still suit a proof of concept. section 8.6 section 8.9

Replacing a legacy language incrementally

If a legacy language needs replacing, look for areas that can be refactored into services. Carving out those areas can avoid a complete rewrite. First weigh the wider technology landscape, including the recruitment market; unfamiliarity with a language alone is not a reason to replace it. section 8.8.1

Table 8.4 Microservices vs. monolithic checklist (view table figure)

Single code base, with no internal libraries.

Yes / No

Single database that drives all systems.

Yes / No

An outage causes everything to stop delivering.

Yes / No

Single-server architecture.

Yes / No

Upgrading software requires a planned outage.

Yes / No

Use the checklist to assess how monolithic the current system is. Three or more yes answers point toward a monolithic architecture; the questions test shared code and data, outage scope, server structure, and upgrade downtime. section 8.6

How Think Like a CTO covers it

How deep it goes
Defines service scope, communication, and independence, then offers a monolith checklist rather than implementation instructions.
Examples
Illustrates risk through a tightly coupled library upgrade and incremental migration through refactoring parts of a legacy system.
What you can do after
Evaluate/understand it by checking monolith characteristics and identifying legacy areas that could be extracted without a complete rewrite.
How it connects
Connects microservices to monolithic architecture, APIs, service buses, message queues, and legacy-language replacement.

Also explained in

Compare how 14 books explain microservice architecture →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a CTO. The section links point to the parts of the book it draws on.