4 ms·

In theory there's no difference between theory and practice, but in practice there is. With a stable operator it's theoretically similar, but it is not the sam

by vasco 4y ago

In theory there's no difference between theory and practice, but in practice there is. With a stable operator it's theoretically similar, but it is not the same, by any stretch, if only because I guarantee your incident rate will be higher when performing changes to the database, all other factors being similar. You now are also exposed to a bunch of other changes, the shenanigans of k8s networking, a missing daemonset, someone was tweaking istio that messed everything... The argument of "don't run it on k8s" isn't because you can't run it physically. It's because all those other things are going to increase your failure rate, and those failures will be way more complex to solve and so your time to recovery will also go up. You'll have to deal with this complexity already for the things that Kubernetes is going to give you actual benefits on, doing databases should be at the bottom of that list. Use your complexity budget wisely. If you're already at the bottom of the list, you look at your team and you go "we have extra capacity and are very confortable with the complexity of our current incidents", go ahead, likely it is the right time for you if you like adventure.

Jensson 4y ago
Practice that beats theory is just a new theory, so practice can't beat theory, it can only beat out of date or simplistic theories. I understand what the saying means, but it gives people so many bad ideas about the value of theories and science or how to work with them. In practice you start out based on general and overly simplistic theories, and then expand the theories in the direction you need to solve your problems, and then that creates a new theory you base your practice around. Wandering around willy-nilly without testing isn't good practice, while going deliberately with lots of testing and logic is what we mean when we talk about theory.
- kqr 4y ago
  There can still be a difference between practise and a(n insufficient) theory without there being a new theory superseding the old one. A lot of historical developments take this shape: we discover something not predicted by the theory we though would explain it, work on it for a while, and only later do we find the new theory that explains also the novel thing. For practise to be condensed into theory requires predictive power, and not all differences between practise and a theory are predictable -- yet. That said, I agree with your overall point. If one finds a difference between practise and theory, it's because one tried to use the wrong theory for the situation at hand.
- slfnflctd 4y ago
  Emerging practice is the ground theory hasn't covered yet. You are correct, though, in that if you want to make these practices more useful and grow your overarching theory, they absolutely must be approached with lots of testing and logic. The trick is knowing where it's most important to do this & when. Many areas of practice are left untouched by theory because there is no obvious compelling benefit.
romankolpak 4y ago
> Use your complexity budget wisely Well said
lokar 4y ago
If you run everything else on k8s having just one way to manage things makes life less complex. Running an app with state (db, storage, etc) in like this is not that hard. We ran all of the low level storage on borg at google when I was there. It worked well.
- hdjjhhvvhga 4y ago
  Let's say a new Kubernetes version comes out in April. In November, as everything works perfectly well, you decide to install a Postgres operator on it. Bummer, it doesn't work. It's not a huge issue, you just wait until the bug is resolved (already done[0]), but it's just one of these tiny things that I don't get when running Postrges natively. And I'm saying this as a big fan of Crunchy Data running some production loads on it without a failure for quite some time now. [0] https://github.com/CrunchyData/postgres-operator/issues/3476 https://github.com/CrunchyData/postgres-operator/issues/3476
  - thunky 4y ago
    And that repo you linked to has 1846 issues, 161 open. Which doesn't seem extraordinary based on my limited exposure to k8s. Another example: https://github.com/zalando/postgres-operator/issues https://github.com/zalando/postgres-operator/issues with 445 open issues. Why? Maybe I'm wrong and this is all a good sign of progress, but my impression is that the entire k8s ecosystem is held together with reused duct tape.
    - Too 4y ago
      Look at the feature-list of that repo. Half of it are actually deficiencies in postgres that warrants the external complexities, not something induced by kubernetes. Sure, a lot of it is nice-to-haves but some are absolutely essential for even a basic postgres deployment even if you used VMs... Like, why is replication so difficult, why do i need all these extensions and why do i need to deploy a bouncer as a separate service in 2023?!
      - 4y ago

by vasco 4y ago

Jensson 4y ago

Practice that beats theory is just a new theory, so practice can't beat theory, it can only beat out of date or simplistic theories. I understand what the saying means, but it gives people so many bad ideas about the value of theories and science or how to work with them. In practice you start out based on general and overly simplistic theories, and then expand the theories in the direction you need to solve your problems, and then that creates a new theory you base your practice around. Wandering around willy-nilly without testing isn't good practice, while going deliberately with lots of testing and logic is what we mean when we talk about theory.

kqr 4y ago
There can still be a difference between practise and a(n insufficient) theory without there being a new theory superseding the old one. A lot of historical developments take this shape: we discover something not predicted by the theory we though would explain it, work on it for a while, and only later do we find the new theory that explains also the novel thing. For practise to be condensed into theory requires predictive power, and not all differences between practise and a theory are predictable -- yet. That said, I agree with your overall point. If one finds a difference between practise and theory, it's because one tried to use the wrong theory for the situation at hand.
slfnflctd 4y ago
Emerging practice is the ground theory hasn't covered yet. You are correct, though, in that if you want to make these practices more useful and grow your overarching theory, they absolutely must be approached with lots of testing and logic. The trick is knowing where it's most important to do this & when. Many areas of practice are left untouched by theory because there is no obvious compelling benefit.

romankolpak 4y ago

> Use your complexity budget wisely Well said

lokar 4y ago

If you run everything else on k8s having just one way to manage things makes life less complex. Running an app with state (db, storage, etc) in like this is not that hard. We ran all of the low level storage on borg at google when I was there. It worked well.

hdjjhhvvhga 4y ago
Let's say a new Kubernetes version comes out in April. In November, as everything works perfectly well, you decide to install a Postgres operator on it. Bummer, it doesn't work. It's not a huge issue, you just wait until the bug is resolved (already done[0]), but it's just one of these tiny things that I don't get when running Postrges natively. And I'm saying this as a big fan of Crunchy Data running some production loads on it without a failure for quite some time now. [0] https://github.com/CrunchyData/postgres-operator/issues/3476 https://github.com/CrunchyData/postgres-operator/issues/3476
- thunky 4y ago
  And that repo you linked to has 1846 issues, 161 open. Which doesn't seem extraordinary based on my limited exposure to k8s. Another example: https://github.com/zalando/postgres-operator/issues https://github.com/zalando/postgres-operator/issues with 445 open issues. Why? Maybe I'm wrong and this is all a good sign of progress, but my impression is that the entire k8s ecosystem is held together with reused duct tape.
  - Too 4y ago
    Look at the feature-list of that repo. Half of it are actually deficiencies in postgres that warrants the external complexities, not something induced by kubernetes. Sure, a lot of it is nice-to-haves but some are absolutely essential for even a basic postgres deployment even if you used VMs... Like, why is replication so difficult, why do i need all these extensions and why do i need to deploy a bouncer as a separate service in 2023?!
    - 4y ago