There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0]

> With operations in over 620 cities, it was paramount for us to identify a chat solution that would enable Uber employees to reliably communicate on desktop and mobile regardless of where they were in the world.

Did Uber really need their own chat solution? Are they not better served by a SaaS product, one of 5 that 90%+ of companies are using? Are they still using uChat today? (honest question, I don't know)

This is especially dangerous when talking about security sensitive features. It is highly inadvisable to roll your own crypto

Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.

[0] https://eng.uber.com/uchat/

> There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0]

Sure, there's obviously a big difference between controlling the things that are critical to your business and wasting time outside your core competencies. And part of that difference is the risk profile: if your entire backend disappears, and takes the API your frontend is built around and all of the data with it, you're basically up shit creek. If your chat app of choice disappears, you can sign the company up for a different one tomorrow – it doesn't take 8 months of crunch to "port" your employees, and likely all of your critical business docs weren't in the form of chat history.

> Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.

Agreed. But very few internet companies can claim that the data in their datastore and the entire mechanism by which their product accesses said data is not critical to their business, which is the distinguishing factor here.

Crypto is almost always implemented as a library, and probably ultimately as a kernel module in most cases. There is no reason at all you should need to call out to a remote service to encrypt and decrypt data. That wouldn't even make sense, as it would need to be encrypted before traversing the network to be of any use. And there are plenty of commodity chat applications like Mattermost and RocketChat that you can self-host, again not necessarily needing to use someone else's cloud service but also not need to roll your own application.

Uber grew extremely fast in its initial years and that resulted in large number of teams starting NIH projects to "make themselves useful". Uber switched to Slack a while back, in addition to laying off a sizable chunk of the engineering workforce, and it didn't really collapse on itself.

Nowadays, there's a lot more support internally at Uber for buying off-the-shelf solutions instead of trying to reinvent wheels.

I see your point.

But at Uber's scale I can see the business need for a custom chat app. Most third party chat apps are bloated, both the cheap and expensive ones. Plus there's the need for custom integrations.

I used to work at a large bank and they operated perfectly fine with Window's messenger. As does every other bank in the US, despite having tens if not hundred of thousands of employees. Some things require more specialized features like trade tickets (which Bloomberg does), but for chatting, you're not gonna be able to build a better solution than already exists. And if you can, then you should spin that off into its own business like Goldman did with Symphony [0]

The nice thing about being a client is that they support all this stuff and it gets better over time. Also something like Slack is absurdly cheap compared to the usefulness and productivity it provides.

[0] https://en.wikipedia.org/wiki/Symphony_Communication

> but for chatting, you're not gonna be able to build a better solution than already exists. And if you can, then you should spin that off into its own business like Goldman did with Symphony

The implication that Symphony is a better solution for chatting than already exists / existed.

As a (non-trading) user of the platform, I strongly disagree.

I don't know what the traders think, but I'd hope there's a USP in there for them besides "it's cheaper than a Bloomberg seat."

I am not concerned with Microsoft posting an Our Incredible Journey (TM) blog post within my lifetime, but duly noted.

Microsoft, too, will pull projects, or just completely rewrite them and make them incompatible.

Applications using .NET Framework with WinForms are not just a dependency update and recompile away from being ported to .NET 6. WinForms got a whole new API and porting complex UI effectively boils down to a rewrite. At least if you can. Microsoft doesn't support third-party controls in the WinForms designer of Visual Studio for .NET 5+, so have fun trying out positions and compiling over and over.

Big companies put projects to rest all of the time. There are even whole sites with countdowns and all.

What’s an example of a company collapsing in that way? I actually can’t think of any.

These tend to be early stage startups who went with BaaS to get around resource constraints and couldn't survive the rapid need to exfiltrate their data and build a backend with a gun to their head. Larger companies generally have the survival sense not to sharecrop business critical functionality to such a degree.

Which is to say, you wouldn't have heard of them, because they never got big enough to be known to anyone beyond a handful of clients and employees. I've personally been hired to try to rescue such a company, and was not successful.

> Larger companies generally have the survival sense not to sharecrop business critical functionality to such a degree.

Larger companies have also been known to buy out critical service vendors and in-house them when there was a risk that they might otherwise shutdown or pivot, too; that's less often an option fot smaller firms.

Do you consider AWS Lambda and such to be BaaS? I'm pretty new to the field and have been focusing on AWS 'serverless' as the backend for most projects. Would you say this is bad practice overall?

(I'm not heavily experienced with Lambda but) I don't think you're in too bad a position, at least from what I've seen, as there does seem to be a portability story wrt those serverless functions.

The objection here isn't to hosting per-se – most companies aren't in the business of maintaining PostgreSQL and should consider outsourcing that task early on. If your host of choice shuts down, that's a standard service, you can dump and restore your DB and move on. Annoying but NBD.

The danger with jamstack or BaaS or similar approaches is working yourself into a place where a proprietary service API is baked into your product as a critical, fundamental dependency; if and when the host shuts down, you're in extreme trouble. That's what I'd heavily caution against.

(There's an argument that when the proprietary service is run by an MS or AWS or Google "they won't go bankrupt" so there's no risk, but even then those companies shift priorities and shut down services not infrequently).

I don't think it's a bad system to build on, but I would be nervous to have it as the only option in my tool belt. Proprietary cloud services often create vendor lock-in, and the skills you learn eventually become non-transferrable as you get more invested in their system. If you only want to work at serverless companies, or on serverless projects, that may be fine. But, knowing how to SSH into a machine, maneuver around, and how to set up a server will always be valuable

Any company built on a 3rd party API. Many examples on twitter.