Spring Cloud Netflix OSS + Spring Boot + MicroServices Architecture

In this blog we will learn about MicroServices Architecture with Spring Cloud Netfix OSS patterns like Intelligent Routing (Zuul), Discovery (Eureka), Circuit Breaker (Hystrix) and Client Side Load Balancing (Ribbon) through Spring Boot autoconfiguration feature.

Why MicroServices?

Before discussing about MicroServices, let’s see the architecture that used to before MicroServices i.e. the Monolithic Architecture – its similar to a big container wherein all the software components of an application are integtated together and tightly packaged.

The challenges of Monolithic Architecture

1. Inflexible – Monolithic applications cannot be built using different technologies
2. Unreliable – Even if one feature of the system does not work, then the entire system does not work
3. Unscalable – Applications cannot be scaled easily since each time the application needs to be updated, the complete system has to be rebuilt
4. Blocks Continous Development – Many features of the applications cannot be built and deployed at the same time
5. Slow Development – Development in monolithic applications take lot of time to be built since each and every feature has to be built one after the other
6. Not Fit For Complex Applications – Features of complex applications have tightly coupled dependencies

Advantages Of MicroServices

Advantage	Description
Independent Development	All microservices can be easily developed based on their individual functionality
Independent Deployment	Based on their services, they can be individually deployed in any application
Fault Isolation	Even if one service of the application does not work, the system still continues to function
Mixed Technology Stack	Different languages and technologies can be used to build different services of the same application
Granular Scaling	Individual components can scale as per need, there is no need to scale all components together
Loose Coupling	Application build from collaboration services or processes, so any process change without effecting another processes.
Tight Cohesion	An individual service or process that deals with a single view of data.

What are the pros and cons of Microservice Architecture?

Pros of Microservice Architecture	Cons of Microservice Architecture
Freedom to use different technologies	Increases troubleshooting challenges
Each microservices focuses on single capability	Increases delay due to remote calls
Supports individual deployable units	Increased efforts for configuration and other operations
Allow frequent software releases	Difficult to maintain transaction safety
Ensures security of each service	Tough to track data across various boundaries
Mulitple services are parallelly developed and deployed	Difficult to code between services

MicroServices Features/Characteristics

1. Decoupling – Services within a system are largely decoupled. So the application as a whole can be easily built, altered, and scaled
2. Componentization – MicroServices are treated as independent components that can be easily replaced and upgraded
3. Business Capabilities – MicroServices are very simple and focus on a single capability
4. Autonomy – Developers and teams can work independently of each other, thus increasing speed
5. Continous Delivery – Allows frequent releases of software, through systematic automation of software creation, testing, and approval
6. Responsibility – MicroServices do not focus on applications as projects. Instead, they treat applications as products for which they are responsible
7. Decentralized Governance – The focus is on using the right tool for the right job. That means there is no standardized pattern or any technology pattern. Developers have the freedom to choose the best useful tools to solve their problems
8. Agility – MicroServices support agile development. Any new feature can be quickly developed and discarded again

Best Practices to Design the MicroServices

1. Separate data store for each MicroService
2. Keep code at a similar level of maturity
3. Separate build for each MicroService
4. Deploy into Containers
5. Treat servers as stateless

1) Should API Gateway be state-full while other microservices are stateless?

Yes, As in 12 Factor App guide lines all the services should be stateless.

2) If so, how should the user session data be shared between API Gateway and microservices?

Your API should be stateless therefore do not share the session state to the microservices. The recommended approach is to set up a Redis cache to store session data.

Companies using MicroServices Architecture/Patterns

Following companies are using MicroServices patterns.

What is the difference between Monolithic, SOA and Microservices Architecture?

Monolithic Architecture is similar to a big container wherein all the software components of an application are assembled together and tightly packaged.

A Service-Oriented Architecture is a collection of services which communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.

Microservice Architecture is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

Principles for Microservice Design: IDEALS rather than SOLID

In simple words, for object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the IDEALS principles.

IDEALS Principles

• Interface segregation
• Deployability (is on you)
• Event-driven
• Availability over consistency
• Loose coupling
• Single responsibility

Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.

Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.

Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they’re okay with eventual consistency.

Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.

Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality. For example each microservice maintains its own database and no other service should access the other service’s database directly.

SOLID Principles

• Single-responsiblity Principle
• Open-closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Single responsibility states that a class should have one and only one reason to change, meaning that a class should have only one job.

