The End of Parse

mBaaS and Alternatives

If you’re here you caught wind of the January 28th decision to shut the doors on Parse (a Facebook product). More than 500,000 apps have been built on Parse to date including some popular ones like Hipmunk, Dubsmash, and Weebly. The clock is ticking, and those that are reliant on this mBaaS (mobile backend as a service) have one year to move to another platform. 

It’s important to understand the history and motives so that you make the right choice for your migration.

 

Oh, and I must disclaim, I always like to start with the history so if you don’t like it, skip. :)

The History of Parse

Parse, one of the first major players in the mBaaS space, was founded in June of 2011. Very quickly after being founded, the four cofounders Tikhon Bernstam (Scribd cofounder), James Yu (second engineer at Scribd), Ilya Sukhar (formerly at Etacts), and Kevin Lacker (Gamador founder) went out to raise an angel round from some very reputable investors. Some of the investors included YC, Start Fund, Google Ventures, and Menlo Ventures.

In November of 2011, the 1.1M round was followed by a 5.5M Series A round led by Ignition Ventures to fuel rapid expansion of the platform. In April of 2013, Facebook acquired Parse for a whopping $90M!

Explaining the acquisition decision, Facebook’s Director of Product Management said:

The Facebook platform has been about being an identity mechanism with sharing. But over the course of the last six months, we’ve been thinking about how we can help applications get discovered and how they can be monetized.

In order to provide the best experience possible, developers also need to build a whole host of infrastructure. Parse is a natural fit. They’ve really just abstracted away a lot of the work necessary to get an app up and running.

The Reason Parse Shut Down

In retrospect, it seems to us that the goal was to get more mobile apps using the Facebook identity mechanism (Facebook Login). Parse made it incredibly quick and easy to integrate Facebook Login and other Facebook features into apps on their platform. The Parse platform helped them to do just that and get a much stronger foothold in mobile.

It seems very possible that Parse was acquired as a tool to get Facebook more tightly integrated into apps at a high velocity at a time when Facebook was not as popular on mobile. The economics of the business model itself were likely less of a concern than a way to cheaply acquire users and gain market share for its identity services and mobile integrations.

Even with their recent decision to open source the Parse server, they are enabling a potential wider-spread adoption of the platform with no capital requirements. It’s hard to say if this will stick, but we do believe that there is a place for sure services in the market still. It’s interesting to us how they framed this as a shutdown though as they could have positioned this in a more positive light by leading with the fact that they are open sourcing the platform.

This open sourcing of the platform will open up opportunities for new companies to offer Parse as a platform on their own environments and resell the hosted solution. There are many PaaS (platform as a service) companies hosting open source software such as companies like Pantheon, Heroku, and wpEngine.

So, mBaaS is a hoax?

Honestly, no. Here at Coplex, we work with many early-stage startups that are in search for product-market fit. PaaS in general is something we all really believe in for many of the apps we build. It drastically reduces the time to get things to market and reduces a lot of the complexity around backend system architecture. Not to mention, it’s a variable cost model which keeps things lean for early-stage startups in their search for product-market fit.

We always like tools in the toolbox that help to drive innovation and increase the speed at which digital products can get to market and iterate. For most startups it is wasteful to build your app to scale from the start as most startups will pivot significantly or die before they are truly in need of such scale.

That all being said, mBaaS (and any PaaS for that matter) has a time and a place. Apps that require more complex data structures or rely heavily on complex backend processing are likely not a good fit for mBaaS.

What do we do?

We now have until January 28, 2017 or a little less than a year (damn, it’s 2017 in a year? I’m getting old…) to figure out what to do with our apps relying on Parse as a backend. Here at Coplex, we have a good portion of our mobile apps using Parse so we have had to do the homework and weigh the options.

The Alternatives

Dump the data and do your own thing with it. Then, build a custom backend.


How

You can do this with the Parse database migration tool that lets you migrate data from your Parse app to any MongoDB database.

Pros
  • Not reliant on another company
Cons
  • You have to manage your own database instance
  • Increased maintenance costs
  • Your iOS App and Cloud code will need to be rebuilt

Host your own Parse Server.


How

Get the Parse Server, which lets you run most of the Parse API from your own Node.js server. Once you have your data in your own database, Parse Server lets you keep your application running without major changes in the client-side code. For more details, check out the migration guide.

Pros
  • Not reliant on another company
  • Seamless migration of data and cloud code
Cons
  • You have to manage your own server or instance
  • Environment setup time
  • Increased maintenance costs

Use a platform as a service (PaaS) solution to host a Parse Server.


How

Consider using Deployd, Modulus, or Heroku.

Pros
  • Seamless migration of data and cloud code
  • Fast environment setup
  • No need to maintain your own environment
Cons
  • You are still reliant on the PaaS company and their support

Use a Parse alternative.


How

There are a lot of other players in the mBaaS space, so you can switch to a different solution. VentureBeat has a good list but also consider Amazon Mobile Hub.

Pros
  • Fast environment setup
  • No need to maintain your own environment
  • No need to rebuild a custom backend
Cons
  • You are still reliant on the PaaS company and their support
  • All code and data will need to be migrated and converted
  • Your iOS App and Cloud code will need to be rebuilt to work with the new service

Do you need some help making the decision based on your specific situation?

 

Get in touch with us at Coplex

We will help you make the right decision or even assist with your migration.