I've never seen a company collapse because their garbage collector posted an Our Incredible Journey™ blog post and then shut down a week later.

I have seen multiple companies collapse because the proprietary Backend-as-a-Service they built their sand castle on top of pulled a vanishing act, however.

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.

The difference is that you don't pay a monthly subscription to use a garbage collector.

Garbage-collection-as-a-service would get a ton of venture capital though.

Oh wow, AR/VR mark/sweep applications! Those VR rooms get messy, who is going to clean them up?

At patent office right now with this. My attorney said will go through the USPO like butter.

There are a ton of a companies that help you track cloud spend, while some of it is architectural, most is really about waste, old ec2 image backups, s3 with no lifecycle policies ... garbage

Hahaha cloud-based garbage collection. Made me giggle.

There's two things happening in this post:

1. Development environments are running on Kubernetes, and VS Code is remoting into them. You don't have to pay a monthly subscription for that. VS Code remoting is free-as-in-beer and Kubernetes is free-as-in-speech.

https://code.visualstudio.com/docs/azure/kubernetes

2. The actual Kubernetes hosting is the product "GitHub Codespaces" running on Azure. GitHub certainly isn't paying a monthly fee to themselves for this; they are, technically, self-hosting it. I agree that you probably do want to have the option to run it yourself, but I think you do, given 1.

Microsoft probably does internal billing here, right?

I mean, probably for the actual Azure usage, but that's not different from billing yourself for development VMs or Mac laptops or whatever (i.e., they'd be doing that independent of this approach). I assume the Codespaces team is getting plenty of value out of GitHub dogfooding the product and doesn't need to bill themselves for its use.

This is already a thing, if you look at Java (old-school ik), Oracle vs OpenJDK [1].

I don’t see why that would be a problem though? If I can pay a company to provide improved GC for my infra, where the cost savings made it beneficial, I would do it…

[1] https://superuser.com/a/1365224

have you heard of Azul Zing?

(not entirely serious, but it has a very expensive monthly fee for what is in essence a better GC algorithm)

I bet somewhere you just gave a Lang Developer a monetization idea...

This will be coming to a cloud service near you

The garbage collector should pay _me_ to use it.

> The difference is that you don't pay a monthly subscription to use a garbage collector.

In some cities you do, and they're often controlled by organized crime.

(Whether this comment is a metaphor for SaaS is left as an exercise for the reader.)

I'd argue that it always held true to a certain extent. You don't necessarily need the underlying knowledge to be an efficient programmer in Python, but knowing C or Assembly certainly gives you an edge when it comes to, well, edge cases.

And it isn't all about efficiency. Programming and CS is such a major part of my life, that I want to know the deeper parts, and I want others to understand it too. Programmers who do not seek that knowledge I unjustly judge for it.

The opening to the second paragraph honestly reads like satire of something that could have been said at any point in the last 50 years.

You're totally right. Javascript and its ilk are clearly superior to the languages and tooling of the past. There's no doubt about that.