Microservices - Introduction, How to design & develop? When to use?

#microservices #agile #devops #cloudnative

This article will focus on microservices architecture introduction, benefits, how to design & develop and when to use for this architecture pattern.

Microservices Introduction

Microservice architectural style is an approach to 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.

It has following characteristics:

Built around business capabilities
Loosely coupled services and highly resilient, scalable services
Independently deployable using automated pipelines (CI/ CD)
Capable of being developed by a small team - highly maintainable & testable

With legacy Monolithic architecture style, which is often developed as a single process, all functionality is deployed as one large process. And it scales by replicating the monolith on multiple servers. This has limitations such as difficult to selectively scale, long term commitment to technology stack and hard to modify as monolith grows over time and long time to develop new features.

Benefits of Microservices Architecture:

Evolutionary design
Possible to selectively scale up and down based on volume
Enables the continuous delivery and deployment - shorter time to market
Easy to understand and add new team members
Flexibility to choose most suitable technology stack for new business change

Following diagram by Martin Fowler summarizes comparison between monolith and microservices.

How to decompose and develop microservices?

To design system with microservices, Domain driven design (DDD) principles are very handy. It says, develop microservices by considering high cohesion of related business functionality.

DDD refers to the application’s context to solve a particular business need as the domain. A domain is consists of multiple subdomains. Each subdomain corresponds to a different part of the business.

For example, Online grocery store as domain would have following sub domains.

Product Catalog
Order Management
Delivery Management
Inventory Management

This segregation of bounded context, domains and sub domains require good understanding of business and organization structure.

Each microservice is built with single responsibility principle, but not too granular that a single business change affects multiple microservices and requires them to deployed together most of the time (sometimes for a big change, this is fine. But not always, otherwise it is just another monolith).

Another analogy that helps with microservices design is the design of Unix utilities such as grep, cat and find. Each utility does exactly one thing, often exceptionally well, and can be combined with other utilities using a shell script to perform complex tasks.

Following diagram shows illustrative views of microservices architecture.

How to develop microservices?

In order to achieve loose coupling, the system with microservices might have more than one/ database per service. So consider saga pattern for distributed transaction management as 2-phase commit is not an option. Each service can publish events as and when their data changes, and other services consume these events to take relevant action on their side (update their data). Consider Event sourcing design pattern.

For retrieving data owned by multiple services, consider Command Query responsibility segregation (CQRS) and API Composition design pattern.

It gives lots of flexibility in terms of choosing technology stack for developing microservices, but be careful to consider "hype cycle" of any technology and availability of talent pool. For example, Java is widely used and popular programming language with support of various open source framework and tools such as Spring Boot, Kafka, Swagger, to name a few. Python as well comes with lots of popular libraries such as numpy, pandas, pyTorch and talent pool.

Be careful to only choose microservices architecture when you have compelling need and demanding business case. Keep in mind that microservices architecture is not silver built that applies to all business problems and use cases.

When to use microservices architecture?

When building strategic business transformation products and services, which have long future and is likely to have high volume transactions and traffic
When existing monolithic application has known issues to accommodate scalability, agility, and delivery speed
Availability of right tools and technological expertise within team to develop cloud-native applications

Most large scale web sites including Netflix, Amazon and eBay have evolved from a monolithic architecture to a microservices architecture.

Happy coding and building microservices ! Please like, share and comment your views/ opinion.

Disclaimer - This post is my personal opinion and does not reflect those of any of my past, present or future employers or affiliations.