4 ms·

The k8s evangelists are operating under the assumption that if your product or service is successful, you're probably going to want to scale it, and if you beli

The k8s evangelists are operating under the assumption that if your product or service is successful, you're probably going to want to scale it, and if you believe in that vision, then you're probably going to want to think about k8s early in your project, not when you've grown it to millions of users worldwide. But I get what you mean.

alemanek 2y ago
I know you are advocating that position. But, I have seen lots of failed projects because of that thinking. They failed to get to customer #1 because they were building something to handle customer #1,000,000. Unless you are building something that can kill people if it goes wrong just get it out the door and be as disciplined as you can along the way. If it is successful then you have the money to split it up into a SoA when you need it.
- Muromec 2y ago
  There are some none obvious ways to kill people with bad API design even if you don’t work in a medical industry and don’t deal with heavy machinery. Corners being cut here and there, context gets lost, then it gets reused in a (non)obviously inappropriate and suboptimal way and somebody indeed dies. Please take effort and do quality stuff as if your life depends on it.
- CuriouslyC 2y ago
  There's a balance. Scope creep and solving engineering problems you don't have are obviously really bad, but too many people see the bell curve meme for tech stacks and lean into stupid. When building something, you want to take a step back and consider some of the most likely places that thing will evolve to, then architect the software to make those transitions/evolutions easy. That way even if you build the wrong thing, you don't have to start from scratch, instead you've created a ratchet of progress that makes each pivot faster and easier.
  - alemanek 2y ago
    Oh yeah I agree. That is why I put in their “be as disciplined as you can be along the way”. If it never ships what’s the point; but if you ship something that has to be rewritten right away it’s almost as bad.
marcosdumay 2y ago
That assumption that you will want to scale does not always hold; The assumption that you want to scale into millions of users do not always hold; The assumption that you need kubernetes to scale into millions of users (or that you will even want it) does not always hold; The assumption that solving that problem from the start leads to a better outcome than waiting that the problem appears has "winning the lottery" odds of not being the opposite of the truth.
- elktown 2y ago
  The amount of assumptions involved in all these really suggests it's mostly rationalization doesn't it? It's absolutely perfectly fine to scale to millions of users with yesterday's proven simple tech using the benefits of time passed. You got everything that was hard before in managed services, why start complicating the simplest part (stateless app servers) now that we've got everything served on a platter? I reckon 99% of the apps HN talks about that needs to "scale" can do it with VMs behind a load balancer, a cache, and a relational database. All of these are now available as managed services. Not to mention that you now got tailor made languages for it like Go that compiles to a simple single binary for your VMs to just kick off. Use the progress instead of trying to be clever. I mean, if actually producing a product is the goal, rather than a vehicle to unnecessarily squeeze in the latest tech into. There's no need to make a big up-front investment in building a platform on top of k8s etc. Spend the time on the product instead. And if you turn out to be in the 1% that's a good problem to have, and no, it won't be over night, so you're fine.
  - marcosdumay 2y ago
    I wouldn't say it's rationalization. Surviving the initial scaling is an horrible experience, full of technical gotchas. People that have seen that will naturally want to avoid it. The problem is that it's an irrational desire, because what they do to avoid it destroys most of their chances to even get there. It looks like a manifestation of the second system syndrome.
    - elktown 2y ago

alemanek 2y ago

I know you are advocating that position. But, I have seen lots of failed projects because of that thinking. They failed to get to customer #1 because they were building something to handle customer #1,000,000. Unless you are building something that can kill people if it goes wrong just get it out the door and be as disciplined as you can along the way. If it is successful then you have the money to split it up into a SoA when you need it.

Muromec 2y ago
There are some none obvious ways to kill people with bad API design even if you don’t work in a medical industry and don’t deal with heavy machinery. Corners being cut here and there, context gets lost, then it gets reused in a (non)obviously inappropriate and suboptimal way and somebody indeed dies. Please take effort and do quality stuff as if your life depends on it.
CuriouslyC 2y ago
There's a balance. Scope creep and solving engineering problems you don't have are obviously really bad, but too many people see the bell curve meme for tech stacks and lean into stupid. When building something, you want to take a step back and consider some of the most likely places that thing will evolve to, then architect the software to make those transitions/evolutions easy. That way even if you build the wrong thing, you don't have to start from scratch, instead you've created a ratchet of progress that makes each pivot faster and easier.
- alemanek 2y ago
  Oh yeah I agree. That is why I put in their “be as disciplined as you can be along the way”. If it never ships what’s the point; but if you ship something that has to be rewritten right away it’s almost as bad.

marcosdumay 2y ago

That assumption that you will want to scale does not always hold; The assumption that you want to scale into millions of users do not always hold; The assumption that you need kubernetes to scale into millions of users (or that you will even want it) does not always hold; The assumption that solving that problem from the start leads to a better outcome than waiting that the problem appears has "winning the lottery" odds of not being the opposite of the truth.

elktown 2y ago
The amount of assumptions involved in all these really suggests it's mostly rationalization doesn't it? It's absolutely perfectly fine to scale to millions of users with yesterday's proven simple tech using the benefits of time passed. You got everything that was hard before in managed services, why start complicating the simplest part (stateless app servers) now that we've got everything served on a platter? I reckon 99% of the apps HN talks about that needs to "scale" can do it with VMs behind a load balancer, a cache, and a relational database. All of these are now available as managed services. Not to mention that you now got tailor made languages for it like Go that compiles to a simple single binary for your VMs to just kick off. Use the progress instead of trying to be clever. I mean, if actually producing a product is the goal, rather than a vehicle to unnecessarily squeeze in the latest tech into. There's no need to make a big up-front investment in building a platform on top of k8s etc. Spend the time on the product instead. And if you turn out to be in the 1% that's a good problem to have, and no, it won't be over night, so you're fine.
- marcosdumay 2y ago
  I wouldn't say it's rationalization. Surviving the initial scaling is an horrible experience, full of technical gotchas. People that have seen that will naturally want to avoid it. The problem is that it's an irrational desire, because what they do to avoid it destroys most of their chances to even get there. It looks like a manifestation of the second system syndrome.
  - elktown 2y ago