4 ms·
_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web
by Scarblac 3y ago
_Services_ are obviously a good idea (nobody is arguing something like PostgreSQL or Redis or DNS or what have you should all run in the same process as the web server).
_Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.
- xnorswap 3y agoThat may be true, but the article describes a services architecture and labels it microservices, indeed goes onto to say: > The term micro can be misleading, though - there doesn’t have to be anything micro about the services
- Scarblac 3y agoYes, but the "widespread meme" as I see it is about microservices, not services in general.
- butlerm 3y agoThe smaller the service, the more likely that the overhead of having a separate service exceeds the benefit of doing so. It isn't at all normal for a service to have its own database unless it provides a substantial piece of functionality, for example, and there are non-trivial costs to splitting databases unnecessarily. If you are not very careful, it is a good way to make certain things a dozen times slower and a dozen times more expensive to develop.
- mjr00 3y agoIt's funny because the term "microservices" picked up in popularity because previously, most "service-oriented architecture" (the old term) implementations in large companies had services that were worked on by dozens or hundreds of developers, at least in my experience. So going from that to services that were worked on by a single development team of ~10 people was indeed a "microservice" relatively speaking. Now, thanks to massive changes in how software is built (cloud, containers et al) it's a lot more standard for a normal "service" with no prefix to be built by a small team of developers, no micro- prefix needed.
- Scarblac 3y agoI can understand wanting to split things off so that one team handles one service, roughly. There was a recent thread here where someone mentioned he personally was responsible for about four of their microservices...
- nicoburns 3y agoYeah, my last company had 10 microservices (the entirety of their codebase) managed by a single team when I started. Some of them had fewer than 5 API endpoints (and weren't doing anything complex to justify that).
- deleted 3y ago[deleted]
- jeffbee 3y agoThis seems subjective. It's like putting "compatible with the character of the neighborhood" in a city's zoning codes.
- arethuza 3y agoYou do see people arguing for running SQLite in-process rather than using a separate database server like PostgreSQL?