Now that you've had some experience breaking a monolith into microservices, you've seen that many of the challenges exist outside the monolith or service code bases themselves. Exposing your service to the internet, controlling routing, and building in resiliency are all concerns that can be addressed by what are commonly called edge services. These are services that exist at the edge of our architecture, generally handling requests from the public internet. Luckily, because many of these challenges are so common, open source projects exist to handle most of them for us. We'll use a lot of great open source software in this chapter.

With the recipes in this chapter, you'll learn how to use open source software to expose your services to the public internet, control routing, extend your service's functionality, and handle a number of common...

In Chapter 1, Breaking the Monolith, we modified a monolith code base to provide easy routing to our microservices. This approach works and requires little effort, making it an ideal intermediary step. Eventually, your monolith will become a bottleneck in the development and resiliency of your architecture. As you try to scale your service and build more microservices, your monolith will need to be updated and deployed every time you make an API change to your service. Additionally, your monolith will have to handle connections to your services and is probably not well-configured to handle edge concerns such as load shedding or circuit breaking. In the Routing requests to services recipe of Chapter 1, Breaking the Monolith, we introduced the concept of edge proxies. Using an edge proxy server to expose your service...

When you start developing microservices, it's common to embed a certain amount of boilerplate into each service. Logging, metrics, and configuration are all functionalities that are commonly copied from service to service, resulting in a large amount of boilerplate and copied and pasted code. As your architecture grows and you develop more services, this kind of setup becomes harder and harder to maintain. The usual result is that you end up with a bunch of different ways of doing logging, metrics, service discovery, and so on, which results in systems that are hard to debug and maintain. Changing something as simple as a metrics namespace or adding a feature to your service discovery clients can require the coordination of multiple teams and code bases. More realistically, your microservices architecture will continue to grow with inconsistent...

As we've seen in other recipes, microservices should provide a specific business capability and should be designed around one or more domain concepts, surrounded by a bounded context. This approach to designing service boundaries works well to guide you toward simple, independently-scalable services that can be managed and deployed by a single team dedicated to a certain area of your application or business. 

When designing user interfaces, clients often aggregate related but distinct entities from various backend microservices. In our fictional messaging application, for instance, the screen that shows an actual message might have information from a message service, a media service, a likes service, a comments service, and so on. All of this information can be cumbersome to collect and can result in a large number...

Failures in a complex system can be hard to diagnose. Often, the symptom can appear far away from the cause. Users might start experiencing higher-than-normal error rates during login because of some downstream service that manages profile pictures or something else tangentially related to user profiles. An error in one service can often propagate needlessly to a user request and adversely impact user experience and therefore trust in your application. Additionally, a failing service can have cascading effects, turning a small system outage into a high-severity, customer-impacting incident. It's important when designing microservices to consider failure isolation and decide how you want to handle different failure scenarios.

A number of patterns can be used to improve the resiliency of distributed systems. Circuit breakers are a common...

In addition to techniques such as circuit breaking, rate limiting can be an effective way to prevent cascading failures in a distributed system. Rate limiting can be effective at preventing spam, protecting against Denial of Service (DoS) attacks, and protecting parts of a system from becoming overloaded by too many simultaneous requests. Typically implemented as either a global or per-client limit, rate limiting is usually part of a proxy or load balancer. In this recipe, we'll use NGINX, a popular open source load balancer, web server, and reverse proxy.

Most rate-limiting implementations use the leaky-bucket algorithm—an algorithm that originated in computer network switches and telecommunications networks. As the name suggests, the leaky-bucket algorithm is based on the metaphor of a bucket with a small leak in it that controls a constant rate. Water...

As web services' frameworks and standards evolve, the amount of boilerplate or shared application concerns is reduced. This is because, collectively, we figure out what parts of our applications are universal and therefore shouldn't need to be re-implemented by every programmer or team. When people first started networking computers, programmers writing network-aware applications had to worry about a lot of low-level details that are now abstracted out by the operating system's networking stack. Similarly, there are certain universal concerns that all microservices share. Frameworks such as Twitter's Finagle wrap all network calls in a circuit breaker, increasing fault tolerance and isolating failures in systems. Finagle and Spring Boot, the Java framework we've been using for most of these recipes, both support exposing...