3 ms·

You won't see databases on k8s in enterprise production environments. Startups or companies/services with lower reliability requirements, sure. But don't expec

You won't see databases on k8s in enterprise production environments. Startups or companies/services with lower reliability requirements, sure. But don't expect to walk into a fortune 500 and standup a postgres operator in production expecting to replace the existing federated solution.

goodpoint 4y ago
Ideally you should not be seeing k8s at all in mission critical infrastructure in any tech company. I know few FAANGs that stay away from it.
- grepfru_it 4y ago
  I disagree with that. Many fortune 500s are running k8s to power critical infra. GMF processes all OnStar data in realtime on k8s, GitHub runs entirely on k8s, etc etc. You need the personal and the tools to manage it, but at a certain point k8s makes sense. There are still use cases were k8s is not a solution. EDIT: part of actions, codespaces and packages are not run on k8s, but 80% of github services are
  - goodpoint 4y ago
    > GitHub runs entirely on k8s That's really not the endorsement you think it is.
    - grepfru_it 4y ago
      Your comment doesn't really help understand why.
      - remram 4y ago
        GitHub experiences outages pretty regularly, for example on 12 separate days last month: https://www.githubstatus.com/history https://www.githubstatus.com/history
        joshribakoff 4y ago
        So what? Nothing here is sufficient to conclude it has anything to do with k8 whatsoever. For example “users cannot resume code spaces created before the incident” sounds a lot more like an application level problem.
        remram 4y ago
        The point above was that it wasn't a good endorsement. Correlation is not causation but the opposite is also true.
- wbl 4y ago
  Why? Yes the operations can be a bit messy. But in practice it solves the "I want to run, update and deploy my service without worrying about hardware allocations" problem. Otherwise you create an implementation of half of it.
rlonstein 4y ago
> You won't see databases on k8s in enterprise production environments. Startups or companies/services with lower reliability requirements, sure. But don't expect to walk into a fortune 500 and standup a postgres operator in production expecting to replace the existing federated solution. Blanket statements like that should be taken with a grain of salt. F500's are not one thing. You don't have to scratch deeply to find teams running production DB's on k8s (ignoring or accepting the trade-offs, of which there are many including working with vendors and existing DBA's and their solutions) and you'll find DBA's evaluating the same and other trade-offs for themselves. I personally think that running DB's on multi-tenant k8s with nodes that weren't specifically allocated for it is strapping in for a bad ride.
- grepfru_it 4y ago
  I don't mean to nit, but we are saying the same thing..

goodpoint 4y ago

Ideally you should not be seeing k8s at all in mission critical infrastructure in any tech company. I know few FAANGs that stay away from it.

grepfru_it 4y ago
I disagree with that. Many fortune 500s are running k8s to power critical infra. GMF processes all OnStar data in realtime on k8s, GitHub runs entirely on k8s, etc etc. You need the personal and the tools to manage it, but at a certain point k8s makes sense. There are still use cases were k8s is not a solution. EDIT: part of actions, codespaces and packages are not run on k8s, but 80% of github services are
- goodpoint 4y ago
  > GitHub runs entirely on k8s That's really not the endorsement you think it is.
  - grepfru_it 4y ago
    Your comment doesn't really help understand why.
    - remram 4y ago
      GitHub experiences outages pretty regularly, for example on 12 separate days last month: https://www.githubstatus.com/history https://www.githubstatus.com/history
      - joshribakoff 4y ago
        So what? Nothing here is sufficient to conclude it has anything to do with k8 whatsoever. For example “users cannot resume code spaces created before the incident” sounds a lot more like an application level problem.
        remram 4y ago
        The point above was that it wasn't a good endorsement. Correlation is not causation but the opposite is also true.
wbl 4y ago
Why? Yes the operations can be a bit messy. But in practice it solves the "I want to run, update and deploy my service without worrying about hardware allocations" problem. Otherwise you create an implementation of half of it.

rlonstein 4y ago

> You won't see databases on k8s in enterprise production environments. Startups or companies/services with lower reliability requirements, sure. But don't expect to walk into a fortune 500 and standup a postgres operator in production expecting to replace the existing federated solution. Blanket statements like that should be taken with a grain of salt. F500's are not one thing. You don't have to scratch deeply to find teams running production DB's on k8s (ignoring or accepting the trade-offs, of which there are many including working with vendors and existing DBA's and their solutions) and you'll find DBA's evaluating the same and other trade-offs for themselves. I personally think that running DB's on multi-tenant k8s with nodes that weren't specifically allocated for it is strapping in for a bad ride.

grepfru_it 4y ago
I don't mean to nit, but we are saying the same thing..