7 ms·

Does it make sense to put quotas on internal services, that I assume are unlikely to be used externally? Is it a security recommendation? I'm curious, as I mig

Does it make sense to put quotas on internal services, that I assume are unlikely to be used externally? Is it a security recommendation? I'm curious, as I might learn something from interesting asnwers to the above questions.

cesaref 6y ago
To be fair, if they didn't use it due to concerns about availability, then that would suggest they needed more work on the service. I imagine once they knew what the issue was, they would have been able to fix it as i'm pretty sure that service doesn't need to be authorised by itself to be configured ;) The trouble I imagine was getting visiblity of what the issue was...
- marcan_42 6y ago
  > I imagine once they knew what the issue was, they would have been able to fix it as i'm pretty sure that service doesn't need to be authorised by itself to be configured ;) You'd be surprised at the circular dependencies that creep up at Google scale... (I used to work there and we had last resort secure access mechanisms, but I wouldn't be surprised if the normal front door wound up shut pretty hard for this one)
clavoie 6y ago
(Disclaimer, I worked at Google over a decade ago, for about half a decade; as an SRE for about 2 of those years) Yes, it absolutely makes sense. You never know when a typo in a config file or bug in your job-management code will go bonkers and try to take over all resources. Same think as disk quotas on computers with tons of users: you want to limit the damage that a user can accidentally (or not...) do. Good quota systems saved my team's bacon way back when a few times, when fewer people were at the company; I can only imagine how useful they are at what, 10-20x the size?
- byecomputer 6y ago
  Good thing quota systems can't go bonkers and take over all the resources, that would be a nightmare!
  - mav3rick 6y ago
    What's the need for the snark ? Bugs can happen anywhere. Doesn't mean we don't try ?
    - byecomputer 6y ago
      I guess I thought the irony was amusing. Computers doing unexpected things is a universal experience, so I don't think there's any need to take it personally. You're also not the person I responded to, so I take it you have some sort of distaste for verbal irony no matter where it happens? Or you work for Google
      - mav3rick 6y ago
        You seemingly refuted a good solution. Rather than guessing my background or character, introspect about your comment.
        deleted 6y ago
        [deleted]
        byecomputer 6y ago
        I made guesses because you took an incongruously dark read of my comment that seemed more reflective of internal disquiet than anything I said. I'll respectfully ask that you refrain from being hostile towards others based on assumptions regarding their intent
  - ChrisRR 6y ago
    And that's precisely why you implement checks at multiple levels. You can't rely on one level to always be well behaved and so you never have to worry about issues at another level. Not sure why you had to be snarky about it
- darig 6y ago
  I think google has killed more products than it has added in the last decade (ignoring rebrandings), so I'd consider them less than 1x the size with 10-20x the liabilities. Why wouldn't you want to limit the damage that instilling distrust in your biggest profit centers can do?
- zadokshi 6y ago
  Well here’s the thing though. Google are removing quotas from things like appengine. How can it be simultaneously helpful to have quotas but at the same time google wants to remove them?
  - alanfranz 6y ago
    I think you're conflating very different things. Quotas may be removed if you've got a virtually unlimited amount of a certain resource (and even there they can be useful to prevent overbilling), but disk quotas are necessary because disk space is not unlimited. Without those, a noisy neighbour can break your application.
- anthony_r 6y ago
  In particular you cannot provide an internal SLA on write requests to low-level storage solutions if you can't guarantee that you actually have the spare disks. The SLA would have to be something like "we guarantee 99.999% write availability unless team A or team B or team C makes a mistake", so now you have to look up what team A and B and C are up to and what do they guarantee. Instead of the more sensible "we guarantee 99.999% write availability unless you are out of quota".
  - clavoie 6y ago
    Exactly. At some point, someone somewhere will have a bad day / sneeze on a keyboard at just the perfectly wrong time -- at Google's scale, that's statistically a daily (hourly?) occurrence. Quota systems for the win -- if only as a shared agreement on who can do how much damage / take how much resources before they're automatically stopped and more resources must be justified through some review process (likely involving budgetary concerns).
