4 ms·

> I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage. I'm curious; what would you have th

> I find it silly to rely on some service, any external service, so much that if it goes down it would cause a prod outage. I'm curious; what would you have these companies do in such a scenario? If 100% uptime is impossible then what you seem to be suggesting is that people should never use third party services or if they do use them they must not be in a critical path. Are you suggesting everyone should do everything in house?

lambda 8y ago
Use free (FLOSS) software. If you have to use non-free software, buy software, not services. If you have to buy services, always have a well-tested fallback path for when that service is not available.
- s73v3r_ 8y ago
  Care to point out the FLOSS equivalent of what Smyte did?
  - lambda 8y ago
    You missed two thirds of my comment. This was in order of preference. If you can, use free software that you can fix and support yourself if need be. If not, buy the software and run it yourself, so you can at least control its operation. The last option is to by SaaS, and if you do, you need to have contingency plans in case it goes away. You should take this risk seriously, and factor it in to your decision when buying SaaS, and invest the engineering resources to make sure you aren't overly dependent on it.
jarfil 8y ago
For any critical service, they should have an alternate provider ready at all times so that they could instantly switch to it. Whether it's another external provider or in house, is not really relevant, although having a bare bones in house alternative for the critical parts is a good idea. What I'm suggesting is that people should use external services for their lower costs, better performance, or extra features, not to 100% depend on any of them.
scarface74 8y ago
No. Smyte wasn't so business critical that they should consider a failure in the service a reason to stop the site. Netflix had an example where if thier authentication service was down, they didn't stop people from watching videos. There is a popular C# package called Polly that has all sorts of fault tolerant strategies. https://github.com/App-vNext/Polly/wiki/Transient-fault-handling-and-proactive-resilience-engineering https://github.com/App-vNext/Polly/wiki/Transient-fault-hand... In this case, use a Fallback strategy that responds to an API failure with some type of generic success response.

lambda 8y ago

Use free (FLOSS) software. If you have to use non-free software, buy software, not services. If you have to buy services, always have a well-tested fallback path for when that service is not available.

s73v3r_ 8y ago
Care to point out the FLOSS equivalent of what Smyte did?
- lambda 8y ago
  You missed two thirds of my comment. This was in order of preference. If you can, use free software that you can fix and support yourself if need be. If not, buy the software and run it yourself, so you can at least control its operation. The last option is to by SaaS, and if you do, you need to have contingency plans in case it goes away. You should take this risk seriously, and factor it in to your decision when buying SaaS, and invest the engineering resources to make sure you aren't overly dependent on it.

jarfil 8y ago

For any critical service, they should have an alternate provider ready at all times so that they could instantly switch to it. Whether it's another external provider or in house, is not really relevant, although having a bare bones in house alternative for the critical parts is a good idea. What I'm suggesting is that people should use external services for their lower costs, better performance, or extra features, not to 100% depend on any of them.

scarface74 8y ago

No. Smyte wasn't so business critical that they should consider a failure in the service a reason to stop the site. Netflix had an example where if thier authentication service was down, they didn't stop people from watching videos. There is a popular C# package called Polly that has all sorts of fault tolerant strategies. https://github.com/App-vNext/Polly/wiki/Transient-fault-handling-and-proactive-resilience-engineering https://github.com/App-vNext/Polly/wiki/Transient-fault-hand... In this case, use a Fallback strategy that responds to an API failure with some type of generic success response.