Reactive Microservices Architecture

Chapter 3. Microservices Come in Systems

One actor is no actor. Actors come in systems.

Carl Hewitt

No man is an island, Entire of itself, Every man is a piece of the continent, A part of the main.

John Donne

Now we have a pretty good understanding of what characterizes a Reactive Microservice. However, learning from Carl Hewitt: one Microservice is no Microservice—they come in systems. Like humans they act autonomously and therefore need to communicate and collaborate with others to solve problems—and as with humans, it is in collaboration that both the most interesting opportunities and challenging problems arise.

Individual Microservices are comparatively easy to design and implement—what is hard in a Microservices-based Architecture is all the things around them: discovery, coordination, security, replication, data consistency, failover, deployment, and integration with other systems, just to name a few.

Systems Need to Exploit Reality

If you cannot solve a problem without programming. You cannot solve a problem with programming.

Klang’s Conjecture by Viktor Klang

One of the major benefits of Microservices-based Architecture is that it gives you a set of tools to exploit reality, to create systems that closely mimic how the world works, including all its constraints and opportunities.

We have already discussed—highlighted by Conway’s Law—how Microservices development is often a better fit to how your engineering organization and departments already work.

Another subtle, ...