8 ms·

Parse never made sense to me. I could see a service like Parse being useful, but it would need to be owned / operated by a nonprofit in order to gain any adopt

by exelius 11y ago

Parse never made sense to me. I could see a service like Parse being useful, but it would need to be owned / operated by a nonprofit in order to gain any adoption. Otherwise, it's just another proprietary platform that will get shut off or changed once Facebook (or whoever) pivots to another business model to address that market. There's certainly demand, but I think most developers are wary about putting their company's tech stack at the mercy of a profit-driven company that may abandon them. In the end though, I just don't think Parse offered enough over existing solutions like AWS and Azure. Both those ecosystems can easily scale from low-end mobile apps (like Parse was designed for) or huge enterprise apps. It also didn't help that Facebook was unable to onboard a single major IoT vendor onto Parse - IMO this was probably the reason they ended up killing it. If there was zero interest from existing players in the industry, they may have figured there's not much of a market there.

nickbauman 11y ago
So Google App Engine doesn't fit into your thinking at all here. I know of large IoT efforts going on there though. And gaming. Both of which would make sense for Parse if Facebook were serious about it.
- exelius 11y ago
  App Engine is far more mature than Parse - it's been around for nearly a decade, the API is stable, and Google's not going anywhere any time soon. App Engine adoption was also very slow to pick up, but it was a more enterprise-targeted computing solution than Parse. IMO Facebook just decided to cut their losses. Parse was very likely to end up as a low-margin enterprise business with little to no impact on Facebook from a data standpoint. Facebook doesn't really have an enterprise sales division like Google does; and standing up a new sales channel like that is very difficult if you're not sure the margin will be there.
Jare 11y ago
I disagree with most of your post, but I think your last paragraph nails it. There was lost of demand and adoption of Parse, but only by thousands of the smallest players who just wouldn't offer FB any real value. I believe FB bought Parse just in case it worked out in one of the possible spaces FB was going to play. But it didn't. Failing at IoT, as you say, was the last straw.
x0x0 11y ago
Parse made a lot of sense to me. Building a simple backend isn't much work, but operating it sucks. You get to deal with script kiddies, hackers, hard drives dying, services crapping themselves at inconvenient times of day, backups, testing backups, security updates (and what is probably more work, monitoring security updates) for the OS and web server and proxy and db and on and on. Maybe there isn't a pricing model that makes this work, but I think there's a real desire.
- jonknee 11y ago
  Parse makes sense in general, but not for Facebook. Facebook is a walled garden that makes its money selling advertising. They don't offer any other developer oriented offerings and don't seem inclined to opening their data centers up for a public cloud.
petercooper 11y ago
I think most developers are wary about putting their company's tech stack at the mercy of a profit-driven company that may abandon them. Heroku? Salesforce bought them, still going, still very heavily used.
- winslett 11y ago
  IMO: Heroku is a bad example of vendor lock in. To use Heroku, no code changes were required which would prevent it from running else where. A counter-argument to my counter-argument, Heroku limitations (i.e. 30-second HTTP request timeouts) required code changes for any and all web apps to work on Heroku. Anyhow, code that runs on Heroku can run anywhere. Parse, on the other hand, was both the code and the infrastructure. EDIT: p.s. love your newsletters!
  - seanwilson 11y ago
    > Heroku limitations (i.e. 30-second HTTP request timeouts) I see this as less of a limitation and more as Heroku forcing you to write your app in a scalable manner. Likewise with Heroku servers/dynos not coming with permanent storage and not letting you SSH into them.
- simonebrunozzi 11y ago
  Heavily? Heroku was making about 2M in annual revenues when it was bought by Salesforce, and I guess it didn't grow much since then. Also, Heroku was essentially a great funnel for AWS. Start on Heroku, as soon as your footprint grows, move to AWS to save 2/3 of the cost. Source: I worked at AWS and saw this happen over and over again.
