Microservices with Spring Boot - Part 1 - Getting Started

This guide will help you learn the basics of microservices and microservices architectures. We will also start looking at a basic implementation of a microservice with Spring Boot.

We will create a couple of microservices and get them to talk to each other using Eureka Naming Server and Ribbon for Client Side Load Balancing.

This is a 5 Part Article Series

Microservices with Spring Boot

In part 1 of this series, lets get introduced to the concept of microservices and understand how to create great microservices with Spring Boot and Spring Cloud.

You will learn

  • What is a Monolith?
  • What is a Microservice?
  • What are the Challenges with Microservices?
  • How does Spring Boot and Spring Cloud make developing Microservices easy?
  • How to implement client side load balancing with Ribbon?
  • How to implement a Naming Server (Eureka Naming Server)?
  • How to connect the microservices with Naming Server and Ribbon?





10 Step Reference Courses

Microservices Overview - A Big Picture

In this series of articles, we would create two microservices:

  • Forex Service - Abbreviated as FS
  • Currency Conversion Service - Abbreviated as CCS

Do not worry if you are not clear about a few things. The idea is to give a big picture before we get our hands dirty and create the microservices step by step

Forex Service

Forex Service (FS) is the Service Provider. It provides currency exchange values for various currency. Let’s assume that it talks to a Forex Exchange and provides the current conversion value between currencies.

An example request and response is shown below:

GET to http://localhost:8000/currency-exchange/from/EUR/to/INR

  id: 10002,
  from: "EUR",
  to: "INR",
  conversionMultiple: 75,
  port: 8000,

The request above is the currency exchange value for EUR to INR. In the response, conversionMultiple is 75.

We will talk about port in the response a little later.

Currency Conversion Service

Currency Conversion Service (CCS) can convert a bucket of currencies into another currency. It uses the Forex Service to get current currency exchange values. CCS is the Service Consumer.

An example request and response is shown below:

GET to http://localhost:8100/currency-converter/from/EUR/to/INR/quantity/10000

  id: 10002,
  from: "EUR",
  to: "INR",
  conversionMultiple: 75,
  quantity: 10000,
  totalCalculatedAmount: 750000,
  port: 8000,

The request above is to find the value of 10000 EUR in INR. The totalCalculatedAmount is 750000 INR.

The diagram below shows the communication between CCS and FS.


Eureka Naming Server and Ribbon

Based on the load, we can have multiple instances of the Currency Conversion Service and the Forex Service running. Image Image

And the number of instances for each service might vary with time. Below picture shows a specific instance where there are 5 instances of the Forex Service. Image

What needs to happen in the above situation is load should be uniformly distributed among these 5 instances. Image

In this series of articles, we will use Ribbon for Load Balancing and Eureka Naming server for registering all microservices. Image

Do not worry if you are not clear about a few things. The idea is to give a big picture before we get our hands dirty and create the microservices step by step

What is a Monolith Application?

Have you ever worked in a project

  • Which is released (taken to production) once every few months
  • Which has a wide range of features and functionality
  • Which has a team of more than 50 working for it
  • Where debugging problems is a big challenge
  • Where bringing in new technology and new process is almost impossible

These are typical characteristics of a Monolith applications.

Monolith applications are typically huge - more 100,000 line of code. In some instances even more than million lines of code.

Monoliths are characterized by

  • Large Application Size
  • Long Release Cycles
  • Large Teams

Typical Challenges include

  • Scalability Challenges
  • New Technology Adoption
  • New Processes - Agile?
  • Difficult to Automation Test
  • Difficult ot Adapt to Modern Development Practices
  • Adapting to Device Explosion


Microservice Architectures evolved as a solution to the scalability and innovotation challenges with Monolith architectures.

There are a number of definitions proposed for Microservices

Small autonomous services that work together - Sam Newman

Developing a single application as a suite of small services each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies - James Lewis and Martin Fowler

While there is no single accepted definition for microservices, for me, there are a few important characteristics:

  • REST - Built around RESTful Resources. Communication can be HTTP or event based.
  • Small Well Chosen Deployable Units - Bounded Contexts
  • Cloud Enabled - Dynamic Scaling

How does Microservice Architecture look like?

This is how a monolith would look like. One application for everything.

This is how the same application would look like when developed using Microservices Architecture.

Microservice Architectures involve a number of small, well designed, components interacting with messages.

Advantages of Microservices


  • New Technology & Process Adaption becomes easier. You can try new technologies with the newer microservices that we create.
  • Faster Release Cycles
  • Scaling with Cloud

Challenges with Microservice Architectures

While developing a number of smaller components might look easy, there are a number of inherent complexities that are associated with microservices architectures.

