[mikehollinger]

The big issue here is that a client server model has an inherent trust on the network to be 100% there when you need it. Cable modems or DSL (probably) fail at a much higher rate per day intermittently than a fleet of 2,000 sets of redundant computers.

Consider - how would you handle order taking if the network dropped?

A buddy did IT for a theater for a while - they had a similar problem where they’d lose access to their payment processor regularly. No one ever noticed since the system queued ops locally until the network came back up.

[reacharavindh]

But, how does bringing K8s into the mix solve the unreliable network problem?

If anything it brings in more components/complexity/headache...

If you could run your pods offline, you could run your software app offline. If you could trust your Kube repository, you could trust Se repository for your App..

What does K8s bring to the mix that is actually useful in solving a problem than the superficial ones?

[mikehollinger]

I’m sure it doesn’t. I look forward to reading the “why we did it” article as well!

I have enough problems getting kubernetes to run on a single node with hyperkube that I’m not entirely sure that I want to deal with it in the future.

[pswenson]

almost all retail credit card transactions go over the internet and commerce seems to continue fine.

but if you want to be safe, have a cellular backup network.

seems way simpler than pushing out a k8s infrastructure to every store.

[zbentley]

Payment processing doesn't go through the k8s infrastructure, they said. And lots of it still uses Tel/dedicated network lines already, especially in places like malls (where lots of restaurants probably are).

[mikehollinger]

Aha! But - We’re only considering payment processsing. What about the actual operations of the store? I’m guessing the fry machine is controlled by the same infrastructure.

And surveillance cameras, and smart locks on any safes, etc.