Hacker News new | ask | show | jobs
by alexmorse 2907 days ago
I don't understand why at all you would do this for a restaurant

What challenge is this addressing, what problem does this solve? Is there a problem to solve here?

I do assume there's a good reason for this, but as presented it seems like a very stupid waste of money.

3 comments

Caleb here (SRE at Chick-Fil-A)... we actually just did it because we thought it would look cool :-P .

Hah... no, but seriously... we wrote this article for QCon attendees, and gave a lot more context during our talk at that conference. We didn't realize it was going to be on here, otherwise we would have explained the "why" and not just dived in.

What we were trying to solve for was; 1) Low latency 2) High Availability 3) Container based, zero-downtime deployments 4) Continued operations even in an internet-down event

Also, as an interesting side note, the equivalent hardware has about a 6 month ROI if we put the entire load on AWS... granted it would be more efficient, so that's not an entirely fair comparison, but the hardware is unbelievably inexpensive from a cost perspective.

It sounds like a huge cost saving to me. Being able to install a few dumb machines in the restaurant and then have remote installation and management of applications running on them would be great. I imagine that kubernetes would be more reliable than PXE booting images across the internet (as that often requires physically rebooting machines which requires involvement of the restaurant staff, will be error prone, etc), not to mention that building bootable images with your software on is not a very modern practice.

Bear in mind that in terms of cost, this is competing with a person driving to each restaurant and fiddling around with computers for an hour, which is a very expensive process.

> not to mention that building bootable images with your software on is not a very modern practice.

1. Why not?

2. Who cares if it's not modern if it does the job?

And they wouldn't even need to make a special app, they could just make it a webapp ergo make a 1-time image with a browser...

> 1. Why not?

It's becoming more common to distribute applications with orchestration software like Kubernetes. The technology around PXE booting is quite old, and mired in enterprise cruft.

> 2. Who cares if it's not modern if it does the job?

Developers love new tech, especially if they can get a Medium post out of it. This doesn't make it a good reason of course, but if this is the tech that more developers are familiar with, that's a good reason.

I personally wouldn't want to learn how to boot 6000 remote machines off built disk images over the internet, I'd rather use the skills I already have around Ansible or learn Kubernetes.

> And they wouldn't even need to make a special app, they could just make it a webapp ergo make a 1-time image with a browser...

I've never been to a Chick-fil-a, but if the setups are anything like my local McDonalds, that's a complex 5 screen setup showing a fluid mix of static images, videos, animations, and applications, not to mention that other stores have different setups/layouts/display types/etc - I don't think you'd be able to _reliably_ do this in a browser. My guess is that it's a multi-screen aware wrapper around video components and web views. That will need re-deploying regularly I would imagine. And that's not to mention the kitchen ordering system, the self-service machines, the tills, etc.

On-site machines totally make sense, smart applications deployed locally, frequently, make sense.

Why do you assume that it's a waste of money? I guess it is a given that they operate some computer infrastructure in every venue, so you would have the same capex without Kubernetes and you would also need some kind of management, so you would also spend money on operations. So maybe it's not such a bad idea to use an off-the-shelf container management software to rollout and operate their containerized applications.
They could just do the same thing with a standard client-server model. Just deploy a bare bones OS with a browser on it.

They'd need connectivity to the server, true, but doesn't Kubernetes also need connectivity to the cluster manager?

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.

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?

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.

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.

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).
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.