Preface
When I visit a city, if I have time, I like to wander around by myself, exploring, without looking at a map. It’s a privilege to work in an industry where I get to experience this feeling—the impulse to discover, to chart new territory, is irresistible.
Exploration isn’t limited to physical spaces. It’s also a privilege to work as a software developer and explore mental spaces. Isn’t it fascinating that we can define simple rules that create immense spaces for us to explore? Often, we end up in trouble—we’re lost. But at other times, we discover a trail of conceptual breadcrumbs and use them to construct a map. It’s ridiculous how much fun this is!
When we find and explore something interesting, like microservices, we should draw a map so others can follow and explore further. This book is the map of my journey over the last six years—all the mistakes, revisions, theories, and victories of building microservice systems for production. It isn’t a chronological journal. Instead, I’ve organized my discoveries and distilled them into rules of thumb that others can use. Building a map is hard work, and there are probably better ways to do it, but I’ve found the conceptual structures in this book useful in my own work, and I hope you will, too.
But concepts are useless without practice. You can’t understand how to build software in a new way, without building software in a new way. This book uses case studies to help you gain intuitive knowledge quickly. There’s such as thing as knowledge that you have but don’t “know.” The neural network of your brain is better at learning by example than by study; and the craft of software development, like all crafts, is best learned this way. The discrete knowledge in this book—the abstract concepts, the classifications and definitions—is a pale shadow of the skills you’ll eventually master. Taking inspiration from Taoist philosophy, this book can only show you the way: you must walk it yourself to truly learn. And although the map isn’t the territory, having it is definitely better than being lost.
Microservices are hyped, but they aren’t hype. I see them as a natural evolution of the quest for software components that actually work. Good empirical, psychological, and mathematical arguments can be made to support the view that microservices are a better way to build large software systems with large teams. Many people are exploring the idea of microservices, which is wonderful. This area will take many years to map fully. We should do so enthusiastically while remembering that this is just another small step on the road to better software. The topic shouldn’t be dismissed because there are pitfalls or insufficient tools, or because the fundamental ideas are old. Nor should we be afraid to call out the failures of older approaches. I don’t hold back in my criticism of the monolithic architecture, though I’ll never build a monolith again. But I also don’t think microservices are free of failings. They certainly have them, and those issues bring real trade-offs and downsides that you must consider carefully. I’ve also highlighted these in the text.
Enjoy this book, and enjoy building microservices. They’ve renewed my faith in our collective ability to get things done and to make a better work/life balance possible. Delivering software shouldn’t be about weekend heroics; the process should be calm and deliberate, yet fast and effective, and finished at 6 p.m. on Friday.