Microservices – What it is and why to choose it?
In the previous article, we saw problems with monolith . Please do read that if you want to understand why we should adopt microservices.
Here we will see what is microservice architecture and how it helps to solve those problems and help us to scale the application and team to build resilient reliable software.
What is microservices?
Microservices – also known as the microservice architecture – is an architectural style that is a collection of services coupled over a network.
Each module in monolith will be a service in microservices. For example payment module will be payment service,user module will be user service. Some of the key points are
- Model your services around your business logic(DDD- Domain Driven Design ). For example to support customer care tech needs we can have something like feedback service, for payment service, to manage order service, etc.
- Each service should have well defined the boundary and should have a single responsibility. For example, payment services should only handle payment-related stuff.
- Services should communicate with other services only via .interfaces (API contracts and Events) . Hide implementation details of services.
- To facilitates independent Software development life cycle, each service should have its own database/tables/data which can only be accessed by owner services. If other services need the data they can fetch it via API or maintain a read-only copy of data.
- We should be able to independently develop test and deploy the service.
Lets see how things are different from monolith
Each module in monolith will convert to a services.(mostly not always)
One key take away here is that in microservices architecture we are able to independently develop, test, and deploy the services. That gives lots of flexibility over monolith. Let’s see how it solves the problems monolith has.
- We can optimize services to scale based on its technological needs. For example, Databases can be optimized for reading or writing, some services can use SQL DB some can use NoSQL as needed,
- As we model our services around business needs, if business needs arise for new feature/capability, we can scale our team that can work closely with business and can create and manage new service.
- For example, if we need tech related to business need for customer care than we can create feedback service to handle those capabilities.
Continuous deployment(Feature Velocity)
- As long as the contract between services does not change, each team can make changes to its service, develop new features, and deploy it without any coordination with other teams. It will improve feature velocity.
- For example – You don’t need to coordinate if you are changing the underlying table structure as long as the API contract is not changed.
- Because of continuous deployment, a small block of code will go live in production. And changes for each service will go live independently of each other.
- If an issue comes up we will be in better shape to identify and fix the service and change that caused the issue.
Isolation of Failure
- It isolates Fault/bugs to the individual service and will not bring down the entire system.
- For example, if the issue is in feedback service or recommendation service, we can turn off these services for time being and critical business operation can go on.
Evolutionary and Flexibility
- We have the flexibility to code each service in their own coding language that is best suited for the use case.
- This architecture is loosely coupled and can really evolve over time as and when the business grows.
All of this comes with some problems
- In microservices. calls are over the network, so it becomes complex when the number of services grows.
- Debugging becomes tough as execution for a single flow is spread across services.(We can solve it using correlation id etc)
- Integration testing becomes tough.
- We need to manage more number of deployments.
- Transactions and joins become complex in microservices(In monolith it is straight forward)
To embrace micro services architecture we need to have
- Proper logging and monitoring mechanism
- Automation of deployment and testcases
- Adopt Dev Ops culture
- Hide implementation details of services
- Decentralize things
This is all for now. We will most more about the common patterns in and more details about microservices soon.
Follow us here