The Background Story – Defining the Problem

For the last several months I have been creating server-side apps using Spring Boot. These apps must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The server-side apps all handle HTTP requests, processing them by executing business logic and providing JSON as responses. Because of my knowledge of developing server-side apps and the current project situation, I have so far created and deployed these apps as single monolithic applications.

While this has worked well so far, it is apparent that as the applications become more complex with enhanced features, testers are having increasing difficulties testing the front-end apps. Even worse, once a defect has been identified in particular feature, the entire application needs to be redeployed. This interrupts background tasks, and it is possible that fixes may even be ineffective. Because the front-end dev team cannot effectively test their apps using real APIs, results can be unpredictable.

In researching strategies to tackle this issue, I came across microservice architecture. Essentially, microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services. Each service runs on its own process and communicates through a well-defined mechanism to serve a business goal. Microservice architecture seemed to offer solutions to the issues I was facing, so I decide to migrate the apps step-by-step from monolithic to microservice.

Introducing Microservice Architecture

Microservices is an architectural style that structures an application as a collection of services that are:

• Highly maintainable and testable
• Loosely coupled
• Independently deployable, and
• Owned by a small team

In this context, loosely coupled means that each service can be usually be updated separately without affecting other services. On the rare occasions other services are impacted, impact to them is generally minimal.

Using Microservice architecture has a number of immediate benefits:

1. It makes continuous delivery and deployment of large and complex applications possible.

• Easier to maintain because each service has a smaller business scope and technical complexity.
• Enables more thorough testing because individual services are smaller.
• Deploying services is easier, and services can be deployed independently.

2. Each service is relatively small:

• They are easier for developers to understand.
• Opening each microservice project in an IDE is faster.
• Application start-up times are lower, speeding up deployments.

3. Improved fault isolation helps prevent the spreading of an issue from one service to another.

To better understand how a microservice works, let’s look at how we could create one.

Designing Microservices

Before we start implementing our Microservice example, here is a high-level diagram of how it will look.

According to Microservices architecture, we will divide the application into separate services. Each service is scalable and independently deployable, and they have exact and well-defined scopes. From the above image we can separate the services into two categories – functional and non-functional.

The non-functional services will be:

1. The Configuration service:
A service dedicated to providing configuration data for all other services. We use this approach to reduce complexity when maintaining the configuration of many microservices in different environments.

2. The Registry service (Discovery service):
This service helps to discover the services we required. When a service needs access to another service, the registry server provides all the endpoint details of the requested service to establish the connection. All services need to register with the Registry Sever, or it won’t know about them. There are multiple popular implementations possible for the Discovery Server (e.g. Netflix Eureka, Consul, Zookeeper).

3. The Gateway service:
This service acts as the “front door” of the system. External users access core services through the API Gateway. The Gateway service then routes the requests to service endpoints by reading services that are registered in the Registry service.

The second category is functional services. Keep in mind that all of these services are dependent on non-functional services used by the client. The functional services will be:

1. The Authentication service:
This is responsible for handling the authentication processes of the system, auth-user retrieval, and auth-user store. It connects with the User, Role, and Permission database tables.

2. The Product service:
This is responsible for the products store and products listings (like stock handling processes).

3. The Account service:
This is responsible for handling user account and user personal identity.

4. The Order service:
This is responsible for handling orders for products placed by buyers. The seller can then process the orders.

Now that we have designed how the Microservices will work microservice, we’re ready to start building. In the next part, I will explain on how we implement the non-functional services using spring boot. Stay tuned!

Author:
I Kadek Dendy Senapartha – Analyst Programmer Mitrais