Self interview about Microservices
We have one big question which has already been answered many times, yet,
both the question and answers to it keep evolving with the time. Facts become myths, myths recycle as post-facts. Based on that, I will try to ask and answer some questions about microservices. Let’s try to answer the main one..
But wait, what was the main question?
When to go microservices?
I am a software engineer and after 8 years of backend development experience, I think I have started to understand things, finally*. So I will answer the question in a developer point of view and so the main question becomes:
When do I choose microservices architecture over monolithic one?
The most easiest answer to that question is “well, i do not, i avoid that as much as possible”.
But most of the time, it is not up to developer to choose or decide. The decision is already made and developer’s responsibility is to envision it. But how one can achieve that? Of course, by asking more questions. And in my opinion, there are two primary ones assuming you have a business
which cares about their customers by being 24/7 available, fast, responsive, resilient, etc. So primary questions are:
1. How many bits are we going to process?
2. How many bits are we going to store?
Let’s try to answer these questions in two different types of companies.
In the first scenario, let’s assume, you are working in a fresh and maybe greenfield startup and nobody ever measured any metrics, nobody gave you any insights regarding your company’s potential amount of customers. Maybe, they have just made a small market research resulted as `people are going to love this product`. The investors, ideators had a gut feeling to trust their product a lot.
Then you can do a favor to those people by deciding `not to go with microservices` but `to build a monolithic application which is highly extensible when the product is about to hit the big time`. This will help them to last longer by spending their resources and energy carefully when things do not go as expected.
In the second scenario, let’s assume, your company made proper market researches, presented you numbers regarding first years of the product launch and those numbers answer question 1 and 2 as “FREAKING HUGE”. (or they have unlimited resource and do not care about the hiring 8x developers, engineers, production managers, servers running idle, service subscriptions paid for nothing, etc)
Then you might think to give it a go with microservices.
But wait here a bit, this does not feel like the correct answer, simply because there is a new question:
Why can't we process and store `FREAKING HUGE` amount of data with a monolithic application?
So, I strongly believe, this is a question that most people (I lead that group) does not have the best answer.
But, anyway, let’s try to answer it.
Answer #1: We will scale by using different storage technologies. I will keep my relational information in Postgres but some documents in MongoDB.
This is a good point but you can achieve the same with a monolithic application by abstracting storages from your application logic with multiple DAOs/Interfaces/Datastores/Connection Pools. At the end of the day, is not it the one of the reasons such frameworks like Spring, Django exists?
Answer #2: Some part of the application will have more load than the other parts. So, we will separate Feed Service from the User Service because first one is going to receive 5 times rps over the second one.
Well, this answer has another good point but it is still achievable in a way like, scattering monolithic application over a cluster, marking some area of this cluster as Feed Service Zone and directing the high traffic into there, maybe with some basic http rules. The one caveat on that might be nonfunctional User Service part will live on Feed Service Zone just like a parasite. But
is it really a big problem to worry? Personally, i am not sure.
Answer #3: The team is going to work on the same codebase, they will interfere each others’ responsibilities. Simply there will be a chaos working 50 developers in the same codebase, eventually they are going to cross their Antennas while moving.
Personally, I like this answer a lot. By in any living creature nature, comfort and so consequently productivity will decrease if these creatures feel like they are trapped in small cell and no way to grow their parts/families independently. Most of the time they have to convince and drag all the community with them. Well, this is very right, but i still think, it is also achievable with monolithic application, by finding the optimum number of developers, facilitating high team collaboration, building strong common ground with good decision makers. (Cliche alert: bees are already doing this)
Answer #4: I want to use different languages for different purposes. A little bit Java, a little bit Python, etc..
I have no strong comment on this topic. Maybe i am too ignorant to say this but most of the time language does not matter, especially for the backends of web applications. I see all modern languages are diverging to each other when it comes to functionality. They all have rest frameworks, gateway solutions, async patterns, dao interfaces, http clients etc. This is what Java is doing for years, it is easily absorbing the functionality from the others.
We can increase the number of those answers but i think i have already made my point which is ‘each of them is not enough to make a decision by only itself but by summing up all these problems, you can get to a point where you express yourself like, -Ok i think at this point I have to embrace Microservices architecture problems in order to overcome pile of Monolithic architecture problems.’
By finishing this story up, I want to summarise the story:
You work in a customer centric company (let’s say bubble, as a metaphor), you know product is going to process and store huge amount of data and therefore you have to scale. You have your own specific business capabilities and you know it is really hard to scale this bubble in a heterogenous way like pumping air into some parts from other parts. So what you have to do is to create other small independent bubbles from this big bubble to let them grow and separate themselves into to the highly possible independent bubbles.
Thank you for reading, please feel free to add comments/objections as all of them will make me ask new questions.