No installations are required for this chapter. However, you may be interested in taking a look at the C4 model conventions, https://c4model.com, since the illustrations in this chapter are inspired by the C4 model.

This chapter does not contain any source code.

When I first learned about the concept of microservices back in 2014, I realized that I had been developing microservices (well, kind of) for a number of years without knowing it was microservices I was dealing with. I was involved in a project that started in 2009 where we developed a platform based on a set of separated features. The platform was delivered to a number of customers that deployed it on-premise. To make it easy for the customers to pick and choose what features they wanted to use from the platform, each feature was developed as an autonomous software component; that is, it had its own persistent data and only communicated with other components using well-defined APIs.

Since I can't discuss specific features in this project's platform, I have generalized the names of the components, which are labeled from Component A ...

To me, a microservice architecture is about splitting up monolithic applications into smaller components, which achieves two major goals:

• Faster development, enabling continuous deployments
• Easier to scale, manually or automatically

A microservice is essentially an autonomous software component that is independently upgradeable and scalable. To be able to act as an autonomous component, it must fulfill certain criteria as follows: 

• It must conform to a shared-nothing architecture; that is, microservices don't share data in databases with each other!
• It must only communicate through well-defined interfaces, for example, using synchronous services or preferably by sending messages to each other using APIs and message formats that are stable, well-documented, and evolve by following a defined versioning strategy.
• It must be deployed...

In the Challenges with autonomous software components section, we have already seen some of the challenges that autonomous software components can bring (and they all apply to microservices as well) as follows:

• Many small components that use synchronous communication can cause a chain of failure problem, especially under high load.
• Keeping the configuration up to date for many small components can be challenging.
• It's hard to track a request that's being processed and involves many components, for example, when performing root cause analysis, where each component stores log events locally.
• Analyzing the usage of hardware resources on a component level can be challenging as well.
• Manual configuration and management of many small components can become costly and error-prone.

Another downside...

This topic will cover using design patterns to mitigate challenges with microservices, as described in the preceding section. Later in this book, we will see how we can implement these design patterns using Spring Boot, Spring Cloud, and Kubernetes.

The concept of design patterns is actually quite old; it was invented by Christopher Alexander back in 1977. In essence, a design pattern is about describing a reusable solution to a problem when given a specific context.  

The design patterns we will cover are as follows: 

• Service discovery
• Edge server
• Reactive microservices
• Central configuration
• Centralized log analysis
• Distributed tracing
• Circuit Breaker
• Control loop
• Centralized monitoring and alarms

As we've already mentioned, we have a number of very good open-source tools that can help us both meet our expectations of microservices and, most importantly, handle the new challenges that come with them:

• Spring Boot
• Spring Cloud/Netflix OSS
• Docker
• Kubernetes
•  Istio (a service mesh)

The following table maps the design patterns we will need to handle these challenges, along with the corresponding open-source tool that implements the design pattern: