Hello everyone,
We have a monolith application that has authentication and other services like managing the data in the database etc.
We recently checked the statistics of the endpoint calls and discovered that %70 of requests is to only one endpoint. Second most receives %6 of the requests.
In that case, does it make sense continue using same architecture or do you recommend something like microservices architecture, serverless etc. ?
Thanks.
Top comments (8)
I feel microservices are a little bit hyped, in the sense that they require changes in the team and in devops. In general, most of the people talking (correctly) about microservices also make a point to underline that having two completely separate apps require a readjustment in people's skills and responsibilities. The ideal scenario seems to be "each team is responsible for one or a few microservices".
That said, I have a few question for you olcay, that I can't surmise from your post:
I'm not saying you shouldn't do it, just do it if it makes sense and if you're ready to maintain two or more apps instead of one.
About microservice vs serverless... that really depends on what the app does. Maybe you'll end up with both, or maybe as it happens in some monolith apps you'll end up with a monolith and one or two serverless functions.
Can you disclose more info about the current architecture? Because "endpoint one receives 70% of the traffic" is not a good enough reason to split in my opinion, at least if you don't have any issues.
Possibly the most important principle of software architecture is "if it ain't broke, don't fix it"!
This. So much this.
Ahah definitely rule number one 😁
I was wondering if we can decrease the costs this way. Maybe we can benefit from using lambda functions for less used endpoints etc.
I don't know, without any detail about the app I can only be vague.
You said one endpoint amounts to 70% of the usage, but what about cost? Is it 70% of the cost? Maybe the second endpoint costs you a few dollars a month already. Which of the two endpoints you want to remove from the monolith?
Lambda has a generous free tier and there's a price calculator, maybe that can help you figure out how much are you going to spend if you migrate: aws.amazon.com/lambda/pricing/ and s3.amazonaws.com/lambda-tools/pric...
You should also add the cost of DBs and other tools if you need them: calculator.s3.amazonaws.com/index.... (you definitely need API Gateway if the lambda is web facing, so add at least that)
Keep in mind that using serverless means that your app might have the occasional cold start and you have 15 minutes of limit to finish the job. See all the limits: docs.aws.amazon.com/lambda/latest/...
Thank you so much for such a clear answer, I totally missed the point that more request does not mean more cost while considering endpoints. It depends on what that endpoint does. I see that now. Also, we have to have a single database so it would be a bottleneck anyways. As you said we should really measure and asses the cost of the current structure and decide if we benefit from any change.
Yeah keep in mind that you tackle things one step at the time. Two apps sharing the same DB because they access the same data is a distributed monolith. Two apps sharing the same db because they access completely different data could just be the first step in having separate microservices.
There's no wrong option, just one you can maintain and one you can't. You have to figure out how much you can split