5 ms·

The "adhoc" part is the problem. K8S is standardized and offers high-availability, failover, logging, monitoring, load balancing, networking, service discovery,

The "adhoc" part is the problem. K8S is standardized and offers high-availability, failover, logging, monitoring, load balancing, networking, service discovery, deployments, stateful services, storage volumes, batch jobs, etc. And it can run self-contained on a single machine or scale out to 1000 nodes. Why piece all of that functionality together yourself into some fragile framework instead of using a industry standard?

bschwindHN 6y ago
It can be worth it to piece things together yourself. A complex tool can also be fragile if you don't take the time to learn and understand every facet of it. If you only need certain parts of what k8s offers, building those parts yourself can offer you more stability, control, and insight into what your application is doing. As with anything else it varies case-by-case.
- p_l 6y ago
  Building it yourself is also a case of "resume-driven development". Not that there aren't good reasons or good outcomes from having done a deep dive, but just putting it there.
  - bschwindHN 6y ago
    I think using something like k8s prematurely is more an example of "resume driven development" than the other way around. Building it yourself doesn't mean building all of it. For example, it's quite easy to get zero downtime deployments with a tiny bit of systemd configuration and the SO_REUSEPORT socket option. That seems easier for a team to understand than "here is kubernetes and everything that comes with it"
    - p_l 6y ago
      That is, however, a very tiny slice of what might be needed. You need to deliver the application to the machines somehow. You might need to configure the network to reach the application, etc. All quite common tasks. (And honestly, systemd can bite you just as much if not worse than k8s definitions, because the API is much less cohesive and the defaults like to cut off your hands)
- ownagefool 6y ago
  Building one yourself is a good exercise for understanding something, I agree. The problem with that logic is everyone on your team will need to do it, so you're going to be stuck picking a standard. Should it be yours, should it be mine, or should we both just learn something with a large community behind it? Nothing is perfect of course, but k8s makes a really good target for CI/CD, which is something you want when you're developing as part of a team. If you're not quite a team yet and you don't know how to bootstrap k8s and CI/CD, then you need to figure out when those types of things are important. Probably lots of people could stick with a monolith and a VM for longer than they did, but automated testing will save you a fair bit of time if you're not figuring out how to do it at the same time.
spottybanana 6y ago
"Why piece all of that functionality together yourself into some fragile framework instead of using a industry standard?" Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. I personally would use the word "industry standard" a little bit differently.
- cameronbrown 6y ago
  > Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. k8s is based off of Borg, which has existed for far longer. https://research.google/pubs/pub43438/ https://research.google/pubs/pub43438/
  - vertex-four 6y ago
    "What Google does" is not an industry standard.
    - cameronbrown 6y ago
      That's not what I'm saying. Your point was about the maturity of k8s which makes sense if it sprung from nowhere, but k8s encapsulates a lot of "lessons learned" of a very stable and mature product (even if proprietary).
  - skj 6y ago
    Really it's just "inspired" by borg. Using both, they're really not very similar.
- manigandham 6y ago
  You still have to put them all together into some custom solution just for your setup which adds overhead and fragility. New employees will have to learn that instead of using K8S APIs. Deploying new components can’t take advantage of the wide and fast growing ecosystem. There’s really nothing like the full suite that kubernetes provides.
Juliate 6y ago
k8s is nice, yes. But, by its age, no more standardized now, than MySQL was 15 years ago. k8s also adresses a very small portion of the market. If you have to scale, yes, you might need k8s. Chances are, you don't. Really. I stopped counting the (supposedly big) customers that burnt themselves into k8s when they logistically need not to, and only brought organisational issues on them.

bschwindHN 6y ago

It can be worth it to piece things together yourself. A complex tool can also be fragile if you don't take the time to learn and understand every facet of it. If you only need certain parts of what k8s offers, building those parts yourself can offer you more stability, control, and insight into what your application is doing. As with anything else it varies case-by-case.

p_l 6y ago
Building it yourself is also a case of "resume-driven development". Not that there aren't good reasons or good outcomes from having done a deep dive, but just putting it there.
- bschwindHN 6y ago
  I think using something like k8s prematurely is more an example of "resume driven development" than the other way around. Building it yourself doesn't mean building all of it. For example, it's quite easy to get zero downtime deployments with a tiny bit of systemd configuration and the SO_REUSEPORT socket option. That seems easier for a team to understand than "here is kubernetes and everything that comes with it"
  - p_l 6y ago
    That is, however, a very tiny slice of what might be needed. You need to deliver the application to the machines somehow. You might need to configure the network to reach the application, etc. All quite common tasks. (And honestly, systemd can bite you just as much if not worse than k8s definitions, because the API is much less cohesive and the defaults like to cut off your hands)
ownagefool 6y ago
Building one yourself is a good exercise for understanding something, I agree. The problem with that logic is everyone on your team will need to do it, so you're going to be stuck picking a standard. Should it be yours, should it be mine, or should we both just learn something with a large community behind it? Nothing is perfect of course, but k8s makes a really good target for CI/CD, which is something you want when you're developing as part of a team. If you're not quite a team yet and you don't know how to bootstrap k8s and CI/CD, then you need to figure out when those types of things are important. Probably lots of people could stick with a monolith and a VM for longer than they did, but automated testing will save you a fair bit of time if you're not figuring out how to do it at the same time.

spottybanana 6y ago

"Why piece all of that functionality together yourself into some fragile framework instead of using a industry standard?" Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. I personally would use the word "industry standard" a little bit differently.

cameronbrown 6y ago
> Quite recently developed "industry standard". Many tools mentioned have been used for tens of years, they work robustly, are well documented and there is lots of people who can use them. k8s is based off of Borg, which has existed for far longer. https://research.google/pubs/pub43438/ https://research.google/pubs/pub43438/
- vertex-four 6y ago
  "What Google does" is not an industry standard.
  - cameronbrown 6y ago
    That's not what I'm saying. Your point was about the maturity of k8s which makes sense if it sprung from nowhere, but k8s encapsulates a lot of "lessons learned" of a very stable and mature product (even if proprietary).
- skj 6y ago
  Really it's just "inspired" by borg. Using both, they're really not very similar.
manigandham 6y ago
You still have to put them all together into some custom solution just for your setup which adds overhead and fragility. New employees will have to learn that instead of using K8S APIs. Deploying new components can’t take advantage of the wide and fast growing ecosystem. There’s really nothing like the full suite that kubernetes provides.

Juliate 6y ago

k8s is nice, yes. But, by its age, no more standardized now, than MySQL was 15 years ago. k8s also adresses a very small portion of the market. If you have to scale, yes, you might need k8s. Chances are, you don't. Really. I stopped counting the (supposedly big) customers that burnt themselves into k8s when they logistically need not to, and only brought organisational issues on them.