Developing Reactive Microservices

Foreword

“Everyone” is talking about microservices. It is reaching the peak of inflated expectations, and—as with all hyped technologies—it is easy to dismiss as just one of our industry’s latest fads, one that will die out quicker than it emerged and be soon forgotten. You can already hear some old-timers say that it is not bringing anything new to the table, that it is just SOA (or god forbid, CORBA) all over again, just common sense rebranded—“been there, done that, move on.” These individuals are right—and they are wrong.

Right because the goals of microservices are the same ones that we have pursued in software engineering for decades: isolation, decoupling, composition, integration, maintainability, extensibility, time-to-market, resilience, and scalability.

And wrong because the world of the software engineer is vastly different now than just 10 to 15 years ago. Now we are faced with challenges that are new and scary to most developers, but we have also been given the means to address them.

Today, multicore processors, cloud computing, and mobile devices are the norm, which means that all new systems are distributed systems from day one—a completely different and more challenging world to operate in, a world with lots of new and interesting opportunities. This shift has forced our industry to rethink some of its old “best” practices around system architecture and design.

One example of this is the recent interest in reactive systems and architecture. These systems are defined by the core traits of Responsiveness, Resilience, and Elasticity powered by Asynchronous Message Passing.

Another change is the departure from monolithic architectures toward systems that are decomposed into manageable, discrete, and autonomous services, and scaled individually; these systems can fail, be rolled out, and upgraded in isolation, a design we now call microservices-based.

Traditional architectures, tools, and products simply won’t cut it anymore. We can’t make the proverbial horse faster—we need cars for where we are going. Layering a new shiny tool like microservices on top of our existing software stack and platform, which was made for monoliths, and then expecting us to not have to change the way we think or learn anything new will only set us up for failure.

The good news is that today we have lots of great tools, frameworks, platforms, and architectural patterns that can help us do the right thing, make the right decisions, and set us up for success.

In this practical report, written for the curious Java developer, Markus shows you how you can take the hard-won knowledge of reactive systems (standing on the shoulders of giants like Jim Gray, Pat Helland, Joe Armstrong, and Robert Virding) and make it a solid foundation for your next microservices-based system.

Along the way you will learn how to create autonomous services that can be rolled out and upgraded in isolation, replicated, and migrated at runtime; self-healed; persisted in a scalable and resilient way; integrated with external and legacy systems; communicated with other services over efficient and evolvable asynchronous protocols; and scaled elastically on demand. And you will learn all this through the lens of Lagom, the reactive microservices framework built on Akka and the Play Framework—a most efficient, pragmatic, and fun way of slaying the monolith.

I hope you enjoy the ride. I know I did.

—Jonas Bonér, CTO at Lightbend