[mrngm]

https://news.ycombinator.com/item?id=43925892 "Microservices are a tax your startup probably can't afford" (310 points, 263 comments).

First build the thing that works, and only if it's really necessary, split it up in separate (networked) parts. You won't have to deal with unreliable network communication, or coordinate on a breaking API change with several teams when a simple search/replace on several function definitions and calls suffices.

[tombert]

I agree, though well designed software, even big monoliths, can be written in a way that isn't too hard to distribute later.

For example, if you utilize asynchronous queues everywhere, instead of something like a shared-memory mutex, it's relatively straightforward to turn that into some kind of networked queue system if you need to. Pretty much every language has a decent enough queue implementation available.

[BenoitEssiambre]

Asynchronous queues make your data out of sync (hence the name) and inconsistent one of the main downsides of microservices. Their use should be minimized to cases where they are really necessary. A functional transactional layer like postgres is the solution to make your state of truth accessed in a synchronized, atomic, consistent way.

[BenoitEssiambre]

To add to this. There's fundamental theoretical reasons why microservices or bad. They increase the entropy of code (https://benoitessiambre.com/entropy.html) by increasing globally scoped dependencies. They are the global variables or architecture. Having lots of interconnected global variables makes for an unpredictable chaotic system.

[Etheryte]

This doesn't actually answer the question in any way though. Say you've already built the thing that works and then split it up, then what?