7 ms·

Why did Facebook decide to shut down Parse?

190 points by sashthebash 11y ago

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.
gkoberger 11y ago
Yeah, it sucks Parse shut down. But that's not an argument to avoid SaaS. My startup is built on over 20+ different third-party tools. It will really, really suck if any of them shut down... but I'd rather deal with that possibility in the future when we have more money and time, than struggle to build everything out ourselves now. Like I said, it sucks Parse is shutting down. But in ~2 hours, you can get the open source Parse clone they released going and be back to new. Seems better to deal with that now than to have slowed down initial development by building everything in-house.
- Jare 11y ago
  > in ~2 hours, you can get the open source Parse clone they released going and be back to new I keep hearing this, and I have a hard time believing it. Are there any examples of a significant app/developer doing this? Sure a working Parse Server is easy to get up and running, but the reason someone wouold choose Parse was to avoid operations, and that's not a service you build in your company in 2 hrs. (as an aside, it looks to me like the Parse Server is a very limited subset of the real Parse)
  - lacker 11y ago
    If you have a small app and don't need to be careful about scaling issues, then 2 hours is pretty accurate I think. It's trickier when you have a large app, because with Parse Server you do need to handle your own databases and production environment. So I think some of the larger apps are either going to need to hire some devops folks, or make an arrangement with higher-service providers like ObjectRocket. It has been less than a week, though, so we will see.
  - arihant 11y ago
    Parse Server uses Mongo, there are plenty of operations-free Mongo hosting options, like Compose. Also, Parse server code itself could be given to company such as Heroku or AWS beanstalk to host it for you.
  - semerda 11y ago
    If someone wrapped it as a microservice with containers and a deployment script for AWS then yes. Otherwise the configuration alone would take few hours. This then begs the question; was/is AWS or Google a better backend to rely on long term.
mayyuen318 11y ago
Interesting thought. In fact when I looked at the market of mBaaS, it is interesting that most major competitors after Parse target the Entreprise market, that echo with your 2nd checkbox.
draw_down 11y ago
> Large mobile app developers such as mobile gaming companies mostly shunned its service, building in house custom solutions instead. Small to medium sized developers embraced its service, but had a much smaller propensity to spend. As a developer, I want the platform I choose to rely on to be reliable and unlikely to shut down. I also don't want to spend a lot of money on it. Hmm. Hmmmmmm.
mattiemass 11y ago
I was hoping for an insider leak...
- dang 11y ago
  We replaced the misleading and linkbait title with a representative sentence from the article. Submitters: the HN guidelines ask you not to use the original title of a post when it is misleading or linkbait. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
th0ma5 11y ago
How is Slack not also a house of cards like Parse?
- zrail 11y ago
  Slack changes a decent amount of money for access to their platform.
- anthonybsd 11y ago
  Slack is gaining a lot of momentum in the enterprise space as a collaboration platform. Considering that they are basically a supercharged IRC, I'd say that's pretty nifty. I don't see them shutting down any time soon.
- tomatohs 11y ago
  Slack is (or should not be) mission critical. If Slack shuts down, you can still communicate with your team through email, SMS, or any other alternative. Your product will remain in operation even if Slack dies.
  - yelnatz 11y ago
    Slack is not mission critical, you mean.
    - dev360 11y ago
      Oh noes, slack is down we can't deploy :(
- deleted 11y ago
  [deleted]
wpeterson 11y ago
Outsourcing functionality or work makes a lot of sense for things that aren't core to your business. If you're building a web or mobile app, backend services should be core to your business. It's a very different thing to write a web application or web services that can run on many hosting platforms than to give responsibility for your entire backend to a service provider.
gaius 11y ago
This "article" is just an ad, once you reach the last paragraph.
- bduerst 11y ago
  Pretty much. It's fitting in with the trend of execs writing about buzzwords to make the topics relevant to their startup offering.
deadlycrayon 11y ago
Interesting insights until you realize that the author has a not so hidden agenda for posting such an article.
derFunk 11y ago
>Can you trust your platform of choice, or will they close shop on you tomorrow? I'm thinking about moving to IBM BlueMix with parts of my business and asking myself the same question. What do you guys think? Will BlueMix still be there in a couple of years (3,4)? I know nobody using it, but IBM is promoting it quite aggressively, and it makes sense for me to have an alternative for both self-made AWS clusters (IaaS) AND BaaS like Parse.
- iofj 11y ago
  It will be around, for sure. But it will also be so expensive it might as well not be.
