Lessons from Parse

In case you missed it, Parse is shutting down in a year. For developers who had been relying upon Parse, they offer some migration assistance, to help you move to another database (MongoDB) or your own hosted trimmed-down Parse server. All things considered, while Parse’s shutdown is unexpected, they are making it fairly graceful. This is not stopping developers from panicking, though, as they try to figure out how and when to move off of the main Parse service.

There are lessons to be learned from this.

Lesson #1: Mice Need To Be Wary of Elephants

Developers have a tendency to flock to offerings from major brands. Facebook acquired Parse in 2013, which helped to raise Parse’s profile. Google has two tons of developer APIs and back-end services. Twiter has Fabric. Amazon has AWS. Microsoft has Azure. And so on.

However, these major brands do not necessarily have small development teams best interests in mind when they make their strategic decisions. Big brands will do what big brands want to do, regardless of fallout.

So, Facebook shuttering Parse is not that surprising. After all, Google is notorious for shutting down APIs. The “acqui-hire” approach, where a big brand acquires some firm mostly for access to its talent, can have similar impacts, as those firms’ services get shut down almost immediately upon acquisition.

This is not to say that you should run away screaming from any developer offering from a big brand. Just recognize that what they want and what you want are unlikely to be in alignment.

Lesson #2: Have a Disaster Recovery Plan

If your app is more or less of a hobby, the fact that Parse happens to be going away may not be a big deal. If nothing else, you can ship an update to your app shortly before Parse shuts down that “shuts down” your app, offering to help the user export their data from your app (which, in turn, you pull from Parse), before that data becomes inaccessible.

However, if your app is part of a larger initiative, whether commercial or otherwise, probably you want your app to keep working in a post-Parse world.

Those who are not using Parse may be chuckling at the worried looks coming from Parse users. However, if your app is dependent upon third-party services, you too are at risk if those services elect to shut down. Worse, not every service fails as gracefully as Parse is, and you may have no time at all to react to a service shutting its doors forever.

As developers, we need to have disaster recovery plans. Traditionally, such plans tended to be focused on the hardware that we were responsible for: developer PCs, physical services, networking hardware, etc. However, in an EIKSaaS (Everything, Including the Kitchen Sink, as a Service) world, disasters include failures in those services. Many developers will have implemented exception handling for when services are down temporarily. But what if the service is gone forever?

If you are dependent upon a service provided by somebody else, you need to have a reasonably up-to-date plan if that somebody else has “shuffled off ‘is mortal coil, run down the curtain, and joined the bleedin’ choir invisible”, as has happened to some parrots.

Lesson #3: Strive for More Options

One powerful option for EIKSaaS disaster recovery is to have a self-hosting option. Since we are concerned about where the service goes away forever, usually that self-hosting option needs to be open source, so that there is a hope of ongoing maintenance from a community.

For example, with crash logging, while some services offer slick proprietary APIs, IMHO you are better served by choosing one that supports ACRA on the client side. If your particular crash logging service “has ceased to be”, switching to another service might be as simple as pushing an update with a one-line change, providing a new endpoint URL. And, since ACRA is open source and has a specification for how it communicates with back-end servers, there are several open source options for self-hosting a logging server, should that prove to be your best option.

In this case, the issue is not the library – a proprietary crash-logging library is not necessarily inferior to ACRA. The issue is the intrinsic tie to the backend server and the level of effort for you to switch should that server starts “pining for the fjords”.

Lesson #4: Give Users Options Too

In the case of crash logging, users are largely oblivious to your issues, wrestling with services that may or may not exist in the future.

In the case of Parse, the user’s own data may be at risk, and the user probably cares about that data, at least to some degree.

For cases where you are reliant upon services that in turn directly impact users, not only do you need options, but your users really need options as well. For example, if Facebook would have shut down Parse without warning, millions of users’ data would no longer be accessible.

Offer data export options from your app, perhaps as part of a broader serious backup system. Make sure that even if your app is no longer able to help the user, that the user is not permanently screwed as a result. We as a developer community cannot afford to build a reputation where people think that they cannot count on our apps, because the work that those people put into using those apps is at risk of loss.

Parse’s impending shutdown is disappointing. However, it also serves as a great example of how depending upon third-party services carries a level of risk that many developers have ignored. Make sure that you know how you will deal with cases where services that you rely upon become permanently unavailable. It is bad enough that something you count on becomes an ex-service; you do not want to have an ex-app as a result.