- mrighele 6y ago
  Shouldn't there be a soft limit that start sending out warnings before hitting the hard one ? Unless some service started eating the quota so fast that it reached both limits in quick succession, the upper limit should never be reached.
  - erhk 6y ago
    From the article capacity was reduced
    - mrighele 6y ago
      You're right. Still, a better approach could have been adopted, like blocking a change that would cause some service to go over quota, or have the automatic system change the quotas gradually, thus giving time for alerts and human intervention
      - cranekam 6y ago
        I'm sure that this Google outage was the combination of several independent issues. Perhaps there are the kind of safeguards you mentioned in place, but they returned an incorrect view of the world because of a bug exposed by a network partition? The point is that with huge distributed systems the things take them down (at least once they're mature) are typically the result of several failures that compound and interact in a way that wasn't foreseen. IMO it's more likely that the suggestions you made (blocks and/or automation) are already in place but failed in some more complex way. Source: worked at a FAANG for a decade, saw many big incidents. Almost all were the confluence of several smaller issues that, had they happened alone, wouldn't have been newsworthy.
  - clavoie 6y ago
    I can't comment on the current incident, as I've been gone for more than a decade. But my recollection is that most SRE teams would have had exactly such things -- either as really crazy borgcfg (sorry, I mean kubectl) code, or as a borgmon (sorry, prometheus) alert. The former were a real PITA to work with (borgcfg hadn't been designed with that in mind), and the latter were only reactive (and thus unable to warn about things until they were fast becoming a real problem). So most likely those safeguards were somehow disabled or made ineffective by the exact circumstances of the problem, possibly the speed at which things developed.
Cthulhu_ 6y ago
Definitely. One thing that grieved me about the attempts at microservice architectures I had to work on in my previous jobs was the complete lack of administration; in theory, a microservice can be called by any other service, but what we never implemented was a kind of authentication or logging (e.g. access keys), to track which other services used the one. It quickly became an untransparent mess.
InvOfSmallC 6y ago
Yes, usually developers (and I'm one of those) don't think about how to size correctly the cloud. You could incur in costs you don't really need. Although in my company we generate an alert and a report so that people are aware and can change instead of letting a system doing it automatically for you.
mattlondon 6y ago
Yes, because in a large organisation where your internal services are just "out there" for other teams to use, and you might not personally know the people who are using your service, you basically need to protect yourself/your service as much as you would for any external service. It also helps your service know how much it needs to scale and size itself if a team gets in touch and says "Hey we are making Service X - the default your service offers is 100 QPS but we think we will need 1000 QPS - can you support that?". In a small org where you know/roughly-know who is doing stuff then it is probably less of a concern as you can go walk over to their desk and have a chat about what they are doing or let them know they're sending too much traffic etc. This is harder to do with an org with 10s of thousands of engineers spread across the globe and in different timezones - you might suddenly get huge amounts of traffic at 3am from a team on the other side of the planet who just launched a feature you had zero idea about, and they're hammering you with 100x the QPS you usually get.
- deleted 6y ago
  [deleted]
mabbo 6y ago
Consider: my team owns a public-facing website for AWS and relies on a number of back-end services to support it. We occasionally face DoS attacks. And sometimes, they can get past our various security measures to prevent them. By everyone else having quotas on how often I can call their systems, they protect every other client they have. They protect customers who are using anything other than my website. Otherwise, someone could take down all of AWS by spamming just one system. I want them to throttle me, quota me, because I want to protect other customers if I get compromised. And even if it's one internal system calling another, it's better to have protection at every layer than to try to only have it on the outer layer. This can burn us, of course. We're always growing, and quotas need to be managed (automatically or manually). It all has to be done carefully. Edit: as always, I speak for myself and not for AWS in any official capacity. I'm mabbo, not jeffbar :)

cesaref 6y ago

To be fair, if they didn't use it due to concerns about availability, then that would suggest they needed more work on the service. I imagine once they knew what the issue was, they would have been able to fix it as i'm pretty sure that service doesn't need to be authorised by itself to be configured ;) The trouble I imagine was getting visiblity of what the issue was...

marcan_42 6y ago
> I imagine once they knew what the issue was, they would have been able to fix it as i'm pretty sure that service doesn't need to be authorised by itself to be configured ;) You'd be surprised at the circular dependencies that creep up at Google scale... (I used to work there and we had last resort secure access mechanisms, but I wouldn't be surprised if the normal front door wound up shut pretty hard for this one)

clavoie 6y ago

(Disclaimer, I worked at Google over a decade ago, for about half a decade; as an SRE for about 2 of those years) Yes, it absolutely makes sense. You never know when a typo in a config file or bug in your job-management code will go bonkers and try to take over all resources. Same think as disk quotas on computers with tons of users: you want to limit the damage that a user can accidentally (or not...) do. Good quota systems saved my team's bacon way back when a few times, when fewer people were at the company; I can only imagine how useful they are at what, 10-20x the size?

byecomputer 6y ago
Good thing quota systems can't go bonkers and take over all the resources, that would be a nightmare!
- mav3rick 6y ago
  What's the need for the snark ? Bugs can happen anywhere. Doesn't mean we don't try ?
  - byecomputer 6y ago
    I guess I thought the irony was amusing. Computers doing unexpected things is a universal experience, so I don't think there's any need to take it personally. You're also not the person I responded to, so I take it you have some sort of distaste for verbal irony no matter where it happens? Or you work for Google
    - mav3rick 6y ago
      You seemingly refuted a good solution. Rather than guessing my background or character, introspect about your comment.
      - deleted 6y ago
        [deleted]
      - byecomputer 6y ago
        I made guesses because you took an incongruously dark read of my comment that seemed more reflective of internal disquiet than anything I said. I'll respectfully ask that you refrain from being hostile towards others based on assumptions regarding their intent
- ChrisRR 6y ago
  And that's precisely why you implement checks at multiple levels. You can't rely on one level to always be well behaved and so you never have to worry about issues at another level. Not sure why you had to be snarky about it
