In this post, I cover a primer about microservices.

What is Microservices? A Primer about Microservices

Wikipedia definition says

Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services.

Firstly, there is no official definition of Microservices by industry standards. It’s a recent phenomenon in the software industry to architect the new software which should be lightweight, easier to deploy, and scale, easier to refactor individually, and could work independently.

However, to understand in detail, you can definitely read Martin Fowler’s Microservices or Chris Richardson’s Microservices.

Secondly, microservices are small services that can run independently but can also easily communicate with other services.

Microservice Architecture vs Monolithic Architecture

In a traditional monolithic architecture style, there is a single application with a single code base. An application contains a number of modules that are interrelated and can have external dependencies. It’s a multi-tier enterprise application and has been used to build software for long.

Above all, the microservice architecture style was born out of a need to build an application that could easily be supported for mobile applications. The older style was not easy to support for mobile and new generation way to the handling of data. Any large enterprise application can be easily built using the microservices architecture style. A famous example is NETFLIX.

How to identify the Microservice Architecture Pattern?

A simple ground rule of the microservice architecture pattern is to build a standalone service that can be run without depending on any other service. In other words, a large application can have more than one service talking to each other, communicating with their own databases, but still performing the business logic. Databases are used to ensure loose coupling of services.

For instance, a large enterprise e-commerce application can consist of the following services

1. Backend service REST API to manage data
   1. Account Service
   2. Shipment Service
   3. Inventory Service
2. Runtime service to handle runtime and backend data to process business logic
3. Logging service
4. Error Handling service
5. Session service

Additionally, UI for the e-commerce application can be built independently to use backend services to show/edit data.

By standards, there are few rules to identify microservices patterns

1. Decomposition by business capability
2. Database per service pattern
3. API gateway pattern
4. Client-side discovery and Server-side discovery

Pros and Cons of Microservices

Pros

1. Deployability – Easier to deploy and one can deploy them independently, without affecting other services.
2. Reliability – A fault in the service can only bring down that service. Depending on the handling of the fault in the application, the rest of the application can still continue to work.
3. Scalability – Similarly, the scaling of each microservice will depend on requirements using clusters and grids.
4. Availability – Dispatching the patch or newer version of service requires less downtime compared to regular monolithic applications.
5. Management – Easier to manage
6. Design and Development – Each service helps the developer to manage the service easily without worrying about other services.

Cons

1. Performance – All services involved in the application have to communicate with each other over the network and that could hamper the performance.
2. Testability – Automated tests are harder to manage and run.
3. Memory usage – Possible duplicate data across services and a lot of duplication in the cache.

References

In conclusion, I covered a primer about microservices. If you want to read more about Microservices at following links:

1. Microservices by Chris Richardson
2. Microservices by Martin Fowler
3. Stackoverflow post about microservices

Lastly, if you enjoyed this post, subscribe to my blog.