3 ms·

I still think, consistent (as in ACID) persistence layer is a huge gap in the early design of k8s ecosystem, so it still feels like you're wrangling against the

I still think, consistent (as in ACID) persistence layer is a huge gap in the early design of k8s ecosystem, so it still feels like you're wrangling against the architecture to have something persisted. A good example is an otherwise excellent Monzo banks's architecture, they've built a very impressive backend it seems: https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend https://monzo.com/blog/2016/09/19/building-a-modern-bank-bac... but they still had a production outage cause by Kubernetes: https://community.monzo.com/t/anatomy-of-a-production-kubernetes-outage-presentation/37331 https://community.monzo.com/t/anatomy-of-a-production-kubern... I really see a big conceptual clash between a consistent database view and k8s ephemeral everything, not sure of object storage is the enswer to that.

georgebarnett 7y ago
Yes, I completely agree with your assessment. For this reason, I prefer separating workloads. Cloud providers make this really easy with managed sql and key value datastores. In datacenter there are good options using high availability storage arrays and vm systems. I don’t see that kube was ever meant to replace that for this workload type. I know some have this overly simplistic idea of “one platform only”, which I don’t agree with. I see no reason not to use the correct tools as appropriate for the task at hand.
redis_mlc 7y ago
The DBA world has almost entirely rejected VMs, containers and even SANs for master databases, which never seem to quite work for production workloads. The issues are: 1) performance degradation - the DBA wants 100% of the possible hardware performance, not less, for masters 2) infrastructure updates affecting the database. k8s has had a lot of updates, which interfere with the average 400 days uptime achieved on physical hardware that I've seen 3) increasing query tail latency, measured at 3x or more under VMware for example 4) vendors disclaiming support (Oracle being the most notable example. They will only support their VM technologies per their license.) 5) sharing database infrastructure with anybody never turns out well. 6) stalls by adding yet another scheduler. Having said that, if you decide you just don't care about database performance, go ahead with what you feel is best. But don't whine about poor availability or queries being slow. Source: DBA who has worked with all of the above technologies. Just give me a pair of 2U servers with Fusion IO SSD cards!

georgebarnett 7y ago

Yes, I completely agree with your assessment. For this reason, I prefer separating workloads. Cloud providers make this really easy with managed sql and key value datastores. In datacenter there are good options using high availability storage arrays and vm systems. I don’t see that kube was ever meant to replace that for this workload type. I know some have this overly simplistic idea of “one platform only”, which I don’t agree with. I see no reason not to use the correct tools as appropriate for the task at hand.

redis_mlc 7y ago

The DBA world has almost entirely rejected VMs, containers and even SANs for master databases, which never seem to quite work for production workloads. The issues are: 1) performance degradation - the DBA wants 100% of the possible hardware performance, not less, for masters 2) infrastructure updates affecting the database. k8s has had a lot of updates, which interfere with the average 400 days uptime achieved on physical hardware that I've seen 3) increasing query tail latency, measured at 3x or more under VMware for example 4) vendors disclaiming support (Oracle being the most notable example. They will only support their VM technologies per their license.) 5) sharing database infrastructure with anybody never turns out well. 6) stalls by adding yet another scheduler. Having said that, if you decide you just don't care about database performance, go ahead with what you feel is best. But don't whine about poor availability or queries being slow. Source: DBA who has worked with all of the above technologies. Just give me a pair of 2U servers with Fusion IO SSD cards!