I'm pretty accustomed to executives making dreadful decisions without the approval/acceptance of other stakeholders within said person's firm. I'd rather know who made this error and not interact with that specific person's department rather than stop doing business (e.g. large ad-buys) with Twitter as a whole.
I don't want this to be a witch-hunt so much as I want the person to just come forward and own the decision, because unless they have an exceptionally good reason for it, it comes off as absurdly high-risk to both Twitter-the-business as well as to all the clients who've likely written serious penalties into their contracts for events like this, which again brings that business risk back full-circle to... Twitter.
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
It's talking about how we all talk to each other. I think it's main purpose is not to lessen criticisms for corporations so much as to keep the discussion constructive.
The parent comment actually seemed spot on to me. The rule is to assume good faith of your interlocutors. The parent failed to assume good faith of a billion dollar corporation. I think it's reasonable to push back against being asked to tone down the latter, while honoring the rule for the former.
That is a metaphor made with an industrial grade cement mixer.
I don't like the implication here (i.e. white men don't care about harassment/abuse and they are also stupid.) I would wager that most anyone of any color or gender or religion in any high position of authority at any company cares first and foremost about the financial viability of the company they have been charged with running.
Many (most) "white men" do in fact care about this stuff and aren't bigots/sexists/racists. You're naive and part of the problem if you think this is a "white male" issue and not a much more complex problem. In fact, you're exhibiting the bias you attribute to these managers.
Also, we can all have biases without it meaning people are being racist. My parents like rock music, so I'm biased towards listening to that over country. I went to certain schools and that colored my world view. I once heard bias described as a heuristic the brain uses to make quick decisions- something that was extremely useful for primitive humans but which needs to be actively balanced in our complex society. A huge part of that for decision makers is exposing themselves to other viewpoints as a way to collect information they themselves wouldn't have gotten. There's a reason why companies have used things like focus groups and surveys to understand their customers- having more people who understand those customers in leadership at companies is an even better way to do it.
This is nothing particularly new. It's the history of America, which was founded by and for white men, and whose story can be told as white men slowly and reluctantly giving up their power.
If "many (most) 'white men' do in fact care", history doesn't really demonstrate that. Not, at least, in terms of doing anything about it. This is not particularly shocking; people care more about problems they experience, and less about problems that happen to benefit them.
We need only look at how the majority of white men supported a blatant racist and sexist for president. And who continue to support him despite (or because) that has only become more clear.
To the folks inclined to keep piling on to this comment, I think a more charitable reading is that "The leadership consists of very privileged people who likely haven't dealt firsthand with the kind of harassment to which some demographics are routinely subjected. They appear to just not really get it at times."
I think that's a very realistic assessment of how some things remain intractable. People in power have blind spots because it isn't something they have to personally deal with. So they end up doing things that are counterproductive or seriously problematic without really meaning to.
That doesn't make it okay. That's just reality.
Same problem. Who's to say they are "privileged" as opposed to being hard working / talented people? You're pushing the same narrative; white men in positions of power are privileged and don't really deserve what they have. Nonsense. Sometimes that's true, sometimes it's not. Either way it's a useless, tribal way of thinking that does more harm than good.
It's completely fair to comment on this because it is the basis of the GP's argument.
Just like a developer is going to spot defects in applications more than a non-technical user because they are exposed to defects more often and understand where things will fail, people who have lived discrimination will be more likely to see it where it happens, and understand where to look to find it.
It's sort of tautalogical to say "People in power don't live like the rest of the world." And this fact has been a problem in terms of creating policies that work well for the masses since time immemorial.
It's an important distinction as it sets the parameters by which we engage in conversation and debate. If you begin the conversation by accusing the other side of being inherently bigoted then there is no civil or useful exchange of ideas to be had. It puts the other side in a defensive posture from the get go and only leads to more tribal group-think.
Both sides need to give a little here if we aren't going to remain stuck on such topics. And expecting all that giving to come from women, people of color, and other underprivileged groups is merely entrenching white male privilege in a really ugly, toxic manner.
Because I don't believe it is valid. Class/color/gender are not the only influencers on someone's decision making process, yet you two seem to think that's all we need to consider.
Where is the evidence that these people don't care about abuse and harassment because of their class and color? I see a pretty damning statement which includes zero evidence, just what someone believes to be true for <reasons>.
So no, I won't accept your premise or the GP's until I see evidence. If there is no evidence then fine, you and anyone else are free to believe whatever you like, but don't pretend it's a logically defensible position.
>This is a perpetual problem where one group feels unheard, unserved, left out, etc and then they complain about that and then are told their complaints aren't valid because they said them in a not nice enough fashion or something. Both sides need to give a little here if we aren't going to remain stuck on such topics.
Not every complaint _is_ valid, and we have no idea what the GP's motivations were. I'm not going to give any ground. You and the GP are taking a complex issue and boiling it down to something absurdly simple. All that I'm saying is that it's not simple and, if we're ever to have a reasoned debate, it needs to be predicated on facts, not "feelings". If you're going to attribute someone's actions to their gender and race then you had better be able to back it up.
It's telling that you believe _I'm_ the one doing harm when I have made no accusations at all and the GP was inarguably expressing a racist view.
If you really can't get over your feelings of personal insult and your need to defend white men, then please go back and substitute "part of the socially dominant racial group" for "white" and "part of the socially dominant gender group" for "men". In US history, those terms are equivalent. If you don't like that, talk to the founding fathers who set it up that way.
The reason it's material here is that a large portion of Twitter abuse is related to this. You can look at famous incidents, for example. Leslie Jones received a giant wave of racist, sexist abuse: https://www.thecut.com/2016/08/a-timeline-of-leslie-joness-h...
And the company admitted they had failed massively: https://people.com/movies/twitter-ceo-jack-dorsey-speaks-out...
You could also look at the differential experience of white men versus others on Twitter. E.g.: https://www.theroot.com/twitter-has-a-serious-harassment-and...
Note also your standard here. You, a white man, refuse to accept that race or gender could be relevant to a social problem until other people take the time to spoon-feed you. Why isn't it your job to know something about American history? Why isn't it your job to learn about the problem of online abuse before deciding that the privilege afforded to white men couldn't possibly be the relevant? Answer: because you were raised to believe that whiteness and maleness were the default and were good. So you choose that as your supposedly neutral stance, and require others to prove you wrong.
The true neutral stance would either be "I don't know about this problem and would like to learn" or "let's assume that online culture has some relationship to the existing offline social dynamic".
The employee who is familiar with them.
The problem is not the genetic characteristics of whiteness or maleness. It's that they grew up in a society that favors whiteness and maleness, and is much more accepting of the abuse of people who aren't so favored. If Twitter had started in China, where the Han are favored over ethnic minority groups like Tibetans and the Uyghur, it would be the same dynamic but with different ethnic groups.
Of course, tech is disproportionately white and male, so it's entirely unsurprising that HN readers have risen up en masse to defend the honor of white men. It exactly proves the point. White men will say that fighting abuse is important. But when they have to show their real priorities by how they allocate time and effort, actually understanding the abuse problem and how it disproportionately effects minorities comes well after defending their own interests.
(And: Yes yes, not all white men. Generalizations are general statements that may or may not apply to an individual.)
I'm not a feminist. I'm a former homemaker that self proclaimed feminists routinely crap on. I come to Hacker News because I need a place where I can engage in meaty intellectual discussion so I don't lose my marbles. That is my only agenda for being here. However, dealing with sexual politics is not something I can entirely avoid what with posting as openly female.
Suffice it to say that I don't really want to be associated with this toxic attitude and I am kind of wishing I had not said anything at all. I am starting to feel like "The only winning move is not to play" and I failed to make that move.
Not judging the individuals, but the history of this culture is very well covered.
That's an awfully biased viewpoint you've got there, good grief.
Wow. Racist much?
Twitter could have stepped in and halted things, but that would have required Smyte to have acknowledged breaching the contract and forfeiting $$.
This is all guess of what seems to me more likely than any Twitter exec pulling any triggers like this. Of course, it's still a screwup by Twitter to have not been tuned in and aware that fingers would point to them.
But that's a very different kind of mistake than "I have an idea, let's hit the power button at 6:30. Team: you have 30 minutes to let all our customers know."
But you're actually right -- if the acquisition hasn't closed yet, they're independent and independently responsible.
My hunch as an outsider is that Smyte wasn't GDPR compliant. Their leadership knew it, they knew they couldn't easily become so (for instance, they may have been using Kafka in a way where compaction wouldn't help, and didn't want to build an encryption-based monstrosity ), realized that they wouldn't increase in value as a business due to that risk, took an acquihire for cheap in order to give their employees a decent landing and give a return to their investors, and couldn't tell anyone about these plans in advance because it might jeopardize the transaction.
EDIT: They were indeed using Kafka per , and due to the strict latency requirements on their business, that may have ruled out the type of encryption scheme in .
GDPR does seem like the most likely culprit here, if they've been planning an aquihire for a while it wouldn't have been worth implementing GDPR and Twitter likely made it a condition that the service is shut down before the acquisition completes
I'm quite surprised none of the cloud vendors were interested/could offer more than Twitter for this team though, seems like a logical service to add.
It could also hamper their ability to make further acquisitions. In future, a startup being linked with a possible Twitter acquisition is going to cause its customers to panic and start moving elsewhere. That'll make startups more reluctant to engage, and may turn some off entirely, if they're not comfortable with the prospect of totally screwing over the customers who've supported them during their early stages.
I think potential for reputation damage, on an activity they don't do very often, and where they will justify it, will be weighed up against the financial benefit now, and disregarded.
I think it's possible to overstate the relevance and importance of people typing furiously on internet forums about things like this. Twitter is what it is - most people aren't using APIs, third party clients etc and will never notice this.
This isn't about people typing furiously on internet forums. This is about business risk, as weighed up by people whose job it is to care. Acquisitions take time and negotiation. Just because a startup is talking to Twitter, doesn't mean the acquisition will definitely happen. But if customers get wind of it, then they may start looking to move elsewhere, anyway, instead of waking up to find services they rely on have been shutdown without warning. If you're the customer of a startup Twitter is negotiating to acquire, then you're negligent not to reduce your reliance on them. And if you're the CEO of that startup, then you have to consider the risk of customer flight (and your own comfort with the thought of screwing them over) vs. the likelihood of the acquisition happening.
Why would anyone else?
Let's not forget that those customers are also likely candidates to advertise on Twitter
But that doesn't come with any actual guarantees does it?
Yet... that you know of.
Nothing specific against Sift Science whatsoever in my comment, but many, many times this sentiment has been conveyed by companies and it rings hollow IMO. There are a lot of different ways a company can change or disappear at some unforeseen point in the future, and claims that "you can trust us to be here forever" do not carry much weight for the large group of experienced users, devs, management, etc who have been burned multiple times.
Clearly, you need to always be prepared for your partner to go away, but you still have to work with other companies.
Sure, that's the intention but when someone comes around waving a checkbook, they can in turn buy you and shut you down, sell your customers' info, etc. Sure, its not YOU allowing that to happen but by ceding control you essentially allowed that to happen.
I've been on both the customer and service end of such agreements.
You can have a contract where you specify indemnification of damage in case the business ceases operations, goes bankrupt, get acquired, etc...
In time, the situation can change. The product can get sold. Cash can be spent. The guarantor can no longer make good on its guarantees.
You're back to square one where the guarantees are as worthless as the original service.
You need 3rd party backing (insurance) in such situations, but that costs money. This money is a cost which makes competing against unbacked entities tougher.
In most cases, you can not have 100% foolproof guarantees of anything. The closest I can think of is governments standing behind their banking institutions. Even there though, governments have defaulted on their guarantees.
The world is not a stable, perfect, and cut-and-dry place as many would like to believe. It is dynamic, and ultimately backed by trust.
The problem has always been present especially when larger slower moving companies buy from smaller, riskier, companies.
In the days of software, code escrow was possible to mitigate some of this kind of risk. That's still got it's costs but can be an effective hedge against a supplier going bust.
While you can have a contract that indemnifies that isn’t going to help your going concerns when the other party just pulls the plug.
Half an hour of warning, to screw over all of these?
They broke npm's user sign-ups, and publishing of packages, with half an hour of warning.
I can't imagine the havoc over at Zendesk either.
That is not 'winding down'. That's ghosting.
Tbh that has always frustrated me though. I should be able to pipe those requests and just add an X-Forwarded-For header.
Is there any indirection that would avoid having to walk the traffic over my own network?
Obviously you then pay the bandwidth, but it’s likely negligible compared to your app traffic. As a bonus you’ll probably circumvent adblockers.
If you want to avoid traffic forwarding, but keep flexibility over the endpoint, you can override the init of the sdk to first query your server for which endpoint to use. That way if the third party service goes down, you just need to change the config on the server.
I wonder how much Twitter is going to pay on top of the acquisition cost of what I can only imagine constitutes breach of contract with all of these companies. (If it doesn't, why even bother having a contract with a duration?)
Acquirers usually prefer asset deals for this reason as it allows them to leave unpleasant liabilities behind. There's generally some sort of shell left that goes through wind down but it has few/no assets attached. In this case you can try to go after the original investors including founders or other shareholders (the IRS may do this if there tax issues) but since there's nobody home you are less likely to get much out of a favorable judgement.
Moreover recovering damages in this kind of case is time-consuming, doubtful, and too late to fix anything. (Like closing the door after the horse is gone.)
What's left is reputation--the names of the founders of Smyte are listed at https://www.crunchbase.com/organization/smyte. I would have some pretty hard questions if they ever showed up in a deal or looking for work.
p.s., According to the Techcrunch page "Smyte stops bad actors on marketplaces and social networks." You can't make this stuff up.
I expect one or more lawsuits to emerge, maybe as a class action. It might not come to trial and simply wash up as a settlement.
I am not now, nor have I ever been, a lawyer.
Twitter owns Smyte. When you buy a company, you acquire all of its responsibilities. There is no longer a Smyte to point the finger at. It's all Twitter.
I’m actually surprised that it was done in this manner, as many startups have a “business continuity” section in whatever contracts are drawn up with customers, detailing the specific steps and timeframe of retiring a particular service. I would have thought this is standard practice for a SaaS company.
Twitter owns this now and the way to ensure it's their reputation that is affected over the long term is by correctly calling this a "Twitter" failure.
Unless you're advocating against any kind of *aaS, this is kind of a silly argument.
A lot of these services are not "a few days of development" worth of work. The value in these is that they have dedicated teams of people who's entire job is to run that specific targeted thing. Unless you're willing to also invest in major development, it's going to be difficult to match that functionality.
Obviously when you make your product/company depend upon these things, you're taking a risk that they could go away, but you protect yourself against that by having robust contracts.
Outages are different, but for a significant outage you expect to see some kind of RFO and explanation of how they're going to mitigate it.
Deliberately withdrawing service for all customers with 30 minutes notice? That's entirely the fault of whomever is in charge at Smyte.
Even 30 days, while it'd probably ruin some existing plans, would at least allow people to have a chance to migrate without things just breaking.
For the cases I was involved in, there were options of buying the service but hosting it internally with some update pipeline. So even if the updates were suddenly turned off, you have a far longer time to swap to a different system. Generally deploying these aren't to much time, but what is really the issue to me isn't that the options that were chosen were the ones which were chosen, but that the process of choosing them did not evaluate the risks of creating such a strong external dependency at all. Its one thing if it is a risk taken with full knowledge of the potential costs and benefits, it is another when people do it because they think there is no possible downside.
* No website or app should ever call out to any third party API
* Every single piece of functionality a website or app has should be developed in-house
* The functionality third party APIs provide would often take "a few days" to reproduce in-house
Definitely. Your website and app should only call your APIs. Your API can then call the third party API from the server. It's a lot easier to change something on the server than having to update the app.
It's not really addressing the whole issue of depending on third party APIs if your API is calling on them, but you are technically correct, which I've heard is the best kind of correct.
No. Delegation is the cornerstone of civilization. Trying to build everything yourself is a terrible idea.
Per the article, they did at least have long-term contracts locked in with Smyte. That's not the same as control over the feature, obviously, but plenty of companies do business on the strength of contracts instead of vertically integrating their entire product.
Obviously we don't have many details yet, but I think there's a real difference between simply using a third party API that works for the moment, and buying a service from a third party. If Twitter/Smyte simply broke contract with all their existing customers, that's very much their responsibility.
Would Smyte's rating have cut it for people?
The problem is, if all suppliers use the same contract clauses you may not have a choice.
and how would their credit rating be affected if they pay all their bills but just reduce the number of bills gradually over time?
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)
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.
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.
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.
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?
Apparently, they were a dominant player in this space, such that its shutdown impacted such a wide array of significant-sized companies, from ZenDesk to TaskRabbit to Meetup. Even more surprising is that they were part of YC (W15), and yet from what I can tell, have only had one significant mention on HN from 3 years ago (65 upvotes, 11 comments)
I would've guessed that Smyte would've been the kind of Silicon Valley business that was made for media hype (what with all the attention/criticism given to fake news and Google/FB/Twitter moderation). Then again, it does seem that content moderation -- important as it may be -- isn't a field as sexy as AI/deep-learning and other forms of automation.
In the former, you can take the assets (including employee contracts) without the liabilities.
There's actually a reasonable quora answer (for once) on this, saving me from writing it up for you :)
Don't know, not a lawyer.
At the end of the day, judges (and appellate panels) have to interpret the law and they don't function like automatons. They take into account the spirit of laws/contracts as well as the letter and most have enough common sense to get missed off at these naive tactics.
(All of this is a good reason i hate LLC's. They aren't necessary anymore to actually do risky innovation in 90%+ of cases. In a non-LLC, they shareholders would be liable, and then you'd still have someone to go after)
Usually, they would use the cash to wind down.
I guess the liability is covered by the usual "no liability outside provision of the service" clause - so you can't claim that you were damaged by their lack of service. But I can see a lawyer making a convincing case that the liability should rest with Smyte. IANAL, obviously, but it seems like the sort of thing they love to fight about ;)
gets popcorn this one will be interesting...
There might be a carveout for consequential damages (which would be huge here), but this seems like it will trigger a number of sizable lawsuits against Smyte's new owner.
If nothing than just getting a pound of flesh from twitter.
So... what was the Service Level Agreement? and the Terms Of Service?
People get all hyped by -aaS stuff, but services do go down, and if you aren't the one controlling when and how they will go up, then you better have a contract with the Service Provider on some terms you like.
Even then, prepare for when they go down, because they will sooner or later, for shorter or longer periods of time.
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.
This is always trotted out and it's, by this point, a completely content-free thing to say. Short of removing yourself from the economy and society in general to live off potatoes grown in your own dung, you're going to rely on some external services and the fact that, for the most part, the parties you do business with will behave responsibly. When they behave very irresponsibly, unpleasant things happen and people quite reasonably complain.
* Malware detection?
* Customer support software?
* Website uptime monitoring?
* Accounting software?
* Email delivery?
I'm not going to argue that one is better than the other when it comes to SaaS vs self hosting. But people in here seem to have very short memories when arguing that self-hosting isn't at all viable. In fact I have personally supported all of the above in self hosted versions in the last couple of years.
I also have the experience of managing many of these services, and I therefore know just how much more productive you can be when you don't need to do it yourself.
Of course there are trade-offs; business is nothing if not a game of tradeoffs. We're just talking about what is optimal.
 Not to mention how much more stable and secure; Self-hosting can involve huge security and reliability risks.
I don't believe what is optimal can be generalised like that. "Optimal" is going to be specific to the business in question. Which is why I'm a firm believer of leaving all the options on the table.
> Self-hosting can involve huge security and reliability risks.
In fairness so can the cloud. I personally don't see difference as 'risk' but more 'responsibility'. Some of the places I've worked have been PCI DSS and Gambling Commission audited so we had that responsibility already. Self hosting a few other resources didn't really add much extra in terms of our security responsibilities. But the case would be very different of lots of other different types of businesses.
It's worth reminding ourselves that the root comment was an absolutist assertion about the folly of outsourcing.
So the discussion is easily resolved: don't be absolutist :)
Even that strikes me as a mischaracterization, or, at best, taking just one statement out of context.
It was an assertion about the folly of relinquishing control, not being prepared for that lack of control, and thereby subsequently suffering a prod outage.
Yes, any of those sounds like a good enough plan B. You don't need it to be perfect, just good enough to avoid getting stranded in a pinch. Then you can start shopping around for someone who does that one little thing much better than you do. That way it no longer is a show stopper and rather just an optimization problem.
For starters, most smallish companies I know of use housing for their servers. So, they actually do own the hard metal servers and have full access to them. Both over SSH and on the console for debugging purposes. The housing provider generally replaces HDDs in case of disk failures. naturally, you're still dependent on electricity and internet, but even that can be mitigated by spreading your servers across several locations.
All of that is obviously possible with AWS, GCP or other VPS hosts, but doing it yourself is not that much harder if you've got an experienced ops person that wants to bother with all of that.
but i repeat... Its often not worth the time investment to get that system properly set up. Just renting VMs or going straight into dockerized microservices is an increasingly better alternative
Your local restaurant going out of business is no reason for you to starve to death, you just go to another one, or to a grocery store, or indeed grow your own food if you're in some post-apocalyptic world or got no money... but somehow a service provider going out of business is reason enough for your production to stop? No, just no.
I don't think anyone is suggesting never to outsource, or even that the answer to "build vs. buy" is always "build".
The point is not having a critical dependency on a single vendor.
I don't think anyone is even saying "never", either.
The question is one of risk.
The risk of your tax accountant "going down" (or being crooked or something) is sufficiently low, and the cost of making that redundant is sufficiently high, that I don't think anybody does that. This could even apply to general accounting software, though one might argue that's not critical in the same way and/or more easily replaceable.
There's a sibling sub-thread that essentially implies, if not outright states that there's no choice but to "buy" in "build vs. buy". Although it may be true that building is no longer a practical choice due to time/cost, under certain circustances, it by no means eliminates the risk if there's only one vendor.
It's also a decision that can end up having tremendous costs at scale, if not re-evaluated, especially with even a soft version of vendor lock-in, like AWS.
you did not include "so much that if it goes down it would cause a prod outage" in your quote, which is why the strawman claim was put forth.
This is yet another strawman. The original commenter found it "silly", which, I agree, was a poor choice of wording.
Perhaps "overly risky" would have been better. I don't know. I just take the most charitable reading, per the guidelines.
It also comes after an exhortation to have a contingency plan, so it's at least implied that the "silliness" isn't inherent merely to the dependence but to the dependence without such a plan.
> in many, it's a completely sensible tradeoff
Is the tradeoff actually considered, though? Or is there just an automatic "we're not a nuclear reactor" decision process?
> is 100% uninteresting
Were that true, I doubt there would be replies. This is not one of those traditionally emotional/political issues.
> Including or not including 'in prod'
I (again, charitably) read "in prod" as a metaphor for "business critical". I'm sure we can all come up with examples, even in Internet companies, where one does not necessarily mean the other (or vice-versa). In the instant case, it seems to apply, so it made sense as shorthand.
> It's just lazy grousing.
I would agree if there were no built-in suggestion on how to avoid the problem at all, but there were.
Just because the point has been made before doesn't make it any less valid, until it has been refuted.
Only if 'strawman' means 'thing I disagree with'. The comment says such a dependence is bad and how you have to prepare for it with SLAs or whatever. This isn't universally true at all.
I doubt there would be replies.
A lot of really boring, trite things generate piles of replies. That's why they should be avoided.
Just because the point has been made before doesn't make it any less valid
The stated goal of the forum is not 'an exhaustive, if repetitive collection of generically valid things'. Remember that time you wanted to print something and the thing just wouldn't print? That's bad and annoying. It's valid that it's bad and annoying. We probably don't need to talk about it in the general sense every time it happens, though.
Only if you pretend there are no companies that do in fact responsibly nail this stuff down. There's plenty. Your argument seems to be that nobody does it because it's hard.
There are pretty solid SLA's for that. We provide some services as kind-of-saas but the SLAs are watertight.
Usually in those kind of sla's you can't sell the company (or move assets) without guarantee of delivery of the contract. In some cases they (the contract holders) even own you if you screw up and go under.
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?
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.
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.
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.
There is a popular C# package called Polly that has all sorts of fault tolerant strategies.
In this case, use a Fallback strategy that responds to an API failure with some type of generic success response.
I'm calling it now: B2B startups will soon have to sign poison pill contracts that specifically detail what happens if they're bought out. This might ruin the "buy them for their people and discard the business" method of hiring - or at least it will if the customers have any sense.
I had assumed Twitter was going to be paying out a bunch of breach-of-contract penalties, because this is basically what contracts are for. Is there a standard way around this?
I postulate more than few roles were halted at that time.
Also I wonder how many customers are staying quiet, because "our fraud protection provider just stopped working" isn't something they want to reveal.
(Disclaimer: I work for a smyte competitor).
I'm confused; how do you know these companies did not do that? In my experience even small companies will typically abstract away a third party service so that if it does fail it fails in an expected way.
What you seem to be suggesting is that all of the companies failed in expected ways. I didn't see that in any of the articles. Did you have a source? I'm curious if it hit some harder than others.
That's an outage...
>manual verification of new users
So is that, unless you have tons of customer support reps sitting around doing nothing when shit hits the fan.
Seems unrealistic especially since the majority of times when these services go down it's likely just a short time so they probably have abstracted around them to avoid unexpected failure and just have routine, down time failures.
Every tech company big enough probably sees the same writing on the wall the rest of us do that it's time to press their advantages. That means shutting everyone else out.
We probably all have mission-critical parts of our infrastructure that aren't core competencies. We probably can't afford for them to go away tomorrow, but now it's time to expect and plan for it.
Get ready to ride the consolidation wave.
The goodwill itself has to be worth a TINY bit.
Companies like Twitter whose core business is to shit on their users and customers don’t care about goodwill.
Imagine if Google decided that tomorrow at 6AM PT they were pulling the plug on YouTube embedding, or GMail / GDrive integrations. The court's going to say, "They put in the contract that they can change the terms of service at any time, and they're not liable for outages or lack of service. And you signed it. Sucks for you."
Then again, I'm just anti-corp in general and this gives me better reason to avoid Twitter.
This will be how it turns out for a few big players with deep enough pockets. Surely though this is hurting somebody's business that can't afford the lawsuit -- potentially to the point of putting them out of business. That's good for Twitter (and especially Twitter, as precarious as they are).
We've all joked for years about how FAANG pay their engineers so much mostly to keep other companies from being able to hire great engineers. We've gotten the big three slapped for colluding against their employees on wages. Why do you think they would engage in some anti-competitive business practices and not others?
Not a lawyer, just interested.
I'm not sure how good apple is, but when they buy software available on Windows that version usually gets killed. (See Logic music production, killed 3 months after purchasing, but presumably the old installs still worked.).
Even Halo was demoed on mac before MS bought it (The mac version never came out)
I bet their term of services mentioned that they can cease operations on no notice.
No company lawyer I know would willingly put their signature on such a contract unless the other side is using a free tier. If someone actually signed 3 year contract with such a clause, congrats, you managed to throw a lot of money into a black hole.
1) If your business depends on Internet access you shouldn’t pay for a residential plan. You need an SLA.
2) Natural disasters happen. Not having emergency drinking water is very naïve.
3) If your business depends on electricity you should also get business rate with SLA and maybe have a backup generator or two. Heck, I have a UPS just to not lose the 15 minutes of work that’s not automatically backed up.
4) Yes, get a weapon (preferably a gun) and at least know enough first-aid to be able to stop a bleeding. Keep an aspirin on hand in case of a heart attack. Know your emergency exits and evacuation plan. Make sure you have the mindset to leave all your possessions behind in a burning inferno.
All of the above used to be common sense before technology made us think we are immortal and entertainment distracted us from real world.
What I've seen was a select group of companies and their users who've been inconvenienced by the abrupt shutdown of a service; and whose unpleasant experience should be used to teach every user - this can happen to you. I would not be at all happy if, say, the servers for medical tracking software used in hospitals around the world went down the same way; or if suddenly air traffic control software that every airport uses goes offline.
This particular situation doesn't cause potential physical harm to a human being. It's not actually an emergency situation. That, to me, is a major difference.
I think the issue here, other than earthquakes being potentially very deadly, which makes this comparison a little absurd, is that they are in a sense unavoidable.
On the other hand you can avoid using SaaS.
For example, there’s enough market demand for Github to provide on-premises secure hosting. Clearly then, if SaaS as a whole is seen as fundamentally unreliable it will create more market demand for similar on-premises, or open source, or otherwise “buy not rent” model services, which I see as the motivation for OP’s comment.
You don't spend a lot of time on Facebook, do you?
Which is especially weird for Twitter. Their official iOS client was a third-party API client they bought. Third-parties created @replies, #hashtags, etc. If anyone should recognize the important of third-parties using APIs, it should be Twitter... yet they've been probably the most abusive of the large APIs.
I'm not sure they know what interop means.
Something something, a good craftsman doesn't blame his tools.
Twitter will never change how they do business, replacement is the best strategy.