top | item 45364238

(no title)

fladrif | 5 months ago

What's the alternative?

discuss

order

mrngm|5 months ago

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|5 months ago

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|5 months ago

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|5 months ago

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?

9rx|5 months ago

Funnily enough, microservices. In the macro economy you don't have to have such strict coordination with Microsoft, or OpenAI, or Google, or whomever you interface with. You just figure out how to make your solution work within the confines of the service they give you. Like it or not.

Microservices is exactly the same concept except in the micro economy of a single organization. Each team is like Microsoft, OpenAI, Google, etc. You don't coordinate with them, you deal with what they give you. Like it or not.

I expect the earlier statement confused microservices with a multi-process application.

latentsea|5 months ago

Except you totally do wind up coordinating with them in practice when it's not google but a small team within your org.

moffkalast|5 months ago

Macroservices, or several megaliths instead of one monolith, if you will.

Rendello|5 months ago

What about going the other way and Unix-piping together hundreds of thousands of nano-services?

stuartaxelowen|5 months ago

I love the distribution of answers to this.