KEY POINTS
- Why Microservices ?
- All these came with the need to be agile and meet market demand at a faster pace.
- Independently deployable. Each microservice can be deployed by itself. Unlike monolith where complete application has to be deployed.
- What is monolithic application ?
- It’s an application where every part of the product is part of same service or web application. And usually the data for the entire application is in a single data store.
- Issues in monolith application ?
- Source code management- every project is in single solution..[merge nightmares]
- you need bigger team to manage bigger application
- Code and database deployments and rollbacks are nightmare.
- Microservices –
- Are smaller single responsibility services. It does only one thing. They have clear cut boundary.
- The logic as well as data of a single responsibility microservice should not leak outside of it.
- Cost of IIS ? – If all services are deployed in same windows machine in an IIS, if IIS has an issue , all app will fail. If you need multiple IIS and boxes, there is significantly higher cost associated with it.
- Cost of Databse ? Having so many databases is also not an effective solution
- Solution? – Containers – Conatiners are used for packaging software and all its dependencies into a standard unit for development,deployment and shipment. They are immutable.
- Containers are defined as images, which becomes containers on runtime
- Docker is the most popular implementation.
- Why not VM ? –
- Containers –Lightweight in size(mb) —– VM goes in GB
- Conatainers – fast to start —————– VM – they take 15 to 30 min. Slower to start.
- Containers – are best suited for microservices ——- VM can be used but not cost effective
- Containers- Resource utilization can be optimised to use most out of a machine, some boxes can run 30 to 40 microservices ——- VM- suboptimal resource optimization
- Containers- less secure across containers ————-VM – Secure across VMs
- .Net core was built with containers in mind. .net core applications can run on containers
- Running in containers gives all the advantage of containers, including saving in cost and efficiency( Linux is the best OS choice, Windows is expensive).
- Containers are immutable, they dont maintain state.
- Database like postgres can easily run in containers and have isolations we want.
When should I use Microservice ?
-
- Start with a monolith application if you are not sure.
- The main deciding point to go to microservice is your agillity of deployment. Think about which functionality makes sense breaking up for ease of deployment.
- If you are going with microservice, docker is your best friend.
- When you use docker – next question is how to scale out or scale down. Orchestration engine is needed. Kubernetes is the most popular and open source container orchestration engine. orchestration engine is not the starting point… when microservices increases , then go for orchestration engine. Cloud providers if you use, it will handle for you. For example ECS service in aws handles it for you
- Microservice is great when it comes to scaling as well. Independently scalable.
- No bulky code unlike monolith
How microservices communicate ?
-
- Most popular is REST API. GRPC is catching up quickly
- Message based communication(Queue or Pub/Sub) which works very well when you want to offload work to some background services. And the response is not time sensitive (example bank state of last 3 year).
How do I convert my monolith to microservices ?
-
- Bring out the most easily separable component from the monolith first.
- If you are using SQL – start isolating the tables, meaning all the tables are in same database but you ensure that for a set of table a single microservice is responsible for that. Any other part of the application which wants to read the data from this table goes to the microservice instead of directly connecting to the table. Every microservice will access its own table set. Then you can move those tables into their own databases.
- If you are using any cloud provider
- AWS – go for Dynamo DB
- AZURE- Cosmos DB
What about reports?
-
- As data is segregated across muliple databases, getting a consolidated view is hard.
- Using Api gateway, using aggregation service
- Api gateway support data aggregation
- Use Api gateway or an aggregator service to get data from multiple services, aggregate them and give it to the user.
- Second option – you can create data stream for all the data and have an aggregator. Create a read-only view of the data.
- When you start building microservice – think about resilience during design – means when one part of your application is down, your entire application should not be down
- Establish the communication pattern you have to use between your microservices based on response needs.
- Logging and monitoring cannot be an afterthought. Cloud based centralised logging is extremely critical. Also passing a correlation logid across microservices would save you lot of debug time in future.
- Build your microservice as if it is built for external user and not for your internal services.