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 or implemented—it’s a feature of a vital, viable information system. While there may be times when things tend to calm down or seem to run fairly quietly, they’re not likely to last very long.
As someone responsible for making sure IT practices keep in alignment with business goals and objectives, you’ll find lots of opportunity for “wins,” but they might look a bit different than you’d expect. For example, a “win” is when you release refactored updates to core services without anyone even noticing. Or you complete a multiyear migration from one data-storage system to another. Or you learn that other teams in the company are now releasing customer-facing applications at a speed not previously thought possible. If you’re lucky, someone will remember that all this was possible because of the work you’ve been doing all along.
As you’ve seen from our examples, you don’t need to transform your organization, culture, and processes all in one “big bang.” There are lots of small moves you can implement as you learn from each attempt and gain experience in the microservices way. And, you’ll need all that experience as you face new challenges to adapt what you’ve built today to meet the unique goals and requirements of the future. Hopefully, the descriptions, models, and guidance we’ve collected here can give you a set of tools you can use to improve your organization’s software system starting today and well into the future.
As we mentioned at the outset, we don’t think it’s important to agree upon a universal definition for the term “microservice.” We don’t even expect the current popularity of the term to last long. However, the principles that make microservices special—things like immutability and modularity, speed and safety, resilience, and agility—are well-known and lasting values. Technology advancements are already occurring as we write this book. The world around us is changing. Concepts such as serverless architectures, automated transport, virtual reality, and adaptive intelligent programs are all generating interest. We can’t predict the future, and any of these technological or social changes could have a profound impact on the industry we share. That may mean that the range and types of tools available in the future may change in profound ways. These potential changes can alter the implementation details and processes you use to meet your goals but the underlying principles will stay the same.
And, even with all the possibilities of rapid change ahead, we think the microservices way of developing software—the harmonic balance of speed and safety at scale—will be valuable to you far into the future. So, when technology, society, and businesses change around you, you can use the way to identify the best of the new principles and patterns that will inevitably emerge from these important changes. That means you have the opportunity to embrace change and more easily adapt to new ways of designing, building, and managing the information systems of the future.
Heraclitus