Open for extension, closed for modification states that objects or entities should be open for extension but closed for modification.

Liskov substitution reuse via inheritance is dangerous. This means that every subclass or derived class should be substitutable for their base or parent class.

Interface segregation states that a client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

Dependency Inversion principle allows for decoupling. It states that Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

MicroServices Architecture

High level MicroServices Architecture using Netflix Components as below

Spring Boot MicroServices Architecture – Implementation Steps

1. Setup new service by using Spring Boot
2. Expose resources via a RestController
3. Consume other MicroService services using RestTemplate
4. Each MicroService has certain specific purpose, and they interact with each other to perform a required functionality.
5. Generally MicroServices are installed in multiple Nodes, and each MicroService may have multiple instances. This is to provide Horizontal scalability.
6. The problem due to this is how one MicroService can detect another MicroService, and the system where it runs, and on which all instances a MicroService runs.
This is termed as Service Registry and Discovery, there is a tool named Eureka for Service Discovery.

How does Microservice Architecture work?

A microservice architecture has the following components:

• Clients – Different users from various devices send requests.
• Identity Providers – Authenticates user or clients identities and issues security tokens.
• API Gateway – Handles client requests.
• Static Content – Houses all the content of the system.
• Management –  Balances services on nodes and identifies failures.
• Service Discovery – A guide to find the route of communication between microservices.
• Content Delivery Networks – Distributed network of proxy servers and their data centers.
• Remote Service – Enables the remote access information that resides on a network of IT devices.

MicroServices Architecture: Why Service Registry and Discovery Required?

Here is an example without using Eureka component. Problem – How one MicroService can detect another MicroService, and the system where it runs, and on which all instances a MicroService runs?

MicroServices Architecture: How Services Registry/Discovery works?

Eureka Client and Eureka Server(provided by Spring Cloud Netflix OSS) are used for Service Registry & Discovery

“Eureka is a REST (Representational State Transfer) based service that is primarily  used in the AWS cloud for locating services for the purpose of load balancing and  failover of middle-tier servers.”

MicroServices Architecture: Advantages of Service Registry/Discovery

1. Scalable – number of instances on which a MicroService can change, dynamically.
2. Auto-scaling – Number of instances can change auto-scaling, failures, and Software/Hardware upgrades.

What is Domain Driven Design?

What is Cohesion?

The degree to which the elements inside a module belong together is said to be cohesion.

What is Coupling?

The measure of the strength of the dependencies between components is said to be coupling. A good design is always said to have High Cohesion and Low Coupling.

MicroServices Architecture: Spring Cloud Netflix OSS Tools

MicroServices Architecture: Eureka server with Spring Cloud configuration

Below maven dependency needs to be added in Maven File (pom.xml)

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

MicroServices Architecture: Eureka server dashboard

appliation.properties

spring.application.name= ${springboot.app.name:eureka-serviceregistry}
server.port = ${server-port:8761}
eureka.instance.hostname= ${springboot.app.name:eureka-serviceregistry}
eureka.client.registerWithEureka= false
eureka.client.fetchRegistry= false
eureka.client.serviceUrl.defaultZone: http://${registry.host:localhost}:${server.port}/eureka/

MicroServices Architecture: Eureka client configuration

Below maven dependency needs to be added in Maven File (pom.xml)

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

MicroServices Architecture: Run the client application

Application logs

MicroServices Architecture: Show all registered instances

MicroServices Architecture: Consuming a service registered on Eureka

MicroServices Architecture: Load balancing

What are the challenges you face while working Microservice Architectures?

Developing a number of smaller microservices sounds easy, but the challenges often faced while developing them are as follows.

• Automate the Components: Difficult to automate because there are a number of smaller components. So for each component, we have to follow the stages of  Build, Deploy and, Monitor.
• Perceptibility: Maintaining a large number of components together becomes difficult to deploy, maintain, monitor and identify problems. It requires great perceptibility around all the components.
• Configuration Management: Maintaining the configurations for the components across the various environments becomes tough sometimes.
• Debugging: Difficult to find out each and every service for an error. It is essential to maintain centralized logging and dashboards to debug problems.

MicroServices Architecture: Spring Cloud Working Example

You may click on below url for Spring Cloud Netflix OSS Load Balancing example

Spring Cloud Netflix OSS + Netflix Eureka + Netflix Ribbon Client Side Load Balancer Example

Kindly let me know in case any issue 🙂