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.