Microservices has become an increasingly popular subject over the last few years. As with any new architectural concept, there is plenty of room for misunderstanding. Even the term microservices is confusing. Newcomers are often unsure about the appropriate size of a microservice (hint: it's not actually about the size of the code base) and can get stuck on how to get started with this architectural style.

Service-oriented architectures are nothing new. Web services were being promoted by various companies in the 1990s as a solution to large, inflexible code bases. The promise was that web services would provide reusable capabilities that could be easily consumed by your code bases. Technologies such as SOAP and WSDL started gaining adoption, but never seemed to deliver on the ease of use promise. Meanwhile, open source languages such as PHP, Ruby, and Python with frameworks such as Symfony, Rails, and Django made developing monolithic web-centric code bases easier.

Fast forward a couple of decades and we started seeing a renewed interest in services. So, what's changed? For one, with the advent of rich web and mobile applications, every system is now a distributed system. Thanks to the advent of cloud computing, compute and storage resources are cheaper than they've ever been. Containers are changing the way we think about deploying and operating our services. Many consumer services are outgrowing their monolithic code bases, and teams are finding them hard to scale. Microservices can help with many of these challenges.

Microservices aren't a panacea. While they have many benefits (which we'll discuss later), they also introduce some specific challenges. Before deciding to make the move to microservices, it's important to have certain infrastructure and tooling in place. Martin Fowler has written about Microservices Prerequisites (https://martinfowler.com/bliki/MicroservicePrerequisites.html), as has Phil Calcado (http://philcalcado.com/2017/06/11/calcados_microservices_prerequisites.html). I won't repeat what others have written; instead, I will just say that it pays to have a certain amount of automation and monitoring in place before you start developing microservices. Your teams should be comfortable sharing on-call duties and you should have a system for managing alerts and escalations, such as PagerDuty (http://pagerduty.com/).

The various benefits of microservices are as discussed in the next sections.

In a monolithic code base, scaling is an all-or-nothing approach. Microservices make it easier to scale separate parts of your application based on their own needs. For example, you might have a particular part of your application that is in the critical path of every user request (that is, authentication/authorization services), whereas other parts are only used by a subset of your users (that is, search or messaging). Different traffic patterns will translate to different scaling needs and different techniques that should be used to scale a service. A service that requires a read for every request from a user should use a data store that makes reads cheap. Services that do not need to provide strongly consistent results can take advantage of extensive caching. 

When teams of engineers are working on separate code bases with separate deployments, they are able to make a lot of decisions independently, without the need to coordinate with other teams in the organization. This means that engineers are free to commit code, design their own code review processes, and deploy to production without always needing to coordinate. In a monolith, it's not uncommon for engineers to have to get their changes into a queue that is then deployed at a set time with changes from other teams. If something goes wrong (poison deploys are one of the most common causes of outages), then the whole change set gets rolled back, delaying work by multiple teams. Microservices help you avoid this by allowing teams to move with more autonomy.

When a monolith fails, it tends to fail completely. A database is unavailable, and then the application tries to use stale connections in a connection pool, eventually the threads or processes serving requests lock up, and users are left with a white screen of death or a inoperable mobile application. Microservices allow you to decide on a case-by-case basis how a failure in a particular part of your application should be treated. If your service cannot reach a database, perhaps it's better to return a stale cache, or an empty response. If your service has to throw up its hands and start returning HTTP 503 responses, upstream services can respond by applying back pressure, allowing the service to catch up. Microservices give you much more freedom to isolate failures in your system, resulting in a happier experience for your users.

This book will serve as a handy reference for many of the subjects that will come up as you develop microservices. We'll start with recipes that will help you make the transition from a monolith to a suite of microservices. Subsequent chapters will address specific areas or challenges that come up when choosing how best to architect and manage your microservices. Recipes that cover code will include working, simple, tested examples that you can use in your own applications. My hope is that this book will help you think about, plan, and execute the development of microservice-based applications. Enjoy!