Why Facebook Really Shut Down Parse (medium.com)

New submitter isisilik writes: For those working in the 'aaS' business the Parse shutdown was the main topic of conversation this weekend. So why did Facebook decide to shut down their developer platform? The author claims that Facebook never wanted to host apps to begin with, they just wanted developers to use Facebook login. And he builds up a good case.

Comments

"Shut" down?

[NotInHere]

They haven't shut Parse down, they have shuttered it down.

Re:Huh?

[Travis Mansbridge]

"as a Service"

Re:What the fuck

[Travis Mansbridge]

"as a Service." Now, if someone could explain what "Facebook Login" is...

Re:Huh?

[Anonymous Coward]

No, but a lot of people care about aSS. (rumor has it, the Internets are full of pictures...)

Re:What the fuck

[Anonymous Coward]

Smart-ass snarky comments add little to the thread. GP post is intended to highlight the fact that the summary is deficient by dint of failing to include basic info that really belongs in the summary, and might not be know to a significant proportion of readers. Such as WTF is "aaS", or Parse, for that matter. Yes, you can follow the links, or Google it, to get said info; in fact generally on Slashdot, you've already read about it two days ago on another site. But that doesn't obviate the fact that the summary doesn't do its job.

FTFY

[Anonymous Coward]

The author claims that Facebook never wanted to host apps to begin with, they just wanted developers to use Facebook login. And he builds up a good case.

The author tries to oversimplify a complex subject by reducing it to childish terms, using phrases such as "they never really wanted apps" and "this was their plan all along", treating a multi-billion-dollar company as if it was an individual yet again, and failing to understand that the priorities and focus of such a company might validly shift over long periods of internet time. And he builds a good case for readers who have similar cognitive biases.

Re:FTFY

[HiThere]

While you are technically correct, people who are not invested in a company won't follow the details of internal politics...in fact those are usually hidden even from those that do, so as a short-cut technique for figuring out how much to trust a company you attend to its externally visible actions. This does require that you treat the company as an entity, and ignore the details about who decided what...but that's usually secret anyway.

So yes, this is an invalid way to think about a company. It is, however, a useful tool. And if corporations can be ruled to be legally persons, it seems improper to castigate someone using that same shortcut in a non-detrimental to citizens way.

The one lesson developers should learn

[Anonymous Coward]

Is that they need to do actual programming, not just glue together scripts from a grab-bag of cloud services and hope they never change or shut down. Of course, you need actual programmers for this, not hipster script-kiddies.

Re:The one lesson developers should learn

[tylersoze]

Really dude? It's more of the fact it was an easy to use service that wrapped a nice API around a solved problem. I'm a mobile app developer I just want an easy to use standard REST/CRED database backend I can connect my app to save my data. I don't want to program a back end for a solved problem. The only issue with Parse was it was developed, hosted and run by another party. Obviously the best approach would be to host the service on your own servers, Facebook is thankfully making the code available to do that. As long as you're not writing even single bit of code yourself you're always going to be depending on some else, whether it be for the language, the server, the database, the OS, etc and have to hope they keep supporting whatever stack you decided on it. It's just a matter of where you draw the line.

Re:The one lesson developers should learn

[Anrego]

Indeed, it's pretty hard to develop software without depending on _something_. The stuff I work on is quite far removed from the web, but we depend on a whole pile of third party libraries and tools. Best you can do is abstract 3rd party stuff within the realm of practicality and accept occasionally having to migrate to something else as a cost of business.

Re:The one lesson developers should learn

[phantomfive]

The only issue with Parse was it was developed, hosted and run by another party.

That's actually a really big issue.
I would hope that people would remember this in the future, but I don't have much hope since there have been many publicly documented failures of the 'cloud,' and people still think it's a good idea to depend on other people's servers.

Re:The one lesson developers should learn

[rockmuelle]

There's nothing wrong with depending on 3rd party tools and products. The problem is that most of the REST APIs that people are more and more dependent on are services, not traditional libraries.

If a library vendor goes out of business, I still have the last copy of the library and possibly even the source code. My product can continue to function until I find a suitable replacement. This is an acceptable cost of doing business, especially since commonly used libraries rarely just disappear.

If a service API goes down, my product is essentially bricked until I find and implement a replacement. This is one of those risks that most modern (er, young) developers don't appreciate. We haven't had a bust yet that shuts down a number of services over a relatively short period of time (hint: if you're using the service for free/at-a-cost-less-than-power-consumption or if it's not the vendor's core business, such as Parse, there's a good chance it will go away at some point). When that happens, the successful apps that relied on less successful services will be in a tough spot.

It'd be fun to do an analysis of the various API services people use and their interdependencies. I bet we'd find a few really scary single points of failure...

-Chris

Re:The one lesson developers should learn

[roman_mir]

There is nothing wrong to "depend on other people's servers" as long as you have a contract, an SLA in place. To depend on other people's servers is perfectly fine as long as there is an understanding on both sides what that means exactly.

To depend on the servers of people who don't owe you anything and to who you don't owe anything either, that's a different story.

Re:The one lesson developers should learn

[DuckDodgers]

People like you and me want to own the whole stack from top to bottom for reasons of long term security of our business model.

But people willing to ride the tidal wave and risk getting the floor yanked out from underneath them (to mix metaphors) build Candy Crush and Words with Friends and so forth.

Re:The one lesson developers should learn

[mlw4428]

It's more about acceptable risk in non-critical applications. If you're relying on someone else's service chances are that what you're doing isn't that critical. After all, if you can read Facebook's data, so can other people. The competitive advantage then transforms into not WHAT you have, but HOW you present it or HOW you handle the data. If you're using someone else's data that anyone else, ostensibly, has access to then your application isn't really critical to anyone anywhere. So you can feel free to code within a higher risk acceptability metric.

