Benefits of microservices

You start building microservices because they give you a high degree of flexibility and autonomy with your development teams, but you and your
team quickly find that the small, independent nature of microservices makes them easily deployable to the cloud. Once the services are in the cloud, their small size makes it easy to start up large numbers of instances of the same service, and suddenly your applications become more scalable and with forethought, more resilient.

A microservice architecture has the following characteristics:

  • Application logic is broken down into small-grained components with well defined boundaries of responsibility that coordinate to deliver a solution.
  • Each component has a small domain of responsibility and is deployed completely independently of one another. Microservices should have responsibility for a single part of a business domain. Also, a microservice should be reusable across multiple applications.
  • Microservices communicate based on a few basic principles (notice I said principles, not standards) and employ lightweight communication protocols such as HTTP and JSON (JavaScript Object Notation) for exchanging data between the service consumer and service provider.
  • The underlying technical implementation of the service is irrelevant because the applications always communicate with a technology-neutral protocol (JSON is the most common). This means an application built using a microservice application could be built with multiple languages and technologies.
  • Microservices—by their small, independent, and distributed nature—allow organizations to have small development teams with well-defined areas of responsibility. These teams might work toward a single goal such as delivering an application, but each team is responsible only for the services on which they’re working.

What’s a microservice?

Before the concept of microservices evolved, most web-based applications were built using a monolithic architectural style. In a monolithic rchitecture, an application is delivered as a single deployable software artifact. All the UI (user interface), business and database access logic are packaged together into a single application artifact and deployed to an application server.
While an application might be a deployed as a single unit of work, most of the time there will be multiple development teams working on the application. Each development team will have their own discrete pieces of the application they’re responsible for and oftentimes specific customers they’re serving with their functional piece.

For example, customer relations management (CRM) application that involves the coordination of multiple teams including the UI, the customer master, the data warehouse and the mutual funds teams. Below Figure illustrates the basic architecture of this application.

Monolithic applications force multiple development teams to artificially synchronize their delivery because their code needs to be built, tested, and deployed as an entire unit.

The problem here is that as the size and complexity of the monolithic CRM application grew, the communication and coordination costs of the individual teams working on the application didn’t scale. Every time an individual team needed to make a change, the entire application had to be rebuilt, retested and redeployed.

A microservice is a small, loosely coupled, distributed service.
Microservices allow you to take a large application and decompose it into easy-to manage components with narrowly defined responsibilities. Microservices help combat the traditional problems of complexity in a large code base by decomposing the large code base down into small, well-defined pieces. The key concept you need to embrace as you think about microservices is decomposing and unbundling the functionality of your applications so they’re completely independent of one another. If we take the
CRM application we saw in above figure and decompose it into microservices, it might look like what’s shown in below figure.Looking at below figure, you can see that each functional team completely owns their service code and service infrastructure. They can build, deploy, and test independently of each other because their code, source control repository, and the infrastructure (app server and database) are now completely independent of the other parts of the application.

A microservice architecture of CRM application would be decomposed into a set of microservices completely independent of each other, allowing each development team to move at their own pace.

Microservices Example using Spring Cloud Eureka

In this tutorial, we will create a demo microservice using spring boot framework in java.

Tools Required

  • Java 8
  • IntelliJ IDE

We need to create three different applications as below –

  1. Eureka Service–  This Service will register every microservice and then the client microservice will look up the Eureka server to get a dependent microservice to get the job done.This Eureka Server is owned by Netflix and in this, Spring Cloud offers a declarative way to register and invoke services by using Java annotation.
  2. demo-server – This service will return a simple hello message.
  3. demo-client – It is similar to the standalone client service created in Bootiful Development with Spring Boot. It will consume the APIs provided by demo-server through Eureka Service .

1. Eureka Service

We need to create new project in intelliJ editor by selecting below dependencies –

Project Setup
Maven dependencies

You need to do below configurations to create Eureka service which allows other microservices to register with it .

package com.myjavablog;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

public class EurekaServiceApplication {

	public static void main(String[] args) {, args);


You need to create application.yml to configure your EurekaService project as register service. Other services will be able to register themselves with EurekaService. So you need to do below configurations –

    registerWithEureka: false
    fetchRegistry: false
      waitTimeInMsWhenSyncEmpty: 0

Now you can run the application . Once the application is up and running you can go to below URL and see EurekaService is working . You will be able to see below home page of eureka-

As no instances are registered with EurekaService , you can see No instances available message as highlighted above . Now we will create services which will register with our Eureka Server.

2. Demo Server

This is a simple REST based webservice. This will be registering itself with the EurekaService. This service has a simple API which is just returning hello message. Create a project structure as shown below in IntelliJ IDE –

Maven Dependencies required

Project structure is as shown below –

You need to include Eureka Discovery client dependency in your pom file.

Once the application is up and running , you can see instance of demo-server registered on EurekaService as shown below –

3. Demo Client

Same way as Demo server , we need to create demo client which will consume services provided by demo-server through EurekaService.

demo-client will have autowired RestTemplate to call the services provided by demo-server.

package com.myjavablog.democlient;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

public class TestController {

    public RestTemplate restTemplate;

    public String test(){
        String url = "http://demo-server/demo/hello/server";
        return restTemplate.getForObject(url, String.class);

Also you can see in the above code , we are using String url = “http://demo-server/demo/hello/server”

demo-server is the name specified in the application.yml file of demo-server project . So instead of using http://localhost:8071/demo/hello/server we are using http://demo-server/demo/hello/server .

demo-server is the name registered on Eureka server for demo-server application as shown below –

    name: demo-server

  port: 8071

    registerWithEureka: true
    fetchRegistry: true
      defaultZone: http://localhost:8070/eureka/
    hostname: localhost

Once the application is up and running , you can see the demo-client is registered on Eureka Server as below –

When you call the APIs from demo client ,it will internally call demo-server APIs through Eureka Service . Eureka server handles all routing and load balancing part. So even if you scale up your services in future by creating multiple instances, you can go on and use the services with the name which is registered on Eureka server.

Github Downlod Link: