Microservices - An Introduction

Microservices is an architectural approach to build suite of services, where each service can be developed, maintained, tested, deployed and scaled independently.

Earlier Monolith approach In this approach, service application is developed as a single monolithic containing collection of services and that is hosted in a single process. This approach is working, but even though only one service getting changed, the whole application needs to be built, tested and deployed, this increase the release cycle time, effort and cost.

Monolith is a single code base, hard to maintain the modularity as the system grows bigger and bigger. It can be scaled out horizontally, but at the service application level, not at the individual service level. Moreover to run this monolith app, need a server with high compute, storage, memory and it leads to increase in cost.

Why Microservices?

• Better way to scale out the individual services to meet the dynamic scaling needs
• Build a service which does one and only one thing, increase greater modular boundary.
• Different services can be developed using different technologies instead of single technology.
• Small teams who can expert in specific problem domain, work on the Microservices.  

Principles of microservices 

• Each service maintains its own data
• Services should be modelled around business domain
• Embrace the culture of automation (automated tests, environments, builds and deployments)
• Deploy independently (each service can be deployed independently)
• Highly observable - services are easy to understand because of one aspect of the functionality is handled here.
• Hide implementation details (evolve the implementation of one service without breaking others)
• Decentralize all the things (dump pipes and smart endpoints)
• Isolate failures (embrace failures and respond to failures )

Best practices

• Model the services around the business domain
• Services should be loosely-coupled and highly functionally cohesive
• Decentralize everything. Individual teams responsible for development and deployment.
• Avoid sharing code and data schema across the services
• Each service should maintains its own data.
• Select the appropriate data storage technology (SQL, NoSQL…) based on the requirements
• Services communicate through well-defined APIs
• Off-load cross-cutting like authentication, to the gateway
• Keep domain knowledge out of the gateway. It should just route the request without any business knowledge

Key Benefits:

• Scalability, specific service can be scaled-out based on the needs
• Ease of deployment, can be deployed quickly and independently without affecting rest of the services or system
• Agility, features can be released quickly since it is maintained by small team and can be deployed independently
• Resiliency, if anyone of the microservices becomes unavailable it won't disturb the other services as long as it responds to failures
• Technology heterogeneity, services can be developed in different technologies and different types of data stores

Key Challenges:

• Service boundaries, defining the service boundaries between the services is very critical, needs domain analysis.
• Inter-service communication, services communicated through messaging infrastructure adds additional complexity to the architecture
• Data consistency, each service manages its own data. can lead to challenges with data integrity and/or redundancy
• Devops, need to implement CI/CD pipeline to streamline the build and deployment
• Complexity, has many moving parts, need to design to embrace the failures instead of avoiding.