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?
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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