18 ms·

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.

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.

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.