Reactive Microsystems - The Evolution of Microservices at Scale PDF
Preview Reactive Microsystems - The Evolution of Microservices at Scale
C o m pli m e nts of Reactive MMiiccrroossyysstteemmss The Evolution of Microservices at Scale Jonas Bonér Reactive Microsystems The Evolution of Microservices at Scale Jonas Bonér BBeeiijjiinngg BBoossttoonn FFaarrnnhhaamm SSeebbaassttooppooll TTookkyyoo Reactive Microsystems by Jonas Bonér Copyright © 2017 Lightbend, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com/safari). For more information, contact our corporate/institutional sales department: 800-998-9938 or [email protected]. Editor: Brian Foster Interior Designer: David Futato Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Octal Publishing Services Illustrator: Rebecca Demarest Proofreader: Matthew Burgoyne August 2017: First Edition Revision History for the First Edition 2017-08-07: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Reactive Microsys‐ tems, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limi‐ tation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsi‐ bility to ensure that your use thereof complies with such licenses and/or rights. 978-1-491-99433-7 [LSI] Table of Contents Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v 1. Essential Traits of an Individual Microservice. . . . . . . . . . . . . . . . . . . . 1 Isolate All the Things 1 Single Responsibility 2 Own Your State, Exclusively 3 Stay Mobile, but Addressable 6 2. Slaying the Monolith. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Don’t Build Microliths 9 3. Microservices Come in Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Embrace Uncertainty 11 We Are Always Looking into the Past 12 The Cost of Maintaining the Illusion of a Single Now 13 Learn to Enjoy the Silence 13 Avoid Needless Consistency 14 4. Events-First Domain-Driven Design. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Focus on What Happens: The Events 17 Think in Terms of Consistency Boundaries 21 Manage Protocol Evolution 25 5. Toward Reactive Microsystems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Embrace Reactive Programming 28 Embrace Reactive Systems 35 Microservices Come as Systems 44 iii 6. Toward Scalable Persistence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Moving Beyond CRUD 49 Event Logging—The Scalable Seamstress 50 Transactions—The Anti-Availability Protocol 59 7. The World Is Going Streaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Three Waves Toward Fast Data 68 Leverage Fast Data in Microservices 68 8. Next Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Further Reading 71 Start Hacking 72 iv | Table of Contents Introduction The Evolution of Scalable Microservices In this report, I will discuss strategies and techniques for building scalable and resilient microservices, working our way through the evolution of a microservices-based system. Beginning with a monolithic application, we will refactor it, briefly land at the antipattern of single instance—not scalable or resilient— microliths (micro monoliths), before quickly moving on, and step by step work our way toward scalable and resilient microservices (microsystems). Along the way, we will look at techniques from reactive systems, reactive programming, event-driven programming, events-first domain-driven design, event sourcing, command query responsibil‐ ity segregation, and more. v We Can’t Make the Horse Faster If I had asked people what they wanted, they would have said faster horses. —Henry Ford1 Today’s applications are deployed to everything from mobile devices to cloud-based clusters running thousands of multicore processors. Users have come to expect millisecond response times (latency) and close to 100 percent uptime. And, by “user,” I mean both humans and machines. Traditional architectures, tools, and products as such simply won’t cut it anymore. We need new solutions that are as dif‐ ferent from monolithic systems as cars are from horses. Figure P-1 sums up some of the changes that we have been through over the past 10 to 15 years. Figure P-1. Some fundamental changes over the past 10 to 15 years To paraphrase Henry Ford’s classic quote: we can’t make the horse faster anymore; we need cars for where we are going. So, it’s time to wake up, time to retire the monolith, and to decom‐ pose the system into manageable, discrete services that can be scaled individually, that can fail, be rolled out, and upgraded in isolation. 1 It’s been debated whether Henry Ford actually said this. He probably didn’t. Regardless, it’s a great quote. vi | Introduction They have had many names over the years (DCOM, CORBA, EJBs, WebServices, etc.). Today, we call them microservices. We, as an industry, have gone full circle again. Fortunately, it is more of an upward spiral as we are getting a little bit better at it every time around. We Need to Learn to Exploit Reality Imagination is the only weapon in the war against reality. —Lewis Carroll, Alice in Wonderland We have been spoiled by the once-believed-almighty monolith— with its single SQL database, in-process address space, and thread- per-request model—for far too long. It’s a fairytale world in which we could assume strong consistency, one single globally consistent “now” where we could comfortably forget our university classes on distributed systems. Knock. Knock. Who’s There? Reality! We have been living in this illusion, far from reality. We will look at microservices, not as tools to scale the organization and the development and release process (even though it’s one of the main reasons for adopting microservices), but from an architecture and design perspective, and put it in its true architectural context: distributed systems. One of the major benefits of microservices-based architecture is that it gives us a set of tools to exploit reality, to create systems that closely mimic how the world works. Don’t Just Drink the Kool-Aid Everyone is talking about microservices in hype-cycle speak; they are reaching the peak of inflated expectations. It is very important to not just drink the Kool-Aid blindly. In computer science, it’s all about trade-offs, and microservices come with a cost. Microservices can do wonders for the development speed, time-to-market, and Continuous Delivery for a large organization, and it can provide a great foundation for building elastic and resilient systems that can Introduction | vii take full advantage of the cloud.2 That said, it also can introduce unnecessary complexity and simply slow you down. In other words, do not apply microservices blindly. Think for yourself. 2 If approached from the perspective of distributed systems, which is the topic of this report. viii | Introduction
The list of books you might like