- bdcravens 11y ago
  For most applications, you're just hosting on Heroku. You can move your application. That's not really a dependency, unlike Parse, where their SDK is deep in your application code. (Oversimplifying what you'd need to do to move, though you can keep the simple deployment story with something like Ckoud 66) It's not a perfect analogy, but Heroku is like AWS EC2, whereas Parse is like AWS Lambda.
jonknee 11y ago
Parse made no sense as part of Facebook, but would have made sense if part of AWS or even Microsoft.
- dev360 11y ago
  Wonder if founders knew this but were just happy to get acquired. Can't say I would blame them.
  - jonknee 11y ago
    Hopefully for them part of the (purportedly $85M) deal was in stock. Back when they got acquired FB was trading for ~$25 a share (compared to $112 toady). That would help ease the pain of Zuckerberg throwing away your life's work.
weinzierl 11y ago
> I could see a service like Parse being useful, > but it would need to be owned / operated by a > nonprofit in order to gain any adoption. > Otherwise, it's just another proprietary > platform that will get shut off or changed once > Facebook (or whoever) pivots to another > business model to address that market. It's not that companies that lock their business customers in wouldn't be successful. In my experience the vendor lock-in argument is always low on the list of arguments, sadly. > There's certainly demand, but I think most > developers are wary about putting their > company's tech stack at the mercy of a profit- > driven company that may abandon them. Developers, sure they know better because service migration is their work and it's boring and unrewarding. Management is a different story.
mbesto 11y ago
Parse's valuation proposition makes a ton of sense. It however, made very little sense under the Facebook banner. Just like Crashlytics/Fabric makes little sense under Twitter's banner. As a developer, I want to build my software-based business on top of a provider that is focused on making money from software developers. Facebook and Twitter make money from advertisers. Amazon (AWS specifically), Google and Microsoft explicitly have revenue incentives to make money from software businesses.
nostrademons 11y ago
It didn't make sense to me until I had a.) started a company and b.) saw the historical tech stacks of a number of companies (eg. Google, Facebook, EBay) that had hit it big. I started my career with the belief that your company has one tech stack, the chief architect chooses it when the company is founded, and that you never ever rewrite it because you're in for a world of pain if you do. I learned that basically no company that experiences hyper-growth ever does this. Instead, the founder chooses a tech stack based on whatever he knows best and will let him write a v1 quickest - whether it be Java (Google), Perl (EBay), PHP (Facebook), or Common Lisp (Reddit). The first few employees collectively say that the founder is an idiot, choose a different tech stack (usually whatever's hot right now - probably Go or Node.js at this time, Python or Rails in 2005), and rewrite the whole product. They hire an experienced VP who says that the first few employees are idiots, chooses a different tech stack (often the tried and true enterprise favorites of C++ or Java), and dictates that everyone rewrite the product. Eventually, managers with more recent experience in that language get hired, who collectively say that that VP was an idiot, and the real way to do C++/Java is with Guice, Boost, C++11, etc, and rewrite the product that way. Development grinds to a halt, and the company buys a bunch of hot startups who wrote in whatever language they were familiar with, who are technical idiots but managed to build a product that everyone likes. In this context, Parse and other BaaS providers makes a lot of sense. You can get your v1 product out there really quick, get customer feedback, improve it, take VC, and hire lots of programmers to call you an idiot and rewrite your product into something saner. Then you get bought, everybody at the new company thinks you're an idiot, but you have at least cashed out. Or you don't get bought and hire a VP who'll force you to rewrite your product, but at this stage you have so much of a market lead that it doesn't matter, and the BaaS got you to the point where you have the resources to free yourself of it. (I wonder if I'll end up tripping some HN flamewar auto-detector with the number of times I've said "idiot" in this post...)
- dastbe 11y ago
  your second paragraph would be incredibly unfortunate. most of the sane large companies i've worked at or know people who work at have settled on 2-4 languages -one of which is usually the legacy starting language-which they provide tier-1 support through dedicated teams providing "the stack" in various forms. everything else is community owned and caveat emptor. its why startups should be able to use whatever language they use a selling point; a huge company churning through languages du jour sounds like an awful experience.
killface 11y ago
Which is why, when a project presented itself that had this need, we ended up using Apache UserGrid.

by exelius 11y ago

nickbauman 11y ago

So Google App Engine doesn't fit into your thinking at all here. I know of large IoT efforts going on there though. And gaming. Both of which would make sense for Parse if Facebook were serious about it.

exelius 11y ago
App Engine is far more mature than Parse - it's been around for nearly a decade, the API is stable, and Google's not going anywhere any time soon. App Engine adoption was also very slow to pick up, but it was a more enterprise-targeted computing solution than Parse. IMO Facebook just decided to cut their losses. Parse was very likely to end up as a low-margin enterprise business with little to no impact on Facebook from a data standpoint. Facebook doesn't really have an enterprise sales division like Google does; and standing up a new sales channel like that is very difficult if you're not sure the margin will be there.

Jare 11y ago

I disagree with most of your post, but I think your last paragraph nails it. There was lost of demand and adoption of Parse, but only by thousands of the smallest players who just wouldn't offer FB any real value. I believe FB bought Parse just in case it worked out in one of the possible spaces FB was going to play. But it didn't. Failing at IoT, as you say, was the last straw.

x0x0 11y ago

Parse made a lot of sense to me. Building a simple backend isn't much work, but operating it sucks. You get to deal with script kiddies, hackers, hard drives dying, services crapping themselves at inconvenient times of day, backups, testing backups, security updates (and what is probably more work, monitoring security updates) for the OS and web server and proxy and db and on and on. Maybe there isn't a pricing model that makes this work, but I think there's a real desire.

jonknee 11y ago
Parse makes sense in general, but not for Facebook. Facebook is a walled garden that makes its money selling advertising. They don't offer any other developer oriented offerings and don't seem inclined to opening their data centers up for a public cloud.

petercooper 11y ago

I think most developers are wary about putting their company's tech stack at the mercy of a profit-driven company that may abandon them. Heroku? Salesforce bought them, still going, still very heavily used.

winslett 11y ago
IMO: Heroku is a bad example of vendor lock in. To use Heroku, no code changes were required which would prevent it from running else where. A counter-argument to my counter-argument, Heroku limitations (i.e. 30-second HTTP request timeouts) required code changes for any and all web apps to work on Heroku. Anyhow, code that runs on Heroku can run anywhere. Parse, on the other hand, was both the code and the infrastructure. EDIT: p.s. love your newsletters!
- seanwilson 11y ago
  > Heroku limitations (i.e. 30-second HTTP request timeouts) I see this as less of a limitation and more as Heroku forcing you to write your app in a scalable manner. Likewise with Heroku servers/dynos not coming with permanent storage and not letting you SSH into them.
simonebrunozzi 11y ago
Heavily? Heroku was making about 2M in annual revenues when it was bought by Salesforce, and I guess it didn't grow much since then. Also, Heroku was essentially a great funnel for AWS. Start on Heroku, as soon as your footprint grows, move to AWS to save 2/3 of the cost. Source: I worked at AWS and saw this happen over and over again.
bdcravens 11y ago
For most applications, you're just hosting on Heroku. You can move your application. That's not really a dependency, unlike Parse, where their SDK is deep in your application code. (Oversimplifying what you'd need to do to move, though you can keep the simple deployment story with something like Ckoud 66) It's not a perfect analogy, but Heroku is like AWS EC2, whereas Parse is like AWS Lambda.

jonknee 11y ago

Parse made no sense as part of Facebook, but would have made sense if part of AWS or even Microsoft.

dev360 11y ago
Wonder if founders knew this but were just happy to get acquired. Can't say I would blame them.
- jonknee 11y ago
  Hopefully for them part of the (purportedly $85M) deal was in stock. Back when they got acquired FB was trading for ~$25 a share (compared to $112 toady). That would help ease the pain of Zuckerberg throwing away your life's work.

weinzierl 11y ago

> I could see a service like Parse being useful, > but it would need to be owned / operated by a > nonprofit in order to gain any adoption. > Otherwise, it's just another proprietary > platform that will get shut off or changed once > Facebook (or whoever) pivots to another > business model to address that market. It's not that companies that lock their business customers in wouldn't be successful. In my experience the vendor lock-in argument is always low on the list of arguments, sadly. > There's certainly demand, but I think most > developers are wary about putting their > company's tech stack at the mercy of a profit- > driven company that may abandon them. Developers, sure they know better because service migration is their work and it's boring and unrewarding. Management is a different story.

mbesto 11y ago

Parse's valuation proposition makes a ton of sense. It however, made very little sense under the Facebook banner. Just like Crashlytics/Fabric makes little sense under Twitter's banner. As a developer, I want to build my software-based business on top of a provider that is focused on making money from software developers. Facebook and Twitter make money from advertisers. Amazon (AWS specifically), Google and Microsoft explicitly have revenue incentives to make money from software businesses.

nostrademons 11y ago

It didn't make sense to me until I had a.) started a company and b.) saw the historical tech stacks of a number of companies (eg. Google, Facebook, EBay) that had hit it big. I started my career with the belief that your company has one tech stack, the chief architect chooses it when the company is founded, and that you never ever rewrite it because you're in for a world of pain if you do. I learned that basically no company that experiences hyper-growth ever does this. Instead, the founder chooses a tech stack based on whatever he knows best and will let him write a v1 quickest - whether it be Java (Google), Perl (EBay), PHP (Facebook), or Common Lisp (Reddit). The first few employees collectively say that the founder is an idiot, choose a different tech stack (usually whatever's hot right now - probably Go or Node.js at this time, Python or Rails in 2005), and rewrite the whole product. They hire an experienced VP who says that the first few employees are idiots, chooses a different tech stack (often the tried and true enterprise favorites of C++ or Java), and dictates that everyone rewrite the product. Eventually, managers with more recent experience in that language get hired, who collectively say that that VP was an idiot, and the real way to do C++/Java is with Guice, Boost, C++11, etc, and rewrite the product that way. Development grinds to a halt, and the company buys a bunch of hot startups who wrote in whatever language they were familiar with, who are technical idiots but managed to build a product that everyone likes. In this context, Parse and other BaaS providers makes a lot of sense. You can get your v1 product out there really quick, get customer feedback, improve it, take VC, and hire lots of programmers to call you an idiot and rewrite your product into something saner. Then you get bought, everybody at the new company thinks you're an idiot, but you have at least cashed out. Or you don't get bought and hire a VP who'll force you to rewrite your product, but at this stage you have so much of a market lead that it doesn't matter, and the BaaS got you to the point where you have the resources to free yourself of it. (I wonder if I'll end up tripping some HN flamewar auto-detector with the number of times I've said "idiot" in this post...)

dastbe 11y ago
your second paragraph would be incredibly unfortunate. most of the sane large companies i've worked at or know people who work at have settled on 2-4 languages -one of which is usually the legacy starting language-which they provide tier-1 support through dedicated teams providing "the stack" in various forms. everything else is community owned and caveat emptor. its why startups should be able to use whatever language they use a selling point; a huge company churning through languages du jour sounds like an awful experience.

killface 11y ago

Which is why, when a project presented itself that had this need, we ended up using Apache UserGrid.