- patwolf 11y ago
  I've been using BlueMix off and on since it was still Beta. I have noticed that a lot of things, particularly in the BaaS space, have changed significantly. While I'm sure BlueMix will be around, I doubt you'll make it 3 or 4 years without having to modify your code to accommodate changes to the platform.
xaduha 11y ago
There's also http://www.28.io http://www.28.io (totally ungooglable name, btw. Also know as "28msec"). http://www.28.io/documentation/latest/data-sources/ http://www.28.io/documentation/latest/data-sources/ Not really comparable to Parse, even though they call it "Virtual Databases". Sure, you can query everything, but what about updates? EDIT: Looks like they have updates, but I couldn't find whether they support similar uniform interface to updates as they have for queries (ideally XQuery Update Facility). http://www.28.io/documentation/latest/modules/connectors http://www.28.io/documentation/latest/modules/connectors
kwhinnery 11y ago
I don't think Parse's lead in this space ever evaporated. They went out as the best-in-class MBaaS.
- lacker 11y ago
  I agree with this! ;-)
jakejake 11y ago
Sometimes I really feel like I'm falling behind the times because I don't use a lot of third party services or platforms for my company's apps. I feel like I stick with simple tools at the expense of not getting any "good stuff" for free. When something like this shutdown occurs though it makes me glad that I can just spin up a plain old server or two and put together whatever services that I need. I can't tell if I'm a dinosaur or a maverick!
tsunamifury 11y ago
Click-bait speculation. Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going. The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly.
- yeukhon 11y ago
  "Word in the industry" from which industry? From what source? The tone of your messages is pretty scary. Instagram still run partly on AWS, not sure about the rest like the actual backends. > Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly. That's the last thing a startup should worry about. Growth and branding are far more important. Most acquisitions ended up with most of the original team departing from the new company a year or two after the acquisitions, or move on to another production. Your product will be dismantled and re-engineered in house.
- up_and_up 11y ago
  > after two failed attempts to move from AWS to Facebooks metal failed spectacularly Seems more like a problem with FB onboarding them and their tech. With some of the smartest people in the world they can't solve problems like this? > Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly. Makes no sense. Startups should focus on product and users. Scaling on AWS is somewhat of a no brainer giving more time for what's important: product and users. This seems more like an outlier situation in which FB really didnt care.
- beachstartup 11y ago
  uhm, i don't know about that conclusion. what you're describing is a basic failed migration. it happens all the time. all the smart people left, and migrations are hard. very hard. you have to know how the internet actually works, and most people don't have the foggiest fuckin' clue about how anything really works, especially in today's advanced abstraction-driven world. they should have written it into the vesting contract, probably will in the future.
d0m 11y ago
I still see a big market for a more powerful Parse. I think the whole "infrastructure as a service" is now commodity and wouldn't be a good competitive advantage, but the software orchestrating all the sys admin stuff on top of any IoT would be of tremendous value. The perfect solution would connect all the great open-source building blocks into one "Good Enough Way". I would totally pay for that, but I don't see how that service would stop copycats. In a way, this is what Meteor is trying to get to. Embrace open-source but deal and charge for the hard parts that nobody else is solving. Ideally, there would be a generalized way to build scalable applications. Similarly to how mostly everyone got behind React, it would be great to have mostly everyone behind such a project. I'm sure it will happen, but I'm not sure when it will. Right now there are hundreds of new libraries in the JS ecosystem, but there are some clear converging trends. I think new languages and libraries will always exist and be welcome, but it'd be great to have one standard way based on years of experience. Similar to how other industries stabilized (i.e. building bridge). I feel we'll be able to move so much faster when we get to that point. Now, every programmer is reinventing the wheel and keep doing the same mistakes that other programmers elsewhere are doing.
wahsd 11y ago
Does anyone know if there is a list of the 60,000 apps that relied on Parse? I'm just curious.
- campers 11y ago
  Google this: site:parseapp.com Thanks for the idea, might have to contact some of them about my Parse replacement platform!
dang 11y ago
For what it's worth (and because someone said they were "hoping for an insider leak"), here's what a genuine insider had to say about this article: Just awful. followed by: I would write something but it would be so simplistic that nobody would believe it. Sorry it's anonymous, but it's the best I could squeeze out of them :)
- danso 11y ago
  They can't just leave us hanging like that.
conductr 11y ago
They bought parse at a time when Facebook was struggling to do mobile right. Parse had the talent. That was my initial thought when the acquisition went down.
kindlep 11y ago
Wow, talk about another ad disguised as an article. Damn South Park was right!

