6 ms·
Slack was evaluated a few times. The reason it was initially rejected when we first considered it is because it wasn't able to handle our scale at the time and
by uber_throwawa12 7y ago
Slack was evaluated a few times. The reason it was initially rejected when we first considered it is because it wasn't able to handle our scale at the time and the team over at Slack was not interested in prioritizing scaling for us over other things on their product roadmap.
- spookthesunset 7y agoWhat about all the other chat apps? Why wasn't the whole thing dumped into a pile of hot lava the second slack could scale to an org the size of uber? What what does scale mean anyway? Just employees using it or employees + contractors? It's easy to armchair quarterback on this stuff, but I find it hilarious how tech companies that employee supposedly smart people justify writing this kind of stuff. I'm sure some junior engineer did a cost/benefit that completely neglected the total cost of ownership for writing a chat app and focused on the sticker shock of having to pay tens of thousands a month for a chat app.
- tmh79 7y agoanother issue was data domiciling and retention policies around 2016 when uber was evaluating slack.
- spookthesunset 7y agoWere these actual concerns that were raised by the actual legal council of the company, or were they issues invented by engineers who are not lawyers but suffer from engineers disease and think that knowing to code means they are experts in everything else? 'Cause I know plenty of those! I've worked in plenty of companies with engineers who think they are legal, privacy and security experts. If we made business decisions based on these folks, we'd never do anything. Hell, every damn text change we makes invokes a few who worry about the legal ramifications ("should we file a JIRA ticket with legal?"). Sadly without somebody stepping in, people actually listen to them instead of the actual experts employed by the company... thus you wind up wasting tons of engineering bandwidth building a feature / platform / product that has no business existing all (or worse, not building some feature / platform / product) because nobody bothered to check with the legal / privacy / security team that some concern by a engineer was actually a genuine concern. And even then, in any good organization legal / privacy / security teams exist only to point out all the risks in any business decision... sometimes it is worth the risk despite what legal / privacy / security say. What appetite the company has for the risk depends on a lot of things that are well outside of legal/privacy/security.
- tmh79 7y agoit was the privacy/legal/security types driving this strategic decision, I can't really talk about it in more depth. A lot has changed since the decision was made, and if I personally was to reassess the situation now I believe I would go with a 3rd party SAAS solution, but back then building a chat app was on balance the correct decision to make.
- spookthesunset 7y ago> it was the privacy/legal/security types driving this strategic decision Booo on legal.... like I said earlier, it's easy to armchair quarterback. Sometimes I wonder how the fuck humanity even manages to make progress with so much waste and boneheaded decision making.
- deleted 7y ago[deleted]
- rrix2 7y ago> Were these actual concerns that were raised by the actual legal council of the company, or were they issues invented by engineers who are not lawyers but suffer from engineers disease and think that knowing to code means they are experts in everything else? 'Cause I know plenty of those! the general counsel and thus the entire legal org required for any company approved comms system a way to automatically by default destroy chat logs after 7 days (and to turn that off for folks who were on legal holds). slack in 2016 did not have that capability.
- GauntletWizard 7y agoThe fact that that number was "7 days" tells you everything you need to know about Uber's internal culture.
- PeterStuer 7y agoNot sure why the parent is down voted. I have worked in financial services and had the same experience. IT typically held a view on the interpretation of rules and regulations that was far more literal and restrictive than the actual compliance officers.
- mv4 7y agoLyft is no better, spending $8M per month on AWS to process 1M transactions per day.
- spookthesunset 7y agoAWS is the opposite of homebrew. Lyft has no business maintaining its own data centers and operational overhead. There is a huge opportunity cost involved with running your own infrastructure. AWS and the like free your own teams from worrying about how to provision new systems, upgrading DB server versions, etc. Running your own data center is hard. Running your own DC is the same as building your own chat app. It is almost always more expensive and almost all the people who claim they can do it cheaper inhouse aren't factoring in all the costs--both costs that are easy to measure and those that are almost impossible to measure Examples of hard-to-quantify costs for running your own infrastructure include: - What is the cost to the company of being three versions behind on mongo because IT doesn't have the bandwidth to upgrade? How many work-arounds do teams have to do because they couldn't use the latest features of mongo? - What is the cost to the company when developers cannot quickly spin up new environments like they could using a service like heroku? - How much innovation and new business (read $$$$) is not happening because the in-house IT simply doesn't have the toolset so a dev can quickly riff on an idea? - How many engineers have good ideas and don't bother building them because spinning up an environment is too much trouble? I'd argue by not using AWS you are holding your product teams back and stifle innovation. Unless of course you want to waste company money to build out your own half-assed provisioning tools that are lousy knock-offs of AWS's tools. But then, you might as well just use AWS...
- mv4 7y agoI should have been more clear. AWS is absolutely the right choice. What I was trying to point out is someone engineered a system that costs 8M/mo to run yet only handles 1M rides per day.
- aloknnikhil 7y agoI don't see the analogy here. This is Lyft's core business. Of course they'll go all in. On the other hand chat is not Uber's core business. They didn't have to reinvent the wheel for an internal tool.
- derefr 7y agoInteresting. IBM adopted Slack just fine, back in 2016. I believe they've got at least 100k employees in their Slack workspace. Not sure if it's Slack or IBM doing the hosting/scaling for it, though.
- kortilla 7y agoHow many Uber drivers are there? Also, don’t forget that slack has an API so write loads can be very different regardless of user count.
- arshbot 7y agoWas this chat app for external contractors as well? Highly doubt it.
- TheSpiceIsLife 7y ago> How many Uber drivers are there? None, they're all independent contractors.
- kortilla 7y agoThat’s still an Uber driver. They’re literally being contracted to be so.
- alexis_fr 7y agoThere is a cultural difference between Uber and IBM which would explain why Slack didn’t shown its limits at IBM: Slack people belong to a startup which typically wouldn’t mind get everything done in a chat; whereas IBM is a 100+ years old company where everyone has to fill a paper form and managers type with two fingers (Source of this specific example: I’ve worked with IBM consultants with one of their products). Chat apps do not play the same role in each.
- AlexCoventry 7y agoAn organization involved in as much sketchy drama as Uber has probably doesn't want its internal communications on someone else's server.
- sdan 7y agoOn top of that they 100% can read your private messages
- shaklee3 7y agoThere's no way this is true. There are companies far, far larger than Uber that run slack with no problem. Even the public kubernetes workspace has almost 75k people in a single channel.
- danpalmer 7y agoThis has only recently been possible. For a long time Slack was capped at 5k per workspace, then later a similar number per channel.