4 ms·

Maybe "cheating" isn't a good way to put it. It just seems like you're narrowing the scope of what k8s is often used for, and then calling it simple and easy.

by thunky 4y ago

Maybe "cheating" isn't a good way to put it. It just seems like you're narrowing the scope of what k8s is often used for, and then calling it simple and easy. It'd be like someone saying: "<language> can be as simple or complex as you want it do be: it's actually really easy to write hello world. You should steer clear for anything more complex than that". Well sure, but that's not a great way to convey it's overall complexity. But I actually agree with your underlying point. I don't see the benefit or running a db on k8s either. Seems like a lot of extra complexity for little to no benefit.

cogman10 4y ago
> It just seems like you're narrowing the scope of what k8s is often used for, and then calling it simple and easy. I mean, to me, that's what it means to simplify. Even in this post, I see people saying "Hey, it's not actually hard to run postgres in k8s" which, ok, maybe? IDK, seemed like not a great idea to me with the complexity of volume mounts and drivers along with adding extra networking in order to hook it all together. > <language> can be as simple or complex as you want it do be: it's actually really easy to write hello world. You should steer clear for anything more complex than that To some extent, that's exactly what I'm saying. I'd argue you can make things more featureful than "hello world" with stateless pods and you can get a lot of benefit out of those. Just like I'd tell a new Java dev "Hey, java is simple, so long as you don't use features like the LambdaMetaFactory, Reflection, or the annotation processor. Some people use those, but IMO they are mostly off limits" Just because something HAS complex features doesn't mean you should use them (or that using them is a great idea) > But I actually agree with your underlying point. I don't see the benefit or running a db on k8s either. Seems like a lot of extra complexity for little to no benefit. And who knows, maybe this is my (our?) inexperience with k8s shining through. Maybe running postgres on k8s is actually highly beneficial. I've just not been convinced that's better than doing something like amazon's RDS or Aurora. The headache of setting up ceph or rook or whatever just seems like a pretty high burden for a pretty low payback. To me, it's features like deployment rollouts, common logging infrastructure, autoscaling, certificate management/distribution, and recovery that are attractive to k8s and all come mostly out of the box.
- thunky 4y ago
  Fair enough. I suppose if more people precisely qualified how & why they use k8s while advocating for it, I'd probably have a better overall view of it rather than assuming it's the blessed solution for every use case it targets.

by thunky 4y ago

cogman10 4y ago

> It just seems like you're narrowing the scope of what k8s is often used for, and then calling it simple and easy. I mean, to me, that's what it means to simplify. Even in this post, I see people saying "Hey, it's not actually hard to run postgres in k8s" which, ok, maybe? IDK, seemed like not a great idea to me with the complexity of volume mounts and drivers along with adding extra networking in order to hook it all together. > <language> can be as simple or complex as you want it do be: it's actually really easy to write hello world. You should steer clear for anything more complex than that To some extent, that's exactly what I'm saying. I'd argue you can make things more featureful than "hello world" with stateless pods and you can get a lot of benefit out of those. Just like I'd tell a new Java dev "Hey, java is simple, so long as you don't use features like the LambdaMetaFactory, Reflection, or the annotation processor. Some people use those, but IMO they are mostly off limits" Just because something HAS complex features doesn't mean you should use them (or that using them is a great idea) > But I actually agree with your underlying point. I don't see the benefit or running a db on k8s either. Seems like a lot of extra complexity for little to no benefit. And who knows, maybe this is my (our?) inexperience with k8s shining through. Maybe running postgres on k8s is actually highly beneficial. I've just not been convinced that's better than doing something like amazon's RDS or Aurora. The headache of setting up ceph or rook or whatever just seems like a pretty high burden for a pretty low payback. To me, it's features like deployment rollouts, common logging infrastructure, autoscaling, certificate management/distribution, and recovery that are attractive to k8s and all come mostly out of the box.

thunky 4y ago
Fair enough. I suppose if more people precisely qualified how & why they use k8s while advocating for it, I'd probably have a better overall view of it rather than assuming it's the blessed solution for every use case it targets.