• falsem@kbin.social
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Scaling a well written system just requires throwing more hardware at said system. Yeah, you could tune it and tweak it, but that isn’t an ongoing and constant process.

    Okay yeah, this conversation obviously isn’t going anywhere if you think the solution to scaling into hundreds of millions of users is just throwing hardware at the problem lol.

    Can you tell me that last major feature added to the Play Store?

    https://android-developers.googleblog.com/2023/11/power-your-growth-on-google-play.html

    • KairuByte@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      You can’t throw hardware at a scaling problem if the scaling problem is related to badly written code. Conversely, you can’t throw development at a scaling problem, if the problem is a hardware limitation.

      If you take good code, which is already written to account for scaling, and it needs to be scaled up, what is it you think they do? Rewrite the code? Tweak the code over and over? No, they deploy a second server to employ load balancing.

      Look at it this way, if more hardware is never the solution, you’re telling me I can run any code at any scale on my rPi4? Since that’s obviously not what you meant, it pretty easily proves that sometimes the answer is more hardware.

      And fair enough on further development, I legitimately wasn’t aware. That said, I doubt that cost isn’t already rolled into the 30% cost referred to in the article. While the original user was arguing an unaccounted for $100 million “initial cost” that was still being “paid off.” I may have dug into that initial comment too much when making my statements.