Parse is shutting down, shall I migrate to another BaaS or Parse OSS offering? (opens in new tab)

Granted there were other open source Baas before, but Parse had an nice UI admin, along with nice analytics.

Overall it was a good product feature wise.

Your point is probably valid if you identify as a backend web dev, but different people have different priorities. I'm personally a product designer first and a developer second. Sure, I can set up and deploy a simple backend, but I don't enjoy it and I have no interest in learning the complexities of scaling it. Any time that I have to spend dealing with data persistence or managing a server is time spent outside of where my attention naturally rests.

Compare to a developer spending days tweaking the shadows and padding and colors and fonts of a UI component. It's "easy" to do, and it's important enough that (given the choice) many people wouldn't use an app which paid no attention to that level of detail, but it's likely time spent away from what they really want to be working on and to which they can best contribute. So just drop in Bootstrap and maybe later get a visual designer to help swap it out.

That's how I feel about backend services. Use a backend service until the app outgrows it, then---if that point is reached---it might be established enough to have someone focused on that problem swap the BaaS out for a custom backend. You have to be careful to keep your code sensibly decoupled and organized...but that's a good practice anyway (and is also the defense against your very relevant worry about the service shutting down). In fact, the app I'm working on now is at a point where, after a year, we are replacing the firebase backend with our own solution.

Basically, BaaS's can be a good crutch for some people---especially small, product design focused teams---because they remove complexity. Just like Bootstrap or Material UI can be a good crutch for small, data management focused teams. It removes complexity. Even if the complexity in each case doesn't seem to be high, every little thing to worry about adds up, and it's good to have the option of making tradeoffs.

That's generally why you want to use them. You're using something that is already battle hardened and tested.

"Plus, you don't have the risk of some business executive randomly deciding to kill your backend"

This isn't really that common, so it's not really something to worry about.

For parse-hosting, we will host each paid client on a dedicated AWS account, which is a different thing :)

I don't see any product like this succeeding if it doesn't allow customers to install the app on their own servers, frankly it's the end of wall gardened BaaS solutions, period. Firebase and co aren't going to fool anyone on that matter, they need to release an opensource version.

Not to mention the on-going maintenance of Parse Server such as upgrade / security patch.

So a parse hosting service is to keep expanding offers on top of Parse Server open source implementation, and help provide the same hassle-free services some app developers looking for.

Devops here. My bread and butter is people who start with "not worrying about servers" who eventually have to transition to "year, I'm gonna have to worry about servers".