Parse’s product is still alive and well—and supported by Facebook—and that isn’t going to end any time soon. (ReadWrite, feb 2014)
Fast-forward two years, and Parse is shutting down, effectively pulling the plug on about 600k apps that are in one way or another relying on the service. The good news is that the software is now open source, but that still leaves many developers and companies worldwide having to face a painful migration process. And this pain is, understandably, shedding a pretty bad light on the whole BaaS ecosystem:
Developers have already been fooled twice over the last few years, first by StackMob shutting down and now again by Parse. It would be foolish to jump ship to yet a third proprietary platform and run the same risk all over again. (n0damage)
The black-box model sounded great initially – you spend all energy on building your app, and no energy on dreaded backend things, like data management, dashboards, hardware or scaling. Until you do, that is. And that’s where Parse broke its promise to users – it didn’t take the pain away, it just postponed it for a while.
A key takeaway from this is the need for transparency. Companies still need robust, dedicated software layers, the only difference now is that many are realizing that the containers need to be transparent instead of opaque. Proprietary means you can never trully assess in a timely manner things like how safe you are in case of a service shutdown, or how secure your data is. That’s why open-source is the way to go forward.
The real lesson is any BaaS that is free should be suspect. (fubarx)
We run an app with 1.8M installs on parse’s free plan. We’re not database heavy by any means, but come on. They could have jacked prices up a bit more aggressively and we would’ve gladly paid. (eandi)
If a startup is not turning a profit from each individual client, then it’s burning through other money and hoping that, until those run out, it will figure out profitability. That’s a huge gamble to take with any service that basically powers up your applications. Especially if it’s closed source, and especially if it’s free.
Having a free tier is a great driver for developer adoption – but that’s proven to be a strategy that has hurt the ecosystem as a whole. Viable companies have leaked money until they died, while many developers are now facing the technological debt of “free”.
BaaS services pushing forward will need to have a very well defined financial strategy. Simply baiting in millions of developers to register and start using your platform has proven to generate only hype – few of those developers would ever convert into paying customers, making sales as well as support painful. The true metric of the future is paying customers.
I’d rather do more work on Amazon with the option to fall back to Google, than do less work on Parse but with no plan B for my back-end. (Tim Hampson)
Traditional BaaS builds on top of IaaS in a closed way. With the dawn of Parse, all the cloud infrastructure powering the service will be terminated, even though many customers would probably be happy to pay to have their individual app still operational. It would justifiably be too much overhead for Facebook. And any BaaS out there could end up having to shut down as well, and cause the same havoc.
But that could never happen if customers were in charge of the infrastructure in the first place. Decoupling the backend from IaaS – or building on top of IaaS in an open way.
Traditional PaaS companies have been trying to do this for years, with varying degrees of success. Heroku, AWS Beanstalk and Google’s App Engine all promise to make infrastructure transparent from the developer’s point of view. This, however, only brings rigid restrictions to the software stack running the back-end services, while increasing costs and leaving the customer locked in like a BaaS would. Only in this scenario, the customer still needs to actually develop a backend solution on top of the PaaS service.
When building on top of an IaaS provider directly, the customer can transparently choose a platform provider, and the backend layer will be deployed, operated, scaled and kept up-to-date and safe on private, dedicated machines provided by the platform and maintained by the backend provider. Infrastructure costs are transparent, scale with usage and are handled by the customer directly. The free tier is now provided by the platform. The customer pays the backend provider a yearly fee for the service. That’s great for the backend, as well as for the IaaS.
Granted, end users would then need to allocate energy into planning and thinking about their infrastructure. The once plug-and-play box would be replaced with a really transparent and configurable box that looks scarier. But the thing is, as we’re seeing now, developers that work on production-level apps will eventually need to worry about this part as well. It’s much healthier to put in a little more work in the beginning of a project if that makes you future safe. It’s about balance.
Firebase and Parse were (and are) both great for prototyping. However, I firmly believe they should not be deployed to production as an integral part of any product. (brendan09)
Bottom line, Facebook has eventually done the right thing by open-sourcing Parse, and encouraging users to move to their own hosted versions. Newer versions of Parse are even getting a feature that’s been notoriously missing from the closed source version, and that modern platforms have been offering for a while: realtime data querying.
— Claes Jacobsson (@claesjacobsson) March 21, 2016
There are a lot of lessons to be learned here, about the fine line that backend solutions need to thread between being open and turning value into profit. Between giving love to the community and clearly identifying and chasing after their paying customers.
We’re working on fixing this model, so we’re launching a beta version of Telepat’s backend service. It’s about open-source, no free tier, dedicated IaaS and great support. Just sign up, and we’ll reach out to start the conversation.