4 ms·

https://old.reddit.com/r/sysadmin/comments/1cqn3qa/whats_the_biggest_cpu_core_physical_server_i_can/l3t45a7/ https://old.reddit.com/r/sysadmin/comments/1cqn3qa/

https://old.reddit.com/r/sysadmin/comments/1cqn3qa/whats_the_biggest_cpu_core_physical_server_i_can/l3t45a7/ https://old.reddit.com/r/sysadmin/comments/1cqn3qa/whats_the... > The whole thing is about 10k APIs that all share the same cluster of 10 databases on the backend, which was never designed to scale like this. This company did 500 million revenue 2010 and now 15 billion this year, all running on this fking sql back end. They have a team of 500 devs writing for these apps, the complexity is unbelievable. No one knows how to untangle it and scale out to micro services.

shermantanktop 2y ago
Unfortunately the word “microservices” on HN brings out some low-quality discourse. Maybe this time will be different?
- pixl97 2y ago
  For this particular instance and company, no. Not because microservices can't work, but instead because of the coordination required between services/api/database that doesn't appear to exist at all in this company. This said, depending on your application and how it's split up quite often there are easy wins. An example I've seen is a company that had a huge batch reporting jobs for reporting at fixed intervals. Hammered the hell of out production, so was moved to pull data from a read only replica.
- rbanffy 2y ago
  It really depends on what they are doing. At this stage, I'd suspect it needs some major rearchitecture, but they accumulated so much tech debt it's difficult to say what next steps could be. As was pointed out by others, starting by introducing some strong governance practices would be a good start.
  - hot_gril 2y ago
    My department was in a bad single-DB position like this. The only way out was big rewrites, and generally each team had one service with its own DB in the end. Dunno if you'd call that microservices or not.
    - rbanffy 2y ago
      I would if they can have their own release cycles.
      - hot_gril 2y ago
        Then yes
- hot_gril 2y ago
  The important thing in these convos is to be clear each time what you mean by "microservices," because there isn't a solid definition for that. I've seen too many debates at work over whether we should use microservices, where both sides already agree on the actual design.
mamcx 2y ago
Adding micro-services is the way to make the company bankrupt. "micro-services" is the worst solution to ANY problem. Is not a solution, only another way to write a problematic app. The problem here is complexity and "micro-services" is the MOST efficient way to add complexity. And the real problem here is complexity X scalability, which requires simplicity and tunning, stuff that "micro-services" IS NOT mean to solve. --- I work in the enterprise space, and you bet you can cut 70%* (every time you find stuff like this) of the code and stay single-master-DB even for some very large companies if you have a half-decent architecture. p.d: Do note that cut code does not mean the app will end with just 30%, is just that 70% is trash to be redone.
- hot_gril 2y ago
  Are you saying that every company up to a certain size should have a single master DB?

shermantanktop 2y ago

Unfortunately the word “microservices” on HN brings out some low-quality discourse. Maybe this time will be different?

pixl97 2y ago
For this particular instance and company, no. Not because microservices can't work, but instead because of the coordination required between services/api/database that doesn't appear to exist at all in this company. This said, depending on your application and how it's split up quite often there are easy wins. An example I've seen is a company that had a huge batch reporting jobs for reporting at fixed intervals. Hammered the hell of out production, so was moved to pull data from a read only replica.
rbanffy 2y ago
It really depends on what they are doing. At this stage, I'd suspect it needs some major rearchitecture, but they accumulated so much tech debt it's difficult to say what next steps could be. As was pointed out by others, starting by introducing some strong governance practices would be a good start.
- hot_gril 2y ago
  My department was in a bad single-DB position like this. The only way out was big rewrites, and generally each team had one service with its own DB in the end. Dunno if you'd call that microservices or not.
  - rbanffy 2y ago
    I would if they can have their own release cycles.
    - hot_gril 2y ago
      Then yes
hot_gril 2y ago
The important thing in these convos is to be clear each time what you mean by "microservices," because there isn't a solid definition for that. I've seen too many debates at work over whether we should use microservices, where both sides already agree on the actual design.

mamcx 2y ago

Adding micro-services is the way to make the company bankrupt. "micro-services" is the worst solution to ANY problem. Is not a solution, only another way to write a problematic app. The problem here is complexity and "micro-services" is the MOST efficient way to add complexity. And the real problem here is complexity X scalability, which requires simplicity and tunning, stuff that "micro-services" IS NOT mean to solve. --- I work in the enterprise space, and you bet you can cut 70%* (every time you find stuff like this) of the code and stay single-master-DB even for some very large companies if you have a half-decent architecture. p.d: Do note that cut code does not mean the app will end with just 30%, is just that 70% is trash to be redone.

hot_gril 2y ago
Are you saying that every company up to a certain size should have a single master DB?