5 ms·

> Perhaps surprisingly for engineers who work in mission-critical business applications, occasional spikes of 90%+ of our users being entirely unable to use the

> Perhaps surprisingly for engineers who work in mission-critical business applications, occasional spikes of 90%+ of our users being entirely unable to use the sole application of our company was an entirely acceptable engineering tradeoff versus sizing our capacity against our peak loads. I think we found the Pokemon Go engineering team.

samstave 9y ago
Acceptable engineering trade off and acceptable business decision trade off are not always the same thing. That paragraph reads to me “screw the users!” - and for them to say that around “mission critical” seems they don’t understand the critical mission...
- lostcolony 9y ago
  The critical mission is to deliver as much business functionality as possible within the business constraints. The business constraints often include cost. They also may be arbitrarily far from 100% uptime.
  - samstave 9y ago
    Yeah, agreed - but that paragraph was worded in such a way as to convey "screw the users for spiking use, such that the application is now unavailable, and now ALL business halts..." -- Or did I misinterpret that?
    - adrianratnapala 9y ago
      The thinking is probably that if usage spikes and some people can't get access to the game and they know that this is because of spiking usage, then this just builds buzz and demand -- like hip restaurants with visible queues. So in this case the business demand on the engineers was presumably to make sure that 10% of users get good service during the spike while the others are gracefully shown a "Sorry we are too busy right now " message. Whether or not this is evil depends on the pricing model and other factors that determine whether those bounced user had a reasonable expectation of service.
      - samstave 9y ago
        These engineers and C-levels of this company should be punched in the face.
    - lostcolony 9y ago
      Depends what happens as to whether it's a problem or not. Maybe it fails to handle the load, the users get a "failure to authenticate" message or similar, and they try again. If their peaks are really sharp and short, that's probably just fine, because that second attempt almost invariably works.
    - derefr 9y ago
      I just read it as "the compute required to reach 100% uptime would cost more per minute than we lose per minute that we can't access the app." I.e., an entirely business-wise consideration, even if phrased in terms of engineering tradeoffs.
      - samstave 9y ago
        That’s actually a salient point! I appreciate you telling me that as I had not thought of it that way! Seriously.
- kelnos 9y ago
  I think you're parsing that statement wrong: he's saying that engineers who are used to building mission-critical apps would likely be surprised about how acceptable downtime was for their non-mission-critical app (a game).
  - samstave 9y ago
    Well thank god, that makes way more sense!
kevinr 9y ago
It's not coincidental; I believe the 'sole application' the author talks about was in fact an online game.

samstave 9y ago

Acceptable engineering trade off and acceptable business decision trade off are not always the same thing. That paragraph reads to me “screw the users!” - and for them to say that around “mission critical” seems they don’t understand the critical mission...

lostcolony 9y ago
The critical mission is to deliver as much business functionality as possible within the business constraints. The business constraints often include cost. They also may be arbitrarily far from 100% uptime.
- samstave 9y ago
  Yeah, agreed - but that paragraph was worded in such a way as to convey "screw the users for spiking use, such that the application is now unavailable, and now ALL business halts..." -- Or did I misinterpret that?
  - adrianratnapala 9y ago
    The thinking is probably that if usage spikes and some people can't get access to the game and they know that this is because of spiking usage, then this just builds buzz and demand -- like hip restaurants with visible queues. So in this case the business demand on the engineers was presumably to make sure that 10% of users get good service during the spike while the others are gracefully shown a "Sorry we are too busy right now " message. Whether or not this is evil depends on the pricing model and other factors that determine whether those bounced user had a reasonable expectation of service.
    - samstave 9y ago
      These engineers and C-levels of this company should be punched in the face.
  - lostcolony 9y ago
    Depends what happens as to whether it's a problem or not. Maybe it fails to handle the load, the users get a "failure to authenticate" message or similar, and they try again. If their peaks are really sharp and short, that's probably just fine, because that second attempt almost invariably works.
  - derefr 9y ago
    I just read it as "the compute required to reach 100% uptime would cost more per minute than we lose per minute that we can't access the app." I.e., an entirely business-wise consideration, even if phrased in terms of engineering tradeoffs.
    - samstave 9y ago
      That’s actually a salient point! I appreciate you telling me that as I had not thought of it that way! Seriously.
kelnos 9y ago
I think you're parsing that statement wrong: he's saying that engineers who are used to building mission-critical apps would likely be surprised about how acceptable downtime was for their non-mission-critical app (a game).
- samstave 9y ago
  Well thank god, that makes way more sense!

kevinr 9y ago

It's not coincidental; I believe the 'sole application' the author talks about was in fact an online game.