darig 6y ago
I think google has killed more products than it has added in the last decade (ignoring rebrandings), so I'd consider them less than 1x the size with 10-20x the liabilities. Why wouldn't you want to limit the damage that instilling distrust in your biggest profit centers can do?
zadokshi 6y ago
Well here’s the thing though. Google are removing quotas from things like appengine. How can it be simultaneously helpful to have quotas but at the same time google wants to remove them?
- alanfranz 6y ago
  I think you're conflating very different things. Quotas may be removed if you've got a virtually unlimited amount of a certain resource (and even there they can be useful to prevent overbilling), but disk quotas are necessary because disk space is not unlimited. Without those, a noisy neighbour can break your application.
anthony_r 6y ago
In particular you cannot provide an internal SLA on write requests to low-level storage solutions if you can't guarantee that you actually have the spare disks. The SLA would have to be something like "we guarantee 99.999% write availability unless team A or team B or team C makes a mistake", so now you have to look up what team A and B and C are up to and what do they guarantee. Instead of the more sensible "we guarantee 99.999% write availability unless you are out of quota".
- clavoie 6y ago
  Exactly. At some point, someone somewhere will have a bad day / sneeze on a keyboard at just the perfectly wrong time -- at Google's scale, that's statistically a daily (hourly?) occurrence. Quota systems for the win -- if only as a shared agreement on who can do how much damage / take how much resources before they're automatically stopped and more resources must be justified through some review process (likely involving budgetary concerns).
mrighele 6y ago
Shouldn't there be a soft limit that start sending out warnings before hitting the hard one ? Unless some service started eating the quota so fast that it reached both limits in quick succession, the upper limit should never be reached.
- erhk 6y ago
  From the article capacity was reduced
  - mrighele 6y ago
    You're right. Still, a better approach could have been adopted, like blocking a change that would cause some service to go over quota, or have the automatic system change the quotas gradually, thus giving time for alerts and human intervention
    - cranekam 6y ago
      I'm sure that this Google outage was the combination of several independent issues. Perhaps there are the kind of safeguards you mentioned in place, but they returned an incorrect view of the world because of a bug exposed by a network partition? The point is that with huge distributed systems the things take them down (at least once they're mature) are typically the result of several failures that compound and interact in a way that wasn't foreseen. IMO it's more likely that the suggestions you made (blocks and/or automation) are already in place but failed in some more complex way. Source: worked at a FAANG for a decade, saw many big incidents. Almost all were the confluence of several smaller issues that, had they happened alone, wouldn't have been newsworthy.
- clavoie 6y ago
  I can't comment on the current incident, as I've been gone for more than a decade. But my recollection is that most SRE teams would have had exactly such things -- either as really crazy borgcfg (sorry, I mean kubectl) code, or as a borgmon (sorry, prometheus) alert. The former were a real PITA to work with (borgcfg hadn't been designed with that in mind), and the latter were only reactive (and thus unable to warn about things until they were fast becoming a real problem). So most likely those safeguards were somehow disabled or made ineffective by the exact circumstances of the problem, possibly the speed at which things developed.

Cthulhu_ 6y ago

Definitely. One thing that grieved me about the attempts at microservice architectures I had to work on in my previous jobs was the complete lack of administration; in theory, a microservice can be called by any other service, but what we never implemented was a kind of authentication or logging (e.g. access keys), to track which other services used the one. It quickly became an untransparent mess.

InvOfSmallC 6y ago

Yes, usually developers (and I'm one of those) don't think about how to size correctly the cloud. You could incur in costs you don't really need. Although in my company we generate an alert and a report so that people are aware and can change instead of letting a system doing it automatically for you.

mattlondon 6y ago

Yes, because in a large organisation where your internal services are just "out there" for other teams to use, and you might not personally know the people who are using your service, you basically need to protect yourself/your service as much as you would for any external service. It also helps your service know how much it needs to scale and size itself if a team gets in touch and says "Hey we are making Service X - the default your service offers is 100 QPS but we think we will need 1000 QPS - can you support that?". In a small org where you know/roughly-know who is doing stuff then it is probably less of a concern as you can go walk over to their desk and have a chat about what they are doing or let them know they're sending too much traffic etc. This is harder to do with an org with 10s of thousands of engineers spread across the globe and in different timezones - you might suddenly get huge amounts of traffic at 3am from a team on the other side of the planet who just launched a feature you had zero idea about, and they're hammering you with 100x the QPS you usually get.

deleted 6y ago
[deleted]

mabbo 6y ago

Consider: my team owns a public-facing website for AWS and relies on a number of back-end services to support it. We occasionally face DoS attacks. And sometimes, they can get past our various security measures to prevent them. By everyone else having quotas on how often I can call their systems, they protect every other client they have. They protect customers who are using anything other than my website. Otherwise, someone could take down all of AWS by spamming just one system. I want them to throttle me, quota me, because I want to protect other customers if I get compromised. And even if it's one internal system calling another, it's better to have protection at every layer than to try to only have it on the outer layer. This can burn us, of course. We're always growing, and quotas need to be managed (automatically or manually). It all has to be done carefully. Edit: as always, I speak for myself and not for AWS in any official capacity. I'm mabbo, not jeffbar :)