190 points by sashthebash 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.

gkoberger 11y ago

Yeah, it sucks Parse shut down. But that's not an argument to avoid SaaS. My startup is built on over 20+ different third-party tools. It will really, really suck if any of them shut down... but I'd rather deal with that possibility in the future when we have more money and time, than struggle to build everything out ourselves now. Like I said, it sucks Parse is shutting down. But in ~2 hours, you can get the open source Parse clone they released going and be back to new. Seems better to deal with that now than to have slowed down initial development by building everything in-house.

Jare 11y ago
> in ~2 hours, you can get the open source Parse clone they released going and be back to new I keep hearing this, and I have a hard time believing it. Are there any examples of a significant app/developer doing this? Sure a working Parse Server is easy to get up and running, but the reason someone wouold choose Parse was to avoid operations, and that's not a service you build in your company in 2 hrs. (as an aside, it looks to me like the Parse Server is a very limited subset of the real Parse)
- lacker 11y ago
  If you have a small app and don't need to be careful about scaling issues, then 2 hours is pretty accurate I think. It's trickier when you have a large app, because with Parse Server you do need to handle your own databases and production environment. So I think some of the larger apps are either going to need to hire some devops folks, or make an arrangement with higher-service providers like ObjectRocket. It has been less than a week, though, so we will see.
- arihant 11y ago
  Parse Server uses Mongo, there are plenty of operations-free Mongo hosting options, like Compose. Also, Parse server code itself could be given to company such as Heroku or AWS beanstalk to host it for you.
- semerda 11y ago
  If someone wrapped it as a microservice with containers and a deployment script for AWS then yes. Otherwise the configuration alone would take few hours. This then begs the question; was/is AWS or Google a better backend to rely on long term.

mayyuen318 11y ago

Interesting thought. In fact when I looked at the market of mBaaS, it is interesting that most major competitors after Parse target the Entreprise market, that echo with your 2nd checkbox.

draw_down 11y ago

> Large mobile app developers such as mobile gaming companies mostly shunned its service, building in house custom solutions instead. Small to medium sized developers embraced its service, but had a much smaller propensity to spend. As a developer, I want the platform I choose to rely on to be reliable and unlikely to shut down. I also don't want to spend a lot of money on it. Hmm. Hmmmmmm.

mattiemass 11y ago

I was hoping for an insider leak...

dang 11y ago
We replaced the misleading and linkbait title with a representative sentence from the article. Submitters: the HN guidelines ask you not to use the original title of a post when it is misleading or linkbait. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

th0ma5 11y ago

How is Slack not also a house of cards like Parse?

zrail 11y ago
Slack changes a decent amount of money for access to their platform.
anthonybsd 11y ago
Slack is gaining a lot of momentum in the enterprise space as a collaboration platform. Considering that they are basically a supercharged IRC, I'd say that's pretty nifty. I don't see them shutting down any time soon.
tomatohs 11y ago
Slack is (or should not be) mission critical. If Slack shuts down, you can still communicate with your team through email, SMS, or any other alternative. Your product will remain in operation even if Slack dies.
- yelnatz 11y ago
  Slack is not mission critical, you mean.
  - dev360 11y ago
    Oh noes, slack is down we can't deploy :(
deleted 11y ago
[deleted]

wpeterson 11y ago

Outsourcing functionality or work makes a lot of sense for things that aren't core to your business. If you're building a web or mobile app, backend services should be core to your business. It's a very different thing to write a web application or web services that can run on many hosting platforms than to give responsibility for your entire backend to a service provider.

gaius 11y ago

This "article" is just an ad, once you reach the last paragraph.

bduerst 11y ago
Pretty much. It's fitting in with the trend of execs writing about buzzwords to make the topics relevant to their startup offering.

deadlycrayon 11y ago

Interesting insights until you realize that the author has a not so hidden agenda for posting such an article.

derFunk 11y ago

>Can you trust your platform of choice, or will they close shop on you tomorrow? I'm thinking about moving to IBM BlueMix with parts of my business and asking myself the same question. What do you guys think? Will BlueMix still be there in a couple of years (3,4)? I know nobody using it, but IBM is promoting it quite aggressively, and it makes sense for me to have an alternative for both self-made AWS clusters (IaaS) AND BaaS like Parse.

