[exelius]

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.

[nostrademons]

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

[jt2190]

While I agree completely with your comment, I wished you'd written "made architectural choices based on facts that are no longer true" instead of "is an idiot." Nobody sets out to make bad choices on purpose, and only the extremely lucky make architectural choices that survive massive growth.

(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.)

[nostrademons]

I agree, but the actual words used when this discussion comes up very often are much closer to "What idiot designed this shit?" rather than "My coworkers made architectural choices based on facts that are no longer true". (At Google the latter was perhaps more common, but I've heard the former in startups a lot more frequently, and certainly on Internet message boards.) I'm perspective-taking on the part of all sides; I hope that it's apparent from each side being called an idiot in turn and the company succeeding in the end that I don't actually believe any of the participants are idiots.

[grrowl]

Once the next round of developers join, the scrappy MVP has usually been pushed far enough to be messy and maintainability becomes an issue. Seeing that might trigger the "idiot" reaction, The old guard appreciate how far it's come.

[st3v3r]

I believe they used the right word. Not because those that did make the decisions were, in fact, idiots, far from it. It's because many times, that's the attitude of people who decide that things have to change.

[barneycarroll]

"based on facts that are no longer true" I don't think each successive wave is necessarily thinking about facts that were true but are no longer true. I think being opinionated about the tech stack you have to work with is often not all that rational. Trying to substitute concrete rational behaviour on the desires of new waves of employees might seem nice, or at least politically correct — but there is often no specific technical translation for "what idiot wrote this"; it's a cultural thing.

[docCaliban]

Wrong: "made architectural choices based on facts that are no longer true"

Less wrong: "made architectural choices based on personal preferance"

Don't be such a politically correct idiot!

[golergka]

And, personally, I think that this stack rewrite path makes a _lot_ of sense and probably should be planned from the beginning.

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.

[derefr]

Or you can be like WhatsApp, write once in Erlang, and scale to a billion users just with OS-level tweaks.

[golergka]

WhatsApp is one example, and if you're trying to imagine your own path, you should be thinking in statistics and probabilities. Imagine if the idea doesn't work out and you need to pivot. I'm not familiar with Erlang at all, but judging by the fact that (1) it was developed by a big telecom company and (2) it's priorities are stability and performance, I don't feel that it drastically changing business logic of an Erlang application is an easy task.

[derefr]

Being an Erlang developer myself: if you don't actually need the stability of a telecom (e.g. restartless upgrades that hold open circuit-based connections), pivoting around the logic of an Erlang app is about as easy as doing so in Ruby/Python/etc.

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.

[yeukhon]

Source? I am skeptical WhatsApp is a single monolithic service at this point.

[msie]

I was nodding so much to this comment. Been there, done that. Been on both sides.

[braythwayt]

I nodded so vigorously that I need a chiropractor. This perfectly describes my experience in the web industry and the client-server industry before that.

Only the particular languages and frameworks change, but the patterns remain the same.

[dev360]

By patterns you mean GoF??!

[braythwayt]

There are management and architecture patterns as well as design patterns.

[volaski]

i think what the op meant was that it didn't make sense because it's owned by facebook. Heroku being owned by Salesforce makes much more sense because that's their business models are aligned. I remember the first time I was about to try out Parse, fortunately that's around when Parse got acquired by Facebook and I decided not to take a risk. It especially didn't make sense for me because I was going to build a social app. It doesn't make sense to build a social app on a platform owned by a social app company.

[nostrademons]

I'm saying that this usually doesn't matter to the people who would be using Parse anyway, because they operate under a timeline much shorter than this. In a year, their startup will either be dead or they'll have the funding to migrate off Parse. On a timescale equal to your lifetime, it's almost a guarantee that FB will pull the plug on Parse. But on a timescale equal to the time period when you need Parse, it's actually a pretty good bet.

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.

[kopos]

Took me rushing through all those years of insane coding in the last company I worked for. By the time I had quit, a fully functional game engine had undergone 3 rewrites with 2 more underway and with one of them not seeing the day of light. All for the same reasons you elucidated and some more.

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!

[dastbe]

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.

[nostrademons]

The "2-4 official languages" dictum is usually put in place after the company churns through those 2-4 languages in the first 2-4 years of its existence. Basically everybody realizes how costly it is and says "no more". At least that's how it was at Google, which is perhaps the most famous example of the "We have 4 official languages, and you're not introducing a new one" policy.

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.

[vorg]

> Google, which is perhaps the most famous example of the "We have 4 official languages, and you're not introducing a new one" policy

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

[nostrademons]

It's technically C++, Java, Python, and Go. There's always been an exception for client-side code (which encompasses Javascript on the web and Objective-C for iOS apps), and for DSLs (which includes Sawzall, Protobufs, Bazel, Gradle, and several that I don't believe are public. Haskell was also used as a DSL by one team, though their product unfortunately got canceled).

[wh-uws]

This is frankly the best tech industry tech stack cycle explanation I've ever seen lol.

I've thought this myself but never put the words together so clearly

[return0]

Did facebook move away from PHP ? Did google radically switch stacks ?

[nostrademons]

Facebook's backend is, to my knowledge, largely C++, connected via Thrift. The frontend started out as PHP, eventually got compiled to C++ via HipHop, replaced HipHop with HHVM, and then added support for Hack. My understanding is that they're gradually adding more React to it as well. FB also includes a number of specialized services, eg. Chat & Whatsapp are written in Erlang.

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

[mintplant]

Facebook rewrote PHP and switched various components to other systems entirely. It's not like they're still running their original LAMP stack.

[walterbell]

The circle of life-cycles. Turn it into a diagram and help founders, early employees, VPs and managers to navigate these phase transitions.

[Jare]

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.

[petercooper]

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]

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]

> 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]

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]

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.

[mbesto]

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.

[x0x0]

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]

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.

[nickbauman]

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]

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.

[jonknee]

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

[dev360]

Wonder if founders knew this but were just happy to get acquired. Can't say I would blame them.

[jonknee]

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]

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

[killface]

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