Re:The one lesson developers should learn

[mike.mondy]

[ Depending on a service offering (especially a dirt cheap one) is a risk ]

Which is why you should use layers of abstraction.

In this example, it would be sensible to support at least two services for back-end data storage. If you want a minimal footprint, you don't even have to ship your mobile app with multiple back-ends enabled (nor the config options to choose a back-end). You'd still be in a position to more quickly provide an update if the service disappears or looks like it's about to.

Re:The one lesson developers should learn

[luis_a_espinal]

There's nothing wrong with depending on 3rd party tools and products. The problem is that most of the REST APIs that people are more and more dependent on are services, not traditional libraries.

If a library vendor goes out of business, I still have the last copy of the library and possibly even the source code. My product can continue to function until I find a suitable replacement. This is an acceptable cost of doing business, especially since commonly used libraries rarely just disappear.

If a service API goes down, my product is essentially bricked until I find and implement a replacement. This is one of those risks that most modern (er, young) developers don't appreciate. We haven't had a bust yet that shuts down a number of services over a relatively short period of time (hint: if you're using the service for free/at-a-cost-less-than-power-consumption or if it's not the vendor's core business, such as Parse, there's a good chance it will go away at some point). When that happens, the successful apps that relied on less successful services will be in a tough spot.

It'd be fun to do an analysis of the various API services people use and their interdependencies. I bet we'd find a few really scary single points of failure...

-Chris

That is an inherent, unavoidable risk when doing distributed computing.

Re:The one lesson developers should learn

[luis_a_espinal]

People like you and me want to own the whole stack from top to bottom for reasons of long term security of our business model. But people willing to ride the tidal wave and risk getting the floor yanked out from underneath them (to mix metaphors) build Candy Crush and Words with Friends and so forth.

That is a function of your security requirements as well as cash flow. Everyone wants to own the full stack, but economics makes it hard (and in many cases, just impossible.)

And just because there are applications that have more lax requirements than yours (assuming you actually operate on requirements and not on personal technological biases), that does not mean these applications are of the "Candy Crush" type.

Re:The one lesson developers should learn

[luis_a_espinal]

The only issue with Parse was it was developed, hosted and run by another party.

That's actually a really big issue. I would hope that people would remember this in the future, but I don't have much hope since there have been many publicly documented failures of the 'cloud,' and people still think it's a good idea to depend on other people's servers.

Only if you do not have an enforceable SLA. And if you are big enough, chances are your systems are running in whole or in part in an external data center... with an SLA.

I mean, if you have a non-trivial presence, chances are you depend on Akamai CDN for performance and DoS protection, Google or Akamai analytics for, well, analytics. So right there, you have a set of vital functional requirements being performed on someone else's infrastructure, the failure of which can cause terrible financial harm to your organization.

This shit is not black and white dude.

Re:The one lesson developers should learn

[phantomfive]

True, true.

But if you don't have the ability to migrate quickly from Akamai, you're still screwed. Maybe not today, but someday. So don't depend on them too much.

Re:The one lesson developers should learn

[HiThere]

Contracts aren't necessarily worth any more than the paper they are written on. What are your enforcement powers? How expensive is it to enforce the contract? Do you trust the party that wrote the contract to honestly tell you what it means? (Do they even know?) Etc.

Once you make yourself dependent on someone else, you are dependent on them. A contract *MAY* give you the tools to damage them somewhat if they disregard it, but that won't give you back your lost time and effort. It may well not even pay your attorney's fees.

Re:What the fuck

[denis-The-menace]

Using Facebook as a login screen.

IOW: No FB account ==> no access.

FB: The future of DRM for websites.

Re:What the fuck

[PPH]

A better headline would have been: Facebook blows aaS!

Re:What the fuck

[SeaFox]

Plenty of sites have gone down that route and wondered where their users have gone. Previously active forums/comments in local newspapers sites have turned into tumble-weed factories.

Meh, newspapers really don't want comments to start with. Too much spam/crackpots commenting on a site they know will get mainstream traffic.
My own hometown's newspaper shut down anonymous commenting because they were getting comments on crime stories from people who knew a little too much and the police started bothering them wanting IP information or some other way to track down those users.

Wrong Lesson

[luis_a_espinal]

Is that they need to do actual programming, not just glue together scripts from a grab-bag of cloud services and hope they never change or shut down. Of course, you need actual programmers for this, not hipster script-kiddies.

You are oversimplifying. Though it is true that the developer's world is infected by script kiddies, there is a legitimate place for integration-centric glue code. Parse, or something like it would fit that bill. More precisely, if one has a sufficiently good back-end made available as a service, then why not leverage it?

Obviously there are issues in such an approach, but so is with everything. Engineering is about trade-offs - cost, security, availability, etc. I can roll my own back-end, but then I could run into logistic and accounting issues. Where do I host it? How much will it cost me? How much of a window do I have to maintain it?

If, OTH, there is/was a backend-as-a-service option that is sufficiently good for my current needs (and I'm not claiming Parse was), and I do not have existing technical/business/legal needs to roll up my own, then it makes engineering sense to use it.

And one of the reasons (not the primary, but an important one) to use such a backend-as-a-service is if it provides a coherent, simple and robust gluing API that I can script-kid (thus freeing me to deal with more important technical or business issues.) Again, I don't claim Parse is/was all that. I'm simply making an observation to one of your statements.

Re:What the fuck

[jmcvetta]

Meh, newspapers really don't want comments to start with. Too much spam/crackpots commenting on a site they know will get mainstream traffic.

Damn straight, that shit is dangerous. Under no circumstances must we let the opinions of the plebs be heard in public. Gods forbid!