4 ms·

Because they are BIG and they understand how BIG works. It’s very hard to be small and understand it.

kstrauser 2y ago
I'm not convinced that's true any more. Let me get this out of the way: McDonald's is BIG. I'm not going to argue against that. That said, BIG in this case means about 63 million customers a day[0]. Yes, they come in bursts. No, you can't divide 63M by 86400 to address their traffic. That said, 63M requests to do something per day is no longer IBM-scale volume. At a prior job we'd designed a system to handle about 30M transactions per second at peak (think "it's the Super Bowl: guess whether the offense is going to kick or run the ball in the next play! 5... 4... 3..."). McD's requests are more complex than that, but so is the technology available to work on it today. IBM knows BIG. I think the notion of what BIG means is a lot different now though. Lots of problems that were nearly intractable a couple decades ago genuinely are in the wheelhouse of clever startups today. [0]https://corporate.mcdonalds.com/corpmcd/our-company/who-we-are.html https://corporate.mcdonalds.com/corpmcd/our-company/who-we-a...
- fragmede 2y ago
  There's usually some way to "cheat" to make things easier. In this case, orders don't need to ask go into a single globally accessible instantaneously updated database like BigTable. A McDonald's in San Francisco doesn't care what a McDonald's in Paris' customers have ordered right that second. Or even the one down the street. So the worst you could do is give each restaurant their own copy of the stack. And that stack meds to handle maybe 3 orders a minute? The busiest McDonald's still isn't going to be all that busy in orders per second, relative to a busy website. Everything you can do to optimize and use fewer resources per restaurant is an optimization and cost reduction problem, but the base problem is inherently tractable. Chick-fil-A runs an Edge Kubernetes cluster at each of their 2800 restaurants.
  - kstrauser 2y ago
    Definitely. And that's the kind of thing that could certainly be managed by a "small" (at least compared to IBM) sized team. While it's not quite as simple as "Terraform it and call it good", it's probably not radically different from that, at least in concept.
fragmede 2y ago
One thing about big is that they take forever to pay. Months to make the sale, months to cost the deal, months more to get paid. A tiny company may not have the resources to wait that long.
dehrmann 2y ago
You're right, but there are two versions of how big works. One is you're buying something to solve a career need, the other is you're buying something to solve a business need.

I'm not convinced that's true any more. Let me get this out of the way: McDonald's is BIG. I'm not going to argue against that. That said, BIG in this case means about 63 million customers a day[0]. Yes, they come in bursts. No, you can't divide 63M by 86400 to address their traffic. That said, 63M requests to do something per day is no longer IBM-scale volume. At a prior job we'd designed a system to handle about 30M transactions per second at peak (think "it's the Super Bowl: guess whether the offense is going to kick or run the ball in the next play! 5... 4... 3..."). McD's requests are more complex than that, but so is the technology available to work on it today. IBM knows BIG. I think the notion of what BIG means is a lot different now though. Lots of problems that were nearly intractable a couple decades ago genuinely are in the wheelhouse of clever startups today. [0]https://corporate.mcdonalds.com/corpmcd/our-company/who-we-are.html https://corporate.mcdonalds.com/corpmcd/our-company/who-we-a...

fragmede 2y ago
There's usually some way to "cheat" to make things easier. In this case, orders don't need to ask go into a single globally accessible instantaneously updated database like BigTable. A McDonald's in San Francisco doesn't care what a McDonald's in Paris' customers have ordered right that second. Or even the one down the street. So the worst you could do is give each restaurant their own copy of the stack. And that stack meds to handle maybe 3 orders a minute? The busiest McDonald's still isn't going to be all that busy in orders per second, relative to a busy website. Everything you can do to optimize and use fewer resources per restaurant is an optimization and cost reduction problem, but the base problem is inherently tractable. Chick-fil-A runs an Edge Kubernetes cluster at each of their 2800 restaurants.
- kstrauser 2y ago
  Definitely. And that's the kind of thing that could certainly be managed by a "small" (at least compared to IBM) sized team. While it's not quite as simple as "Terraform it and call it good", it's probably not radically different from that, at least in concept.

fragmede 2y ago

One thing about big is that they take forever to pay. Months to make the sale, months to cost the deal, months more to get paid. A tiny company may not have the resources to wait that long.

dehrmann 2y ago

You're right, but there are two versions of how big works. One is you're buying something to solve a career need, the other is you're buying something to solve a business need.