Technical requirements

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.

My way into microservices

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 of 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:

Enter microservices

Learning about microservice-based architectures in 2014 made me realize that other projects had also been struggling with similar challenges (partly for other reasons than the ones I described earlier, for example, the large cloud service providers meeting web-scale requirements). Many microservice pioneers had published details of lessons they’d learned. It was very interesting to learn from these lessons.Many of the pioneers initially developed monolithic applications that made them very successful from a business perspective. But over time, these monolithic applications became more and more difficult to maintain and evolve. They also became challenging to scale beyond the capabilities of the largest machines available (also known as vertical scaling). Eventually, the pioneers started to find ways to split monolithic applications into smaller components that could be released and scaled independently of each other. Scaling small components can be done using...

Defining a microservice

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 and well documented and evolve by following a defined versioning strategy.
• It must be deployed as separate runtime processes. Each instance of a microservice runs in a separate runtime process, for example...

Challenges with microservices

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 they form a distributed system. Distributed...

Design patterns for microservices

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 alarms

This list is not intended to be comprehensive; instead, it’...

Software enablers

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:

Other important considerations

To be successful when it comes to implementing a microservice architecture, there are a number of related areas to consider. 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 teams 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 and ops, the teams also need to automate...

Summary

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.