An Introduction to Microservice Architecture

By October 7, 2019Data Sink
Microservices Architecture

Recently we came across a problem where we wanted to create new UI for an existing old product. The core functionality of a product is quite stable and total features are still quite useful. We wanted to write UI using Angular. In the exiting product, UI is not completely decoupled from business logic and middleware. Initially, we decided to create a web services wrapper around the middleware. But as we were going to decouple UI and middleware, we decided to review the existing microservices architecture of the product and identify other architectural issues and identify possible changes we need to do make it more scalable. We might not be able to change all things at once but it’s good to take a look at the bigger picture.

Monolithic Microservice Architecture :

As most of the older monolithic applications have more of a one complete package having all the related needed components and services encapsulated in one package.
Below is the diagrammatic representation of monolithic architecture being package completely or being service-based.

Problems with Monolithic application :

Scalability: All parts for the application were tightly coupled, it had scalability issues. We couldn’t deploy applications in a multi-server environment. We could only separate the application server and DB but couldn’t deploy the application server on the multi-server environment. So the only option was to increase server hardware which also has limits.

No continuous deployment: Even for a small change, we need to rebuild and deploy the whole application or manually change affected executables.

Slow development: Since it was hard to separate out an application into independent blocks, there is a limitation on the concurrent development.

Limited technology choice: Even if we wanted to add a new feature we have to use old technologies as there was no logical separation in the different parts of the application.

Testability: For any small change, we had to test a lot of scenarios as there was no logical separation or clear cut boundary for the different components.

Microservices Solution:

Microservices: Also known as the microservice architecture is an architectural style that structures an application as a collection of services that are

• Loosely coupled

• Highly maintainable and testable

• Independently deployable

• Organized around business capabilities

• Owned by a small team

In a microservice architecture, each service is self-contained and implements a single business capability.

Features of Microservices:

Componentization: Microservices can be easily replaced and upgraded hence that are known as independent components.

Decoupling: The application as a whole can be easily built, altered, and scaled because services within a system are largely decoupled.

Autonomy: Teams and developers can work independently of each other, therefore, increases the speed.

Business Capabilities: Microservices are very easy and focus on a single capability.

Agility: Microservices support agile development. Any recently developed feature can be quickly developed and discarded again.

Continuous Delivery: Allows frequent releases of software over systematic automation of software creation, testing and approval.

Independent Development: Each microservices can be easily developed based on their individual functionality.

Independent Deployment: They could be individually deployed in any application based on their services.

Granular Scaling: Specific parts can scale as per need, there is no need to scale all components together.

Mixed Technology Stack: Different technologies and languages can be used to build distinct services of the same application.

Fault Isolation: If one service of the application does not work, the system still continues to function.

Consider the Online travel portal as a use case to figure out the difference between both of them.

The most important difference we see in the above representation is that all the features were initially under a one instance sharing a single database with microservices, each feature was allotted a distinct microservice, handling their own data, and performing different functionalities.

Rahul Khedekar

Author Rahul Khedekar

More posts by Rahul Khedekar

Leave a Reply