4 ms·

That's a bit distressing. Most everywhere I've worked, the infrastructure that matters to the business has fallen into roughly two categories: Category 1: stat

That's a bit distressing. Most everywhere I've worked, the infrastructure that matters to the business has fallen into roughly two categories: Category 1: stateless-"ish" workloads. More than 90% of hosts/containers used . . . less than 25% of operations headaches and time. Issues that happen here are solvable with narrow solutions: add caches, scale out, do very targeted, transparent fixes to poorly-performing application code. Category 2: stateful workloads. Less than 10% of hosts/containers. 75% or more of operations headaches and time. Issues that happen here have less visibility, fewer short-term fixes ("just add an index and turn off the bad queries" only works so many times before you're out of low-hanging fruit), and require more expertise to solve in a way that doesn't require the application/clients to change. If k8s and other next-gen technologies are only easing the first category, that makes me sad. It's like we have this sedan (off-the-shelf web technologies) that we have to take off-roading and it falls apart all the time. I don't want a better air conditioning system and more cushions in my seats; I want the vehicle to not break.

wereHamster 8y ago
In k8s you can easily host stateful services. You have persistent disks that you can attach to containers, and you also have StatefulSets if you have a stateful service that you want to have automatically scaled (https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ https://kubernetes.io/docs/concepts/workloads/controllers/st...). You can use both to run a database (postgres) for example.
- zaat 8y ago
  I thought that this was the case too, but OP had a link (https://gravitational.com/blog/running-postgresql-on-kubernetes/ https://gravitational.com/blog/running-postgresql-on-kuberne...) to previous post that got me worried.
  - outworlder 8y ago
    From TFA > Kubernetes is not aware of the deployment details of Postgres. A naive deployment could lead to complete data loss. That sounds ominous, but is actually a tautology. You have the exact same challenges anywhere else, but since K8s makes some operations so easy to do, you need to be careful. RDBMs are specially tricky because most of them expect a single "master" which holds special status. And it so happens to hold all your data too (as do your replicas, provided they are up to date).
thraxil 8y ago
K8s and similar represent a current view on how systems should be designed and run from the ground up (largely based on the same observations you have made that the stateless workloads can be run with drastically less operational problems). If your architecture lines up with this approach (eg, following the 12-factor approach), there really are a lot of advantages. But no, legacy architected applications are just not going to benefit in the same way. I assume that there must be consultants and "thought leaders" out there who are pushing k8s and containerization as silver bullets and that's unfortunate.
mdekkers 8y ago
require more expertise to solve in a way that doesn't require the application/clients to change. Surprise! IT is hard and requires experts. Either hire one, or become one, but either way, the idea that "nobody in my enterprise/company/team need to understand the details of how stuff works" is crazy. Imagine a car-mechanic shop where nobody knows how an engine works: "we plugged in the computer tool, and it said something is wrong with your engine. I guess you need a new one"
- zbentley 8y ago
  Yes, it is. But tooling can improve that. For example: having worked on DB2 and Postgres, and I'd choose Postgres for any new work barring extremely unique constraints--not because it means "I don't have to understand the details of how stuff works", but because it exposes how stuff works in a more intelligible, powerful, and useful way. Tools improve. Sometimes they repeat past mistakes--I'd pick Postgres over Hadoop/HBase too, until considerable duress. But sometimes? Sometimes tools learn from past mistakes--use those tools. Not everyone complaining about the deficiencies of current-gen tools is doing so out of ignorance or laziness about their stack.
brianwawok 8y ago
k8s solves state pretty well lately, but that doesn't mean you need to move everything into your cluster. I use k8s for bin packing and easy rolling deployments. Neither of which matter for my DB (i.e. no such thing as an easy rolling postgres deployment (maybe citris?)), and I am not going to put anything else on my database server... so no bins to pack. If you are doing one or the other, then sure worry about it from a k8s sense. But don't throw stuff in k8s for no reason. It makes stuff like rolling upgrades of your cluster way more scary.

wereHamster 8y ago

In k8s you can easily host stateful services. You have persistent disks that you can attach to containers, and you also have StatefulSets if you have a stateful service that you want to have automatically scaled (https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ https://kubernetes.io/docs/concepts/workloads/controllers/st...). You can use both to run a database (postgres) for example.

zaat 8y ago
I thought that this was the case too, but OP had a link (https://gravitational.com/blog/running-postgresql-on-kubernetes/ https://gravitational.com/blog/running-postgresql-on-kuberne...) to previous post that got me worried.
- outworlder 8y ago
  From TFA > Kubernetes is not aware of the deployment details of Postgres. A naive deployment could lead to complete data loss. That sounds ominous, but is actually a tautology. You have the exact same challenges anywhere else, but since K8s makes some operations so easy to do, you need to be careful. RDBMs are specially tricky because most of them expect a single "master" which holds special status. And it so happens to hold all your data too (as do your replicas, provided they are up to date).

thraxil 8y ago

K8s and similar represent a current view on how systems should be designed and run from the ground up (largely based on the same observations you have made that the stateless workloads can be run with drastically less operational problems). If your architecture lines up with this approach (eg, following the 12-factor approach), there really are a lot of advantages. But no, legacy architected applications are just not going to benefit in the same way. I assume that there must be consultants and "thought leaders" out there who are pushing k8s and containerization as silver bullets and that's unfortunate.

mdekkers 8y ago

require more expertise to solve in a way that doesn't require the application/clients to change. Surprise! IT is hard and requires experts. Either hire one, or become one, but either way, the idea that "nobody in my enterprise/company/team need to understand the details of how stuff works" is crazy. Imagine a car-mechanic shop where nobody knows how an engine works: "we plugged in the computer tool, and it said something is wrong with your engine. I guess you need a new one"

zbentley 8y ago
Yes, it is. But tooling can improve that. For example: having worked on DB2 and Postgres, and I'd choose Postgres for any new work barring extremely unique constraints--not because it means "I don't have to understand the details of how stuff works", but because it exposes how stuff works in a more intelligible, powerful, and useful way. Tools improve. Sometimes they repeat past mistakes--I'd pick Postgres over Hadoop/HBase too, until considerable duress. But sometimes? Sometimes tools learn from past mistakes--use those tools. Not everyone complaining about the deficiencies of current-gen tools is doing so out of ignorance or laziness about their stack.

brianwawok 8y ago

k8s solves state pretty well lately, but that doesn't mean you need to move everything into your cluster. I use k8s for bin packing and easy rolling deployments. Neither of which matter for my DB (i.e. no such thing as an easy rolling postgres deployment (maybe citris?)), and I am not going to put anything else on my database server... so no bins to pack. If you are doing one or the other, then sure worry about it from a k8s sense. But don't throw stuff in k8s for no reason. It makes stuff like rolling upgrades of your cluster way more scary.