Why did Facebook decide to shut down Parse?(medium.com) |
Why did Facebook decide to shut down Parse?(medium.com) |
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.
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...)
(I believe Etsy had a policy of rewrites needing to support current needs multiplied by five. This acknowledges that there's a reasonable trade off between current needs and future-proofing.)
The business requirements to the architecture — not functionality! — change over time. At first, you have to be lean as hell and try a lot of different stuff. Then, you need to scale, and performance becomes an issue. Some time afterwards, you want to add more features to increase monetization and retention, and here you start needing good, abstracted out architecture for all this stuff not to interfere with each other. And finally, you find the sweet spot, and start to really care about bug-free experience, maintainability and reliability.
And all these different business priorities are best suited by different languages, different design approaches, different architectures and people with different personality traits.
While it was not 'idiots' that was the reason, the later developers always had just enough more data on the assumptions to be made for the current revision. But then again, not enough to foresee the need for a fresh rewrite when things changed again in the future. Sometimes, the rewrite was essential, sometimes it was just on a subjective whim to build a silver bullet once and for all!
I've thought this myself but never put the words together so clearly
Heroku? Salesforce bought them, still going, still very heavily used.
Parse, on the other hand, was both the code and the infrastructure.
EDIT: p.s. love your newsletters!
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.
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.
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.
> 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.
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.
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!
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.
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.
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.
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.
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 :)
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.
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).
Submitters: the HN guidelines ask you not to use the original title of a post when it is misleading or linkbait.
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.
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.
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.
Actually it is, at least the kind of SaaS / PaaS that locks you into proprietary APIs / tools. Speaking of which, Parse never made sense to me. I mean, you can quickly assemble the needed functionality from open-source libraries, deployed on AWS or Heroku, without the never ending issues, limitations or the lock-in of something like Parse.
You do need the know-how and that might take time if you don't have it, but on the other hand that technical know-how becomes your secret sauce.
Somebody wise once told me that the best product managers and project cofounders are highly-technical people, preferably former engineers. The reason is because imagination is limited by what you know is possible, which is the reason most non-technical folks aren't capable of proposing good solutions to their problems.
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)
It has been less than a week, though, so we will see.
If you had tried out Parse right when they got acquired by FB, chances are you would either have a fundable business that can hire engineers to move to your own infrastructure, or you would know that your business idea doesn't work. Either way, you no longer need Parse.
Similarly, the shutdown mostly affects "zombie" businesses - the ones that aren't dead, but aren't growing either - because in a year, you should be able to figure out whether or not your business concept has legs.
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.
Google as written by Larry Page was done in Java. It was rewritten in Python by Scott Hassan before the company was incorporated. As of 1999, the webserver and crawler were still in Python. It was almost completely rewritten (multiple times) in C++ shortly thereafter for efficiency. Most of the Google Apps (GMail, Docs, Plus, etc.) are written in Java. The webserver for Search shifted over to a combination of Java and two different DSLs in 2010; I worked on the implementation of this. My comment is lightly paraphrased from a remark Larry Page gave when asked why Google doesn't adopt more modern programming frameworks like Rails or Node (it was in 2011, when both of these were still state-of-the-art).
Less wrong: "made architectural choices based on personal preferance"
Don't be such a politically correct idiot!
Only the particular languages and frameworks change, but the patterns remain the same.
Though, that being said, I'd actually recommend Elixir, which gives you the same Erlang-ecosystem benefits, but with the key advantage of being 5x easier to convince the average Ruby/Python developer to use.
I've worked in startups that tried to implement the "1-2 languages only" (usually Java and Jython/JRuby/Groovy) policy as a startup, and they didn't go anywhere. That team of prima donnas who is willing to mortgage the startup's future in order to ship an awesome product seems to be a necessary feature of startup success, and only successful startups get to hire the team of professionals who will button down everything, choose "official" languages, and build tier-1 infrastructure. So yes, it's incredibly unfortunate, but this is the industry we live in. Pick which role you wish to occupy accordingly.
I believe those 4 languages were Java, C++, Javascript, and Python. Nowadays they also use Go, Dart, Groovy (in Android Studio), and I guess a lot more. (When I say Groovy, I mean the tiny non-Turing Complete subset of the syntax used as a DSL in typical Gradle build scripts.)