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

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: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.

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

[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

[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

[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:What the fuck

[PPH]

A better headline would have been: Facebook blows aaS!