HI Tom - Interesting blog, but I take exception to one key point you make. You talk about "nail it" before you "scale it". There is kind of an underlying assumption that whatever you nail will be able to scale. Scalability fails when a system runs out of resources, but that does not mean you can just throw resources at a system to get unlimited scale. There are LOTS of places where more resources won't help scaling at all. (See my blog on this here (https://g4as.substack.com/p/why-is-deepseek-so-cheap)). This doesn't mean you can't 'nail it' without considering eventual scaling. The system may never get to that point of resource constraint. But keep in mind the more valuable the results produced, the more likely high levels of scaling may be required. And for this, you may have to go back and reimplement everything - you know, all the work you skipped the first time through. It's an inherent risk you take if you do not plan for scaling at the outset.
One prime example of this is in your data design. Access may not be a problem at lower levels of scale, but can cripple your system as you scale.
Like I said, it may be OK to skip the scaling considerations, but when you hit that wall, it hurts.
Right, Rick. I wasn't suggesting that researchers ignore scaling. I meant to suggest that a focus on nailing it (improving design for greater performance) shouldn't get buried in a march towards growing the scale of the system. Your points are well taken in that context. Cheers,
HI Tom - Interesting blog, but I take exception to one key point you make. You talk about "nail it" before you "scale it". There is kind of an underlying assumption that whatever you nail will be able to scale. Scalability fails when a system runs out of resources, but that does not mean you can just throw resources at a system to get unlimited scale. There are LOTS of places where more resources won't help scaling at all. (See my blog on this here (https://g4as.substack.com/p/why-is-deepseek-so-cheap)). This doesn't mean you can't 'nail it' without considering eventual scaling. The system may never get to that point of resource constraint. But keep in mind the more valuable the results produced, the more likely high levels of scaling may be required. And for this, you may have to go back and reimplement everything - you know, all the work you skipped the first time through. It's an inherent risk you take if you do not plan for scaling at the outset.
One prime example of this is in your data design. Access may not be a problem at lower levels of scale, but can cripple your system as you scale.
Like I said, it may be OK to skip the scaling considerations, but when you hit that wall, it hurts.
Right, Rick. I wasn't suggesting that researchers ignore scaling. I meant to suggest that a focus on nailing it (improving design for greater performance) shouldn't get buried in a march towards growing the scale of the system. Your points are well taken in that context. Cheers,