4 ms·

I work at a company that uses a hybrid monolith/service approach to serve millions and millions and millions of users. Unless you work for one of the top-top-to

I work at a company that uses a hybrid monolith/service approach to serve millions and millions and millions of users. Unless you work for one of the top-top-top social networks we probably serve many more users that your systems do. And even our existing services are not "micro": they are relatively large, and were mostly extracted to handle tasks that needed a different language. This massive code base is a very good example of how most people can do just fine with a monolith. I even learned to appreciate this uniform approach to things: monorepo, unified ci/cd process, shared responsibility.

saberience 6y ago
This comment shows an extreme naïveté. Just because at your anecdotal example, a monolith, works, it does not mean that it always works. There is a time and a place for every kind of design. There are many different kinds of applications and the number of users isn't the only factor when trying to understand the optimal architecture. In many cases you can have lots of users but what the application is doing is relatively simple, especially in terms of the data access patterns, state, etc. At other companies, they might have low numbers of users, but extreme requirements in terms of latency or data integrity (e.g. HFT applications or bank ledgers) Look for example at the requirements of Netflix (obviously lots of users) versus the requirements for Reddit (also lots of users). Both sites have high usage but have completely different use-cases and as such, their architectures will be radically different. I've also worked for a company with insanely high numbers of concurrent users (along with very sensitive latency requirements), and one where I'm sure performance was more critical than your systems, and we didn't use a monolith. There's no way that company could operate with a single monolith for the various products. Again, this is just an anecdote, just like yours, and just as meaningless.
- vkazanov 6y ago
  Yes, sure, we need better definitions and a limited scope. I also don't think ppl would have a monolith vs numerous services discussion in HFT or MMO game development or a major search engine development context. It seems that we're talking about typical web apps, shared mobile app backends, etc. I believe that most code developed with this use-case in mind doesn't have to know anything outside of the usual 3 layers: client-side, server-side (aka "the monolith) and a database backend.
throwaway9870 6y ago
I don't think the number of users has as much to do with partitioning a system as the variety of required tasks does.

saberience 6y ago

This comment shows an extreme naïveté. Just because at your anecdotal example, a monolith, works, it does not mean that it always works. There is a time and a place for every kind of design. There are many different kinds of applications and the number of users isn't the only factor when trying to understand the optimal architecture. In many cases you can have lots of users but what the application is doing is relatively simple, especially in terms of the data access patterns, state, etc. At other companies, they might have low numbers of users, but extreme requirements in terms of latency or data integrity (e.g. HFT applications or bank ledgers) Look for example at the requirements of Netflix (obviously lots of users) versus the requirements for Reddit (also lots of users). Both sites have high usage but have completely different use-cases and as such, their architectures will be radically different. I've also worked for a company with insanely high numbers of concurrent users (along with very sensitive latency requirements), and one where I'm sure performance was more critical than your systems, and we didn't use a monolith. There's no way that company could operate with a single monolith for the various products. Again, this is just an anecdote, just like yours, and just as meaningless.

vkazanov 6y ago
Yes, sure, we need better definitions and a limited scope. I also don't think ppl would have a monolith vs numerous services discussion in HFT or MMO game development or a major search engine development context. It seems that we're talking about typical web apps, shared mobile app backends, etc. I believe that most code developed with this use-case in mind doesn't have to know anything outside of the usual 3 layers: client-side, server-side (aka "the monolith) and a database backend.

throwaway9870 6y ago

I don't think the number of users has as much to do with partitioning a system as the variety of required tasks does.