DEV Community

What can I do in terms of architecture?

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)

Collapse
 
rhymes profile image
rhymes • Edited

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:

  • what problems do you currently have?
  • what are you hoping to gain by splitting the app? Is it about a better allocation of resources? Is it about having two services that can scale independently?
  • are there any constraints? Keep in mind that, if split in multiple parts, each app will have their own backing database and so on. Does the functionality of this popular endpoint depend on something that's going to be duplicated in both apps? Because in that case you'll either end up with a monolith again or have to figure out the correct boundaries and likely create more services that endpoint one and two will use.

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.

Collapse
 
dmfay profile image
Dian Fay

Possibly the most important principle of software architecture is "if it ain't broke, don't fix it"!

Collapse
 
theycallmenucci profile image
Steve Antonucci

This. So much this.

Collapse
 
rhymes profile image
rhymes

Ahah definitely rule number one 😁

Collapse
 
olckara profile image
πš˜πš•πšŒπšŠπš’ • Edited

I was wondering if we can decrease the costs this way. Maybe we can benefit from using lambda functions for less used endpoints etc.

Collapse
 
rhymes profile image
rhymes

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/...

Thread Thread
 
olckara profile image
πš˜πš•πšŒπšŠπš’

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.

Thread Thread
 
rhymes profile image
rhymes

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