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-premises. To make it easy for 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 Component F. The composition of the platform as a set of components is illustrated as follows:

Figure...

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, replaceable, 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, either using APIs and synchronous services or preferably by sending messages asynchronously. The APIs and message formats used must be stable, well documented, and evolve by following a defined versioning strategy.
• It must be deployed as separate runtime processes. Each instance of a microservice...

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 records 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 (but not always obvious initially) of decomposing an application into a group of autonomous components is that...

This topic will cover the use of 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, Kubernetes, and Istio.

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. Using a tried and tested solution from a design pattern can save a lot of time and increase the quality of the implementation compared to spending time inventing the solution ourselves.

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...

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, an application framework
• Spring Cloud/Netflix OSS, a mix of application framework and ready-to-use services
• Docker, a tool for running containers on a single server
• Kubernetes, a container orchestrator that manages a cluster of servers that run containers
• Istio, a service mesh implementation

The following table maps the design patterns we will need to handle these challenges, along with the corresponding open source tool that will be used in this book to implement the design patterns:

To be successful when it comes to implementing a microservice architecture, there are a number of related areas to consider as well. I will not cover these areas in this book; instead, I’ll just briefly mention them here as follows:

• Importance of DevOps: One of the benefits of a microservice architecture is that it enables shorter delivery times and, in extreme cases, allows continuous delivery of new versions. To be able to deliver that fast, you need to establish an organization where dev and ops work together under the mantra you built it, you run it. This means that developers are no longer allowed to simply pass new versions of the software over to the operations team. Instead, the dev and ops organizations need to work much more closely together, organized into teams that have full responsibility for the end-to-end life cycle of one microservice (or a group of related microservices). Besides the organizational part of dev/ops...

In this introductory chapter, I described my own way into microservices and delved into a bit of their history. We defined what a microservice is – a kind of autonomous distributed component with some specific requirements. We also went through both the good and challenging aspects of microservice-based architecture.

To handle these challenges, we defined a set of design patterns and briefly mapped the capabilities of open source products such as Spring Boot, Spring Cloud, Kubernetes, and Istio to the design patterns.

You’re eager to develop your first microservice now, right? In the next chapter, you will be introduced to Spring Boot and complementary open source tools that we will use to develop our first microservices.

Join our community on Discord

Join our community’s Discord space for discussion with the author and other readers:

https://packt.link/SpringBoot3e