Lets look at some of the challenges:

  • Quick Setup needed : You cannot spend a month setting up each microservice. You should be able to create microservices quickly.
  • Automation : Because there are a number of smaller components instead of a monolith, you need to automate everything - Builds, Deployment, Monitoring etc.
  • Visibility : You now have a number of smaller components to deploy and maintain. Maybe 100 or maybe 1000 components. You should be able to monitor and identify problems automatically. You need great visibility around all the components.
  • Bounded Context : Deciding the boundaries of a microservice is not an easy task. Bounded Contexts from Domain Driven Design is a good starting point. Your understanding of the domain evolves over a period of time. You need to ensure that the microservice boundaries evolve.
  • Configuration Management : You need to maintain configurations for hundreds of components across environments. You would need a Configuration Management solution
  • Dynamic Scale Up and Scale Down : The advantages of microservices will only be realized if your applications can scaled up and down easily in the cloud.
  • Pack of Cards : If a microservice at the bottom of the call chain fails, it can have knock on effects on all other microservices. Microservices should be fault tolerant by Design.
  • Debugging : When there is a problem that needs investigation, you might need to look into multiple services across different components. Centralized Logging and Dashboards are essential to make it easy to debug problems.
  • Consistency : You cannot have a wide range of tools solving the same problem. While it is important to foster innovation, it is also important to have some decentralized governance around the languages, platforms, technology and tools used for implementing/deploying/monitoring microservices.

Solutions to Challenges with Microservice Architectures

Spring Boot

Enable building production ready applications quickly

Provide non-functional features

  • embedded servers (easy deployment with containers)
  • metrics (monitoring)
  • health checks (monitoring)
  • externalized configuration

Spring Cloud

Spring Cloud provides solutions to cloud enable your microservices. It leverages and builds on top of some of the Cloud solutions opensourced by Netflix (Netflix OSS).

Important Spring Cloud Modules

Dynamic Scale Up and Down. Using a combination of

  • Naming Server (Eureka)
  • Ribbon (Client Side Load Balancing)
  • Feign (Easier REST Clients)

Visibility and Monitoring with

  • Zipkin Distributed Tracing
  • Netflix API Gateway

Configuration Management with

  • Spring Cloud Config Server

Fault Tolerance with

  • Hystrix

Microservice Series of Articles

In this series of articles, we would create two microservices:

  • Forex Service - Abbreviated as FS
  • Currency Conversion Service - Abbreviated as CCS

The diagram below shows the communication between CCS and FS. We would establish communication between these two components.


We would want to be able to dynamically scale up and scale down the number of instances of each of these services.

Image Image

And the number of instances for each service might vary with time. Below picture shows a specific instance where there are 5 instances of the Forex Service. Image

Implementing a solution for dynamic scale up and down needs to answer two questions

  • How does the Currency Conversion Service (CCS) know how many instances of Forex Service (FS) are active?
  • How does the Currency Conversion Service (CCS) distribute the load between the active instances.

Because we want this to be dynamic, we cannot hardcode the urls of FS in CCS. Thats why we bring in a Naming Server.


All instances of the components (CCS and FS) register with the Eureka Naming Server. When FS needs to call the CCS, it will ask Eureka Naming Server for the active instances. We will use Ribbon to do Client Side Load Balancing between the different instances of FS.

A high level sequence diagram of what would happen when there is a request from CCS to FS is shown below: Image

Here are the next series of Articles

  • Creating a Forex Microservice - We will create a simple rest service based on Spring Boot Starter Web and Spring Boot Started JPA. We will use Hibernate as JPA implmentation and connect to H2 database.
  • Create the CCS - Currency Conversion Service - We will create a simple rest service using feign to invoke the Forex Microservice
  • Use Ribbon for Load Balancing
  • Implement Eureka Naming Service and connect FS and CCS through Eureka.

Next Steps








Related Posts

Spring Boot Tutorials for Beginners

At in28Minutes, we are creating a number of tutorials with videos, articles & courses on Spring Boot for Beginners and Experienced Developers. This resources will help you learn and gain expertise at Spring Boot.

Introduction To Aspect Oriented Programming and Cross Cutting Concerns

Software applications are built in layers. There is common functionality that is sometimes needed across layers - logging, performance tracing etc. How do you implement these common features?

Programming Basics - Introduction To Object Oriented Programming

Object oriented programming (OOP) is all about thinking in terms of objects. Let's dig deeper.

Programming Basics - Five Things To Think About While Programming

You would obviously want to write code that meets your core requirements and provide good performance - choosing right data structures and algorithms to use is the fundamental part of programming. What are the other things that you need to worry about? Here are five things that we think are essential.

Asynchronous communication with queues and microservices - A perfect combination?

In this article, we throw some light on what asynchronous messaging is all about and discuss why you should consider it for your microservices architectures.

Microservice Best Practice - Build an Archetype

In this article, we focus on learning why creating proper archetypes is important for successful microservices architecture.

Microservice Architecture Best Practices - Messaging Queues

In this article, we discuss why Messaging queues are needed, and how they form the cornerstone of communication in microservices architectures.

Microservice Best Practice - Why do you build a Vertical Slice?

In this article, we look at what is a vertical slice, and why we build it. We also discuss the best practices involved in building vertical slices.

Microservices Architectures - Event Driven Approach

In this article, we talk about event driven approach, in the context of microservices architectures. We also discuss what are the advantages of using an event driven approach.

The 12 Factor App - Best Practices In Cloud Native Applications and Microservices

In order that an application be deployed in the cloud and enjoy features such as auto scaling, it first needs to be cloud native. In this article, we have a close look at the best practices for cloud native applications, popularly known as The 12 Factor App.