top | item 34231658

(no title)

strictfp | 3 years ago

Yes. If you design a distributed system you need to consider the network traffic very carefully, and choose your segmentation in such a way that you minimize traffic and still achieve good scalability.

For this reason, I've been trying to push for building a monolithic app first, then splitting into components, and introducing libs for common functionality. Only when this is all done, you think about the communication patterns and discuss how to scale the app.

Most microservice shops I've been in have instead done the naïve thing; just come up with random functionally separate things and put them in different micro services; "voting service", "login service", "user service" etc. This can come with a very very high price. Not only in terms of network traffic, but also in debuggability, having a high amount of code duplication, and getting locked into the existing architecture, cementing the design and functionality.

discuss

order

vaughan|3 years ago

> Only when this is all done, you think about the communication patterns and discuss how to scale the app.

The main thing is that regardless of scaling, the app should always be able to run/debug/test locally in a monolithic thing.

Once people scale they seem to abandon the need to debug locally at their peril.

Scaling should just be a process of identifying hot function calls and when a flag is set, to execute a call as a network rpc instead.

c-fe|3 years ago

Everything you mention (network traffic cost, code duplication (we instead resorted to auto-generate some shared code between services based on a open-api spec), locked into the architecture) applies to our use case...

And it is reassuring to hear that you seem to have success in avoiding these issues with a monolithic architecture, as I thought I was oldschool for starting to prefer monoliths again.