Spring Microservices in Action

These three critical roles have an important impact on the successful foundation of microservices:

The Architect: The guy who draws to the big picture.
The Software Developer: The guy writes the code.
The DevOps engineer: The guy makes a decision about deploying and managing services. WatchWords: consistency and repeatability.

3.1 The architect's story: Designing the microservice architecture

An architect focuses on a solution model of the business problem. When building a microservices, an architect should consider three key tasks:

Decomposing the business problem
The granularity of the established services
Defining the service interfaces

3.1.1 Decomposing the Business Problem

People often break down problems into essential parts. It's actually pretty much the same in a microservices architecture. The architect's role is to break the business problem into chunks that represent discrete domains of activity. These chunks encapsulate the business rules and the data logic associated with a particular part of the business domain.

A guideline for decomposing a business problem into microservice candidates:

Pay attention to the nouns you use to describe the business problem. Repeatedly using the same names is a good indicator.
Examine the verbs carefully. Verbs describe movements and represent the natural contours of a problem domain.
Seek for cohesion in the data. Look for related pieces of data in broken-down business problems.

After you've simplified the data model. You can continue with the next step, defining the needed microservices in the application.

3.1.2 Establishing Service Granularity

The purpose is to take these major pieces of functionalities and extract them into independently deployable self-contained units.

The Granularity is essential when building microservices, these are the definitions of how to ensure the right level of granularity:

If a microservice is too coarse-grained, then it ends up with too many responsibilities and maintains data across various large numbers of tables, and it's likely to have too many test cases.
If a service is too fine-grained, it leads to composing business logic becoming complex. Each microservice is only responsible for a crud operation and is heavily dependent on one another service.
Developing a microservices architecture should be approached with an evolutionary mindset, understanding that it won't be perfect the first time. It's better to be coarse-grained than fined-grained at the start.

3.1.3 Defining Service Interface

How your application's microservices will contact with each other. A guideline for defining the service interface:

Use standard HTTP verbs and model your functionalities around these HTTP verbs.
Use URIs and HTTP status codes for intelligible communication.
Define results and responses as JSON.

3.2 When not to use microservice

The following definitions explain why we should not use microservices to develop our application.

Distributed and fine-grained(small) services, meaning microservices add complexity to our application.
It introduces a level of complexity to maintaining and building applications in production. Depending on demand, the count of servers or containers might end up at 50 to 100.
If a request requires complex data aggregation or transformation between multiple data sources, the microservice architecture makes it hard to handle.
So, if you're building an application that meets a small number of demands, Developing a distributed system like microservices might not be worth building.

3.3 Building a Microservice with Spring Boot and Java

I'll try to mention things that are used to develop the project in the book.

Why use JSON for communication: HTTP allows us to use multiple protocols to communicate, but JSON becomes the de facto standard for several reasons.

Why Endpoint names matter: It is significant for establishing clear communication. It should clearly explain the intent of the services. If you notice that your URLs are long and nested, it might be a good sign that your microservice is doing too much than it should be.

HATEOAS: It stands for Hypermedia as the Engine of Application State. Spring HATEOAS allows us to create APIs that follow the HATEOAS principle of displaying the related links for a given resource.

3.4 The DevOps story: Building for the rigors of runtime

Developing the microservices is considered to be an easy part compared to keeping them alive. Distributed independently running containers introduce various failure points. These four guidelines should always be kept in mind when developing microservices:

Microservices should be independently deployable for multiple instances of the service with a single software artifact.
Microservices should be configurable without any human intervention.
Instances of microservices should be transparent to the client. The client should interact with a service via the discovery agent without knowing the exact location of a service.
A microservice should inform its health. In the real scenario, an instance may fail, and Discovery agents may need to route traffic around a failed service instance. Spring Boot Actuator is used to display the health of each microservices.

these four principles should be addressed into a standard set of lifecycle events that occur each time a microservice is built and deployed to an environment.

3.4.1 Service assembly: Packing and deploying your service

A microservice should be packageable and installable as a single artifact within all its dependencies. It needs to guarantee repeatability and consistency.

3.4.2 Service bootstrapping: Managing configuration of your microservices

Environment-specific configuration code needs to be separated from run-time code. Service bootstrapping occurs when the microservice starts and is required to load its application configuration information. Ideally, microservice can be configured via a centralized configuration service and/or properties file such as YAML.

3.4.3 Service registration and discovery: How clients communicate with your Microservice

A microservice's relationship with the client should be transparent and loosely coupled. In a cloud-based environment, a service might go up and tear down quickly with an entirely new assigned IP address. Therefore, it’s handy to use the service registration and discovery mechanism

A service registry allows a microservice to register itself and discover other services. It informs the discovery agent with its physical IP address and service logical name.

3.4.4 Microservice's health

Another significant role of service discovery is monitoring the health of each service instance. After registration of the microservice, the service discovery agent continuously checks the health of the service to ensure that the service is available. If it's down, it removes the failing service instances from its pool to prevent failure calls.

One of the simplest ways to create a health check is to expose an endpoint that presents the instance's health status, which can be implemented via the Spring Actuator.

For further information, follow the link.

References

[1]Spring Microservices in Action, 2nd Edition, John Carnell.
https://www.manning.com/books/spring-microservices-in-action-second-edition

[2] Spring Microservices in Action> Reading Notes, Yang(Bruce) Li.
https://medium.com/@yangli907/spring-microservices-in-action-reading-notes-e3e476bdbd78

Notes of Spring Microservices in Action (Chapter 3)