Microservice Architecture

Chapter 8. Epilogue

The best software architecture “knows” what changes often and makes that easy.

Paul Clements, author of Software Architecture in Practice

While this book bears the title microservice architecture, you have likely noticed that the central theme has been change. Specifically, we’ve focused on designing systems that make change easier.

When we work in a business environment where the goals and processes change frequently, our software architecture needs to reflect that. When it doesn’t, the gap between business practice and system functionality widens and we call that “technical debt.” On the other hand, when you engineer your system to support change safely—to allow replacing small interoperable parts without having to rebuild the entire system—then you’re making change easier and avoiding that widening gap between practice and code.

Microservices are the small interoperable parts and microservice architecture is the engineering practice that can make change easier. The process of working along the path from your current architectural state and the desired future state where you can harmonize the speed of change with the need for system safety is what we call the microservices way.

Another key point to keep in mind is that there is no “all done” moment, that instant when you’ll have everything in place, just the way you like it all running along without the need for modification. This need for constant change is not a “bug” in the way your software is engineered ...