4 ms·

I'm not denying that what they've done is really bad, but who puts a 3rd party API in a critical path without having any fallback (alternative service, reasonab

I'm not denying that what they've done is really bad, but who puts a 3rd party API in a critical path without having any fallback (alternative service, reasonable timeouts, etc.) for when it goes down (as almost any service will eventually do)?

striking 8y ago
People who have multi-year contracts with those API providers, probably with an SLA detailed in the contract. Especially since this API call would have to be on the critical path; you don't want people signing up when the anti-spam service isn't running.
- snowwolf 8y ago
  1. You have an SLA guaranteeing 100% uptime? 2. If it's that critical, you have redundancy (an alternative provider, or a naive implementation that maybe causes more false positives but that will cover you during an outage)
  - striking 8y ago
    No, but if I were npm, I'd have an SLA guaranteeing three-and-a-half or four nines of uptime (which is far from unreasonable) and just accept that there might be times that signup is not accessible because that'd only cost me a couple hours of signups a year. And no, I wouldn't have an alternative provider. It would not make sense to, if I'm paying a company to provide a service. Why should I pay another to do nothing?
  - hluska 8y ago
    I might be wrong, but I'm getting the sense that you don't have much actual experience. I've been a senior developer in an organization and known that a solution isn't perfectly robust. Clearly I want to fix it because I (like most other developers) like building robust solutions, but I have six weeks of tasks to finish in two weeks, and that isn't one of them. What do I do? You might say "do it anyways" and, if so, that's a junior developer attitude. I'd strongly urge you not to do that as shipping big projects is really more about choreography than engineering. Or, you might say "fight for permission" and that's not a bad idea, as long as you accept that you'll likely lose. You'll likely lose for business reasons. On some level, we all know that a SAAS on a critical path is a bad idea, but we do math. Our SLAs are not 100%, but we can accept a few hours of downtime a year. And, the probability of a service you've seemingly vetted being acquired and shutting down this quickly is low. Is the probability of a shut down like this high enough to justify adding and testing redundancy? The math usually works out in favour of bug fixes and new features > redundancy.
    - AndrewUnmuted 8y ago
      In the first place, it was an awful business decision to take the route of trusting a SaaS provider with such an important task. It is extremely irresponsible to forward sensitive user data and site interactions to a third party, even if it is in the name of spam/abuse/scam filtering. That its implementation brings down production websites in the case of service failure only adds insult to injury, originally caused by plain-awful product design. If there's one thing that you should be doing in-house when you run a large online community of privacy-conscious users, it's the kind of service that Smyte provided. If sound business reasoning had prevailed, npm would have suffered no downtime.
      - hluska 8y ago
        It's easy to say that now that everything has gone to hell, but in business, we usually have to make decisions with imperfect knowledge. I don't agree that it's irresponsible to forward sensitive data to third parties. Rather, I believe that intelligent companies have intelligent policies around sharing data with third parties. Some third parties provide an amazing service that would be extremely expensive for companies to mimic in-house. And, you cannot convince me that the probability of a well vetted service shutting down as fast as Smyte did is high enough to justify bringing this in-house when you have other things to work on.
workinthehead 8y ago
I know for a fact that you've done worse in your own life. Spare us the moral posturing, please.
- snowwolf 8y ago
  This whole thread is moral posturing about how unprofessional Twitter/Smyte have been, but if we want to talk about professionalism we should look at ourselves.
  - ajeet_dhaliwal 8y ago
    If you upload to AWS S3 you put in a fallback to another service? And any other AWS services you use? That's a lot of fall backs. Is the second fallback good enough? Should we add a third? In any practical sense development would grind to a halt. Twitter/Smyte are totally in the wrong for not giving a reasonable notice. I think whoever made this decision should actually be removed from their post and the servers should powered back on again with an apology to all of their clients. If they still want to shut it down later then they should provide a reasonable time frame.
- teddyh 8y ago
  What you just did is called a “Tu quoque” argument, and it is a type of Ad Hominem attack; i.e. a fallacy. https://en.wikipedia.org/wiki/Tu_quoque https://en.wikipedia.org/wiki/Tu_quoque
  - workinthehead 8y ago
    Good effort, buddy, but no.
mickronome 8y ago
Everyone that does online transaction of money, and many more. Like all those who use AWS services on AWS.

striking 8y ago

People who have multi-year contracts with those API providers, probably with an SLA detailed in the contract. Especially since this API call would have to be on the critical path; you don't want people signing up when the anti-spam service isn't running.

snowwolf 8y ago
1. You have an SLA guaranteeing 100% uptime? 2. If it's that critical, you have redundancy (an alternative provider, or a naive implementation that maybe causes more false positives but that will cover you during an outage)
- striking 8y ago
  No, but if I were npm, I'd have an SLA guaranteeing three-and-a-half or four nines of uptime (which is far from unreasonable) and just accept that there might be times that signup is not accessible because that'd only cost me a couple hours of signups a year. And no, I wouldn't have an alternative provider. It would not make sense to, if I'm paying a company to provide a service. Why should I pay another to do nothing?
- hluska 8y ago
  I might be wrong, but I'm getting the sense that you don't have much actual experience. I've been a senior developer in an organization and known that a solution isn't perfectly robust. Clearly I want to fix it because I (like most other developers) like building robust solutions, but I have six weeks of tasks to finish in two weeks, and that isn't one of them. What do I do? You might say "do it anyways" and, if so, that's a junior developer attitude. I'd strongly urge you not to do that as shipping big projects is really more about choreography than engineering. Or, you might say "fight for permission" and that's not a bad idea, as long as you accept that you'll likely lose. You'll likely lose for business reasons. On some level, we all know that a SAAS on a critical path is a bad idea, but we do math. Our SLAs are not 100%, but we can accept a few hours of downtime a year. And, the probability of a service you've seemingly vetted being acquired and shutting down this quickly is low. Is the probability of a shut down like this high enough to justify adding and testing redundancy? The math usually works out in favour of bug fixes and new features > redundancy.
  - AndrewUnmuted 8y ago
    In the first place, it was an awful business decision to take the route of trusting a SaaS provider with such an important task. It is extremely irresponsible to forward sensitive user data and site interactions to a third party, even if it is in the name of spam/abuse/scam filtering. That its implementation brings down production websites in the case of service failure only adds insult to injury, originally caused by plain-awful product design. If there's one thing that you should be doing in-house when you run a large online community of privacy-conscious users, it's the kind of service that Smyte provided. If sound business reasoning had prevailed, npm would have suffered no downtime.
    - hluska 8y ago
      It's easy to say that now that everything has gone to hell, but in business, we usually have to make decisions with imperfect knowledge. I don't agree that it's irresponsible to forward sensitive data to third parties. Rather, I believe that intelligent companies have intelligent policies around sharing data with third parties. Some third parties provide an amazing service that would be extremely expensive for companies to mimic in-house. And, you cannot convince me that the probability of a well vetted service shutting down as fast as Smyte did is high enough to justify bringing this in-house when you have other things to work on.

workinthehead 8y ago

I know for a fact that you've done worse in your own life. Spare us the moral posturing, please.

snowwolf 8y ago
This whole thread is moral posturing about how unprofessional Twitter/Smyte have been, but if we want to talk about professionalism we should look at ourselves.
- ajeet_dhaliwal 8y ago
  If you upload to AWS S3 you put in a fallback to another service? And any other AWS services you use? That's a lot of fall backs. Is the second fallback good enough? Should we add a third? In any practical sense development would grind to a halt. Twitter/Smyte are totally in the wrong for not giving a reasonable notice. I think whoever made this decision should actually be removed from their post and the servers should powered back on again with an apology to all of their clients. If they still want to shut it down later then they should provide a reasonable time frame.
teddyh 8y ago
What you just did is called a “Tu quoque” argument, and it is a type of Ad Hominem attack; i.e. a fallacy. https://en.wikipedia.org/wiki/Tu_quoque https://en.wikipedia.org/wiki/Tu_quoque
- workinthehead 8y ago
  Good effort, buddy, but no.

mickronome 8y ago

Everyone that does online transaction of money, and many more. Like all those who use AWS services on AWS.