What to consider when parsing through your Parse alternatives

At the conclusion of January, Facebook had officially shuttered Parse, disabling the API on an app by app basis.

As a Backend as a Service (BaaS) product, the development platform provided SDKs and APIs that allowed developers to quickly build their apps without having to build a backend from scratch. Facebook did’t present much insight into the motivation to shut down the platform. But Parse’s customers, following the 2013 acquisition, comprised heavily of small to medium sized developers that had a lower propensity to spend.

While Facebook was burdened with having to answer to post-IPO investor concerns about desktop growth plateauing and uncertain mobile revenue, the Parse acquisition was a quick fix, helping secure Facebook’s grasp on widespread mobile adoption.

Despite Parse being the backend backbone for 60,000+ apps at the time of the acquisition, Parse, like many low-cost BaaS solutions, had limitations for businesses and developers who wanted to scale their app. Amazon, Microsoft and Google, who acquired Firebase afterwards, all followed Facebook’s suit, but aggressively doubled down on maximizing the assets in their developer platforms, while Facebook stood pat with Parse after accomplishing what they needed to do to establish their mobile adoption.

Realizing the peak of “mBaas”

The resulting shutdown of Parse should be viewed as a wakeup call to developers that a BaaS solution alone cannot be a long-term choice for sustainable digital, mobile and progressive web businesses.

The 2016 announcement of the shutdown gave developers time to find alternative solutions to migrate their applications. While a BaaS solution facilitates a quick time to market, API-centric development, and innovation, the drawbacks have become more evident.

• Business data is more likely to be exposed on a cloud-based shared database. Customers starting to value data privacy more will be turned off by a solution that can be exposed with the vulnerabilities of a shared database.
• As a business grows, extending the backend will be difficult because of the limitations BaaS offers for individual solutions. This will become a concern if your business needs to extend the backend for its unique business logic. (i.e. linking your BaaS with your legacy IT, your web services, creating some custom back-end side algorithm for IA, data validation).
• Because of the BaaS limitations to “-asS” business logic, you would need to create your own backend somewhere else in the cloud. Following this, you would need to create a dialog with this BaaS and your backend ultimately becomes your performance killer, mainly at the network level (all the API calls in both ways you need to do: “your back-end” <-> “BaaS” must communicate many times to generate a single end-user call).
• Additionally, you would be limited to only the features available out-of-the-box. If you discover after few weeks of work a feature is missing (i.e. complex search, a missing filter, or geofencing features), you would not be able to work around it.
• Finally, your BaaS will be hindered by your dependency on the BaaS solution’s roadmap as they’ll upgrade features in time and deprecate old ones (think back to the transition from Google Maps V2 to V3). Your roadmaps need to consider these continuous upgrades as your solution will need to revolve around the roadmap of the BaaS solution.

So what now?

Apart from relying on BaaS solutions, what are the alternatives businesses can use to expedite a product development?

• Alternative 1: PHP framework
  • Benefits: It’s easy to build a team, find people, easy to host, very mature ecosystem
  • Drawbacks: It doesn’t fit with the new market expectation & UX : real-time (sockets), IoT (MQTT), scalability (in comparison with node.js, Scala, Go, python)

• Alternative 2: Node.js or Python framework
  • Benefits: This offers great capabilities as it fills in the gaps on what PHP cannot do
  • Drawbacks: It’s not easy to build a team or find people who can do this. It is not easy to host, nor is it a very mature ecosystem. This is usually very costly and is only used by Silicon Valley startups with the monetary resources to hire gurus.

• Alternative 3 : PaaS
  • Benefits: This enables teams to simplify a lot the hosting automation, scalability and all other cloud benefits
  • Drawbacks: Deep linking the API and billing system requires a heavy reliance on AWS. As it’s impossible for your business to predict, your business model will be too dependent on AWS from start to finish.

• Alternative 4 : Self-hostable back-end
  • Benefits: Allows for feasible platform-agnostic API and SDK connectivity and offers the flexibility for IT teams to scale their solution for growth.
  • Drawbacks: Small developer teams won’t immediately find need for the breadth of capabilities, but this solution is most fitting and ideal for mid-sized businesses (both enterprise and consumer facing).

As Parse had demonstrated before the acquisition and recent shutdown, BaaS solutions are great for early stage app solutions and prototypes, but aren’t ideal for applications that intend to scale.

Dependent on size and need of the business, there are four possible options that IT decision makers and developer teams can consider. This decision will be increasingly vital as many applications will need to be rewritten or formatting for upgrades (by the end of 2017) to the mobile web and platforms hosting these applications.