iofj 11y ago
It will be around, for sure. But it will also be so expensive it might as well not be.
patwolf 11y ago
I've been using BlueMix off and on since it was still Beta. I have noticed that a lot of things, particularly in the BaaS space, have changed significantly. While I'm sure BlueMix will be around, I doubt you'll make it 3 or 4 years without having to modify your code to accommodate changes to the platform.

xaduha 11y ago

There's also http://www.28.io http://www.28.io (totally ungooglable name, btw. Also know as "28msec"). http://www.28.io/documentation/latest/data-sources/ http://www.28.io/documentation/latest/data-sources/ Not really comparable to Parse, even though they call it "Virtual Databases". Sure, you can query everything, but what about updates? EDIT: Looks like they have updates, but I couldn't find whether they support similar uniform interface to updates as they have for queries (ideally XQuery Update Facility). http://www.28.io/documentation/latest/modules/connectors http://www.28.io/documentation/latest/modules/connectors

kwhinnery 11y ago

I don't think Parse's lead in this space ever evaporated. They went out as the best-in-class MBaaS.

lacker 11y ago
I agree with this! ;-)

jakejake 11y ago

Sometimes I really feel like I'm falling behind the times because I don't use a lot of third party services or platforms for my company's apps. I feel like I stick with simple tools at the expense of not getting any "good stuff" for free. When something like this shutdown occurs though it makes me glad that I can just spin up a plain old server or two and put together whatever services that I need. I can't tell if I'm a dinosaur or a maverick!

tsunamifury 11y ago

Click-bait speculation. Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going. The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly.

yeukhon 11y ago
"Word in the industry" from which industry? From what source? The tone of your messages is pretty scary. Instagram still run partly on AWS, not sure about the rest like the actual backends. > Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly. That's the last thing a startup should worry about. Growth and branding are far more important. Most acquisitions ended up with most of the original team departing from the new company a year or two after the acquisitions, or move on to another production. Your product will be dismantled and re-engineered in house.
up_and_up 11y ago
> after two failed attempts to move from AWS to Facebooks metal failed spectacularly Seems more like a problem with FB onboarding them and their tech. With some of the smartest people in the world they can't solve problems like this? > Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly. Makes no sense. Startups should focus on product and users. Scaling on AWS is somewhat of a no brainer giving more time for what's important: product and users. This seems more like an outlier situation in which FB really didnt care.
beachstartup 11y ago
uhm, i don't know about that conclusion. what you're describing is a basic failed migration. it happens all the time. all the smart people left, and migrations are hard. very hard. you have to know how the internet actually works, and most people don't have the foggiest fuckin' clue about how anything really works, especially in today's advanced abstraction-driven world. they should have written it into the vesting contract, probably will in the future.

d0m 11y ago

I still see a big market for a more powerful Parse. I think the whole "infrastructure as a service" is now commodity and wouldn't be a good competitive advantage, but the software orchestrating all the sys admin stuff on top of any IoT would be of tremendous value. The perfect solution would connect all the great open-source building blocks into one "Good Enough Way". I would totally pay for that, but I don't see how that service would stop copycats. In a way, this is what Meteor is trying to get to. Embrace open-source but deal and charge for the hard parts that nobody else is solving. Ideally, there would be a generalized way to build scalable applications. Similarly to how mostly everyone got behind React, it would be great to have mostly everyone behind such a project. I'm sure it will happen, but I'm not sure when it will. Right now there are hundreds of new libraries in the JS ecosystem, but there are some clear converging trends. I think new languages and libraries will always exist and be welcome, but it'd be great to have one standard way based on years of experience. Similar to how other industries stabilized (i.e. building bridge). I feel we'll be able to move so much faster when we get to that point. Now, every programmer is reinventing the wheel and keep doing the same mistakes that other programmers elsewhere are doing.

wahsd 11y ago

Does anyone know if there is a list of the 60,000 apps that relied on Parse? I'm just curious.

campers 11y ago
Google this: site:parseapp.com Thanks for the idea, might have to contact some of them about my Parse replacement platform!

dang 11y ago

For what it's worth (and because someone said they were "hoping for an insider leak"), here's what a genuine insider had to say about this article: Just awful. followed by: I would write something but it would be so simplistic that nobody would believe it. Sorry it's anonymous, but it's the best I could squeeze out of them :)

danso 11y ago
They can't just leave us hanging like that.

conductr 11y ago

They bought parse at a time when Facebook was struggling to do mobile right. Parse had the talent. That was my initial thought when the acquisition went down.

kindlep 11y ago

Wow, talk about another ad disguised as an article. Damn South Park was right!