Enabling Microservice Success

Part III. Building and Operating

Your approach to lots of aspects of software development and operation will need to change when building and operating a microservice architecture. Mostly, these stem from three key aspects of a microservice architecture.

First, the system is distributed, with almost any request going over the network multiple times. That means latency and intermittent failures are part of normal operation.

Second, pretty much anything you do now needs to be done multiple times, because you have a lot of separate services.

Finally, we can no longer keep a model of the whole system in our heads; it’s too complex. Architectural diagrams are out of date as soon as they are created, because things change regularly, and this complexity also means we don’t really know what we depend on. An outage of a system you’ve never heard of can take you down.¹

For each chapter in this section, we’ll look at how to avoid running into trouble, but also what to do to recover if you find yourself in the mire.

¹ In Leslie Lamport’s words, “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.”