Download code from GitHub
Introduction to Microservices
This book does not blindly praise microservices. Instead, it's about how we can use their benefits while being able to handle the challenges of building scalable, resilient, and manageable microservices.
As an introduction to this book, the following topics will be covered in this chapter:
- How I learned about microservices and what experience I have of their benefits and challenges
- What is a microservice-based architecture?
- Challenges with microservices
- Design patterns for handling challenges
- Software enablers that can help us handle these challenges
- Other important considerations that aren't covered in this book
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-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 ...
Defining a microservice
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...
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 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...
Design patterns for microservices
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
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
- 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:
| Design Pattern | Spring Boot | Spring Cloud | Kubernetes | Istio |
|
Service discovery |
Netflix Eureka and Netflix Ribbon | Kubernetes kube-proxy and service resources | ||
|
Edge server |
Spring Cloud and Spring Security OAuth | Kubernetes Ingress controller | Istio ingress gateway | |
|
Reactive microservices |
Spring Reactor and Spring WebFlux | |||
|
Central configuration |
Spring Config Server | Kubernetes ConfigMaps... |
Technical requirements
This chapter does not contain any source code that can be downloaded, nor does it require any tools to be installed.
Learning about Spring Boot
Spring Boot, and the Spring Framework that Spring Boot is based on, is a great framework for developing microservices in Java.
When the Spring Framework was released in v1.0 back in 2004, it was released in order to fix the overly complex J2EE standard (short for Java 2 Platforms, Enterprise Edition) with its infamous and heavyweight deployment descriptors. Spring Framework provided a much more lightweight development model based on the concept of dependency injection (DI). Spring Framework also used far more lightweight XML configuration files compared to the deployment descriptors in J2EE.
- Standard deployment descriptors, describing the configuration in a standardized way
- Vendor-specific deployment descriptors...
