Microservices decision factors
In this article, I am going to talk about various factors that influence microservices. Microservices has been a buzz word for over a decade now. But not all capabilities are microservices candidates. Microservices come up with additional maintenance overhead and extra cost too. So we need to weigh-in the benefits (in terms of business) vs the cost associated with build and maintenance. We call it as ROI — Return Of Investment.
First step we need to ask ourselves is — what is the problem we are facing. If the problem (eg outage), that we are facing, has impact with respect to the business, then there is a likely chance that it can be considered as microservices.
The next step is to understand RTO and RPO.
- RTO — Recovery Time Objective. This means what is the acceptable downtime
- RPO — Recovery Point Objective. This means what is the acceptable amount of data loss.
If business says the RTO for my application is (say) 5 mins, then we MUST bring back the application up and running within 5 mins (no matter whatever be the issue). Typically the customers (of any product) will penalise the product company if the RTO and RPO are not adhered. So it’s important to keep the application Highly Available.
Now we know the business impact and we also know RPO and RTO. The next question we need to ask is — what is the budget (to transform or modernize)? If we have a limited budget (not sufficient for Big Bang transformation), then how can we make sure that the application is highly available.
One of the solution (rather easier one) is to build a distributed monolithic application. What it means is — the application will be deployed in multiple regions. So even if the app is down, in one region, we have the same app running in other regions. This ensures that the application is available all the time. This approach will be useful when we have limited budget and not enough time for transformation. There are a few trade-offs with this approach.
- If there is any bug (which impacts the business), then we MUST bring down the application across all regions. So in these cases there will be downtime
- If we need to deploy a change, we must deploy the same in all regions at the same time. Otherwise we might end up with data consistency issues.
If the business has enough budget for transformation, then microservices can be a potential option. Before designing the microservices, we MUST first follow the DDD (Domain Driven Design) approach in order to identify the key domains associated. The domains typically represent the business units. So we will use business terms rather than technical terms. We will have to follow the event storming workshop in order to identify the domains and capabilities.
Once the domains and capabilities are identified, then there comes identifying the dependencies with other services. The dependecy can be synchronous or asynchronous. We MUST make sure we decouple the dependencies so that there won’t be any impact to the consumer in case if the provider is down.
At this point of time, we also need to evaluate whether we need a dedicated database for each microservice. Sometimes, a shared DB will be good to address the business concerns. It also ensures that data is consistent. However if the DB is down or performing slow, all the services (connecting to that DB) will be impacted. Again we need to weigh-in the advantages of having a dedicated DB vs a shared DB.
The next aspect is Team composition — it is important that each of the microservice is developed, deployed and maintained independently. And to achieve this, businesses need to re-organize their teams. It is better to appoint an independent team to work on each microservice separately.
Skillset : The main advantage of microservices is — we can have the luxury to choose the right tech stack. Each service can be built in the language the team is comfortable with.
Once the services are built, We also need to ensure that we have the right set of DevOps toolkit. This ensures that we will have the completely automated build and deployment management and there-by better speed to market.
*** Please note that the cost associated with building the ecosystem surrounding microservices will be slightly high since we also need to ensure there are right set of monitoring and observability tools.
If you have any questions, on this article, feel free to reach out to me through my email id : kiran.mvv@gmail.com or LinkedIn — https://www.linkedin.com/in/kiran-mushnuri-7b09a73b/
I am going to publish all the latest trends, architecture related posts going forward. Please like, subscribe so that you will receive automatic notifications as soon as i publish the articles.
