A microservice is a small, loosely coupled, tightly scoped, and self-deployable distributed service. Microservice Architectures is a solution for the problems faced by developers with Monolith architecture based application like each change needs thorough impact analysis and regression testing, not scalable as per demand, innovation challenges, etc.

Why is the software industry moving towards Microservice Architecture?

Monolith applications are typically vast and have few challenges-

  • Code Changes:

It is difficult to make code changes fast and correctly because of complex code and needs impact analysis.

  • Testing:

Each change needs extensive manual testing during a regression test to ensure that change has not broken anything else.

  • Build and Deployment:

For small changes, the whole application needs to be built and deployed.

  • Slow Startup:

Heavy application results in a slow startup because all the things need to initialize and start.

  • Scalability:

Difficult to scale up and down a particular functionality based on demand.  We need to scale the whole application, which requires more resources.  For example, at the time of the festive season or during the sale catalog and checkout services of an e-Commerce website will need more instances to handle the load.

  • Troubleshooting:

Debugging and troubleshooting issues is difficult.

  • Cloud Readiness:

These applications cannot be deployed on the cloud as it is.

How do Microservices solve the above challenges?

  • Small Modules:

It allows you to take a broad application and decompose or break into easily manageable small components with narrowly defined responsibilities, which makes code changes and testing easy for developers.

  • Process or technology Adaption:

By using microservices, new Technology and process adaption becomes easier. You can try new technologies with the microservices which are implementing new functionality.

  • Change Isolation:

Other parts of application remain mostly unaffected by the failure of a single service.

  • DURS:

Each microservice can be independently deployed, updated, replaced, and scaled. Microservice can also scale independently by cloning with more CPU or memory.

New Challenges with Microservices:

  • Configuration Management:

When we break a big monolithic application into many small microservices, it becomes tedious to configure and monitor so many services.

  • Debugging:

Tracking down the service failure is a painful task. You may need to look into multiple services across different components. Centralized Logging and Dashboards are essential to make it easy to debug problems.

  • Automation:

Because there are several smaller components instead of a monolith, you need to automate everything – Builds, Deployment, and Monitoring, etc.

  • Testing:

End to end testing requires a lot of effort because it needs all the dependent services to be up and running.

Implementation technologies for Microservice Architecture-based applications:

Microservices are simpler, developers get more productive, and systems can be scaled quickly and precisely. The implementation part of a Microservice is called “inner architecture”.  Spring-boot can be used to create a microservice which exposes a REST endpoint and encapsulate logic and data persistence. The key concept here is that we need to stick to the interface contracts.

Microservice architecture can be more convenient and straightforward by adding a few more things that we need to manage from outside. For example –

  • managing deployments,
  • communication between microservices,
  • service discovery,
  • health monitoring of all microservices in your application,
  • scaling the number of instances based on demand,
  • debugging the issue in your distributed system

Few technologies can help you achieve all these functionalities. These are known as “outer architecture” and will change the way we build, maintain, and operate our applications. Let’s have a look at these technologies –

Spring Boot:

Microservices implementation is possible using spring boot. It exposes resources using RestController. If one microservice wants to call another microservice, then it can use RestTemplate or Feign Client.

Spring Cloud:

Spring cloud provides many technologies for creating “outer architecture” of a microservice like Service Discovery, Configuration, Monitoring, Client-side load balancing, etc. Below are the few essential technologies –

Declarative REST Client using Feign Client: 

Netflix provides Feign as an abstraction over REST-based calls. Microservices can communicate with each other by using Feign, but developers don’t have to bother about REST internal details.

Why We Use Feign Client?

With RestTemplate, we need to construct a URL for calling one microservice from another microservice. Hence, we need to know the RestTemplate API, which is not part of

the application logic. Microservice developers should only concentrate on business logic. Developers should not need to worry about the REST API. Hence Spring addresses this issue and comes with Feign Client, which works on the declarative principle. We have to create an interface/contract, and then Spring creates the original implementation on the fly by abstracting REST-based service calls from developers. Not only that — if you want to customize the service call, like encoding your request or decoding the response in a Custom Object, do it with Feign in a declarative way.

Client-Side Load Balancer – Ribbon:

Usually, multiple instances of service are running for better load handling and fault tolerance. The Client of such service can decide which instance it needs to call by using client-side load balancing. The Ribbon is a client-side load balancer that gives you a lot of control over the behavior of HTTP and TCP clients. It helps you determine the best available instance of a service. Feign already uses Ribbon.

Service Discovery and Service Registry using Eureka Server and Eureka Client:

Service Discovery means how one service will find another service.

Eureka Server is a spring boot application having Eureka server dependency (from spring cloud) in its pom.xml file. Every Microservice will register itself to the Eureka server by providing its metadata. Hence Eureka server will know the IP address and port of all the registered microservices. Eureka Server is additionally known as Discovery Server. Annotate the Spring Boot application runner with @EnableEurekaServer to enable this as a Eureka Server. Eureka Server receives heartbeat messages from each instance of eureka Client.

Eureka client is a spring boot microservice which registers itself with Eureka Server. Eureka Client applications will have Eureka Client dependency in its pom.xml. Annotate your Spring Boot application runner with @EnableDiscoveryClient or (@EnableEurekaClient), and you can use it to discover service instances from the Eureka Server. Below configuration to locate the Eureka server

eureka.client.serviceUrl.defaultZone=http://localhost:8761/eureka/

Conclusion:

Although everyone in the industry is in the race of moving towards Microservices, you need to be carefully accessed if your application needs to move to microservices or not.  Also, we need to choose a technology stack carefully because we will also need resources to support them.  It would be best if you considered moving your application functionality in chunks instead of significant migration from an existing monolithic application to microservices.  Microservice architecture based applications are providing good ROI in many industries like e-Commerce, social media, etc.