The downtime is extremely frustrating. They are pretty nonchalant about it as well, which is actually more of a concern than the fact that there was an issue.
Beyond that, there are some good use cases for apps to be built upon Parse and bad ones. It turns out that the thing I'm building is one of those bad use cases.
Parse appears to frown upon background processes. They have very tight restrictions on what can be done in the background and how fast it must be done.
If you have a social-esque app, at any kind of scale, fanning things out becomes a problem.
We're in the middle of packing up our toys and heading over to GAE.
It's an important reminder that most startups are run by a handful of people who are normal, fallible human beings. They generally don't have access to the infrastructure and manpower required to be on the ball and maintain near 100% uptime of their services. I think the important information to be gleaned about a company is how they deal with problems like this (not necessarily the fact that they encountered the problem in the first place - if that is of concern, pick a more established organisation).
Also another issue, which probably doesn't apply to Parse is limited funding. One of my own venture's certificates has now expired and as a 'bootstrapped' web app, I simply can't justify spending more to renew the certificate. However I keep the service live as a demo to potential customers, if one takes a very keen interest I will happily renew it, or seek further funding.
I'd love to hear more about why you think we're nonchalant about downtime. We definitely need to improve reliability and are working hard to do so but also spend a lot of effort on writing up detailed postmortems (e.g. http://status.parse.com/incidents/j336l474l8h4) to be as transparent as possible even if it's painful.
You're right that there are some applications that are a good fit for Parse and others that aren't. We have many social-esque apps that are doing fine so I'd love to hear more. That said, we know it's not "one size fits all" and are working to productize/integrate some Facebook technologies that should make fanning out and other things way better.
So I would recommend using Parse after the end of the year once they figure out their reliability. Infrastructure as a service that is in the process of improving reliability is not very confidence boosting, though.
But I do appreciate that yall have started posting on status.parse.com! That is a major improvement in the right direction.
You will know when it becomes a problem. The helpdesk gets flooded. Servers go down. You get white pages and 500 internal server error pages. The entire site folds because a mouse farts.
You add new servers and they get crushed. You scrutinize every line of code and fix algorithms and cache whatever is possible and you still can't keep up. You look at your full stack configuration and tune settings. You are afraid of growth because it will bring the site down. THEN you know it's time to consider switching frameworks. And even then I would try to find the core of the problem and rewrite that one piece.
Rewriting an app in a new framework can kill a company. Be leery of starting over. I personally know of one company who started over some 4+ years ago because the old app was too hard to maintain and only started rolling out the new app last year to extremely poor reception (even with about 1/2 the features of the old app). The reception was so bad that they had to stop rolling it out until it was fixed. They could have easily spent a year improving the old app and would be miles ahead.
That's not to say that all problems are due to the framework either. I've had web servers go unresponsive for 20+ minutes because apache went into the swap of death because KeepAlive was set to 15s and MaxClients was set to a value that would exceed available RAM. The quickest solution was to cycle the box. This was 10 years ago though and I think I had a total of 1GB of ram to work with.
Yes of course. 40 xhr requests to load a single page. Developers with no clue on the impact on what they are doing.
Sorry a bit pessimistic here. Just had to deal with some serious similar issues in a team.
It's funny to me. A while back there was a thread on HN about the SDK going hay-wire and taking apps down with it. I sometimes wonder how much damage (financially, technically and socially) a single "shutdown" command can cause.
Seems developers don't bother to test/handle certain failure scenario. Because this API or this server will be available until the heat death of the universe and will never fail.
Also shows FB can, at will, essentially DDOS entire apps just by causing a few failures. Quite a nice position to be in for...Leverage should we say? :P
P.S and a tip to devs:
Please test your apps to enure if a third party component dies, your entire site isn't useless without it. It's okay having "stripe" as the gateway for your entire business to make money but you're essentially putting all your eggs in their basket.
Also, if you use third party JS scripts (caching providers), test that if something isn't loaded you have a fallback (perhaps a locally served version, just do that anyway). It's amazing how a script request just doesn't work and well...Your entire site/app is now dead.
(Note: I agree w/ the OP + commenter whole-heartedly)
The other counter-example I can think of is Myspace who frequently had tons of server errors and page load errors alongside failing to iterate their product rapidly.
This appears to be well-meaning (which is to say it's not the usual tautological whinging tech hate for dynamic sites, it appears to come from a place of concern for delivering important information in a crisis). But it's also quite a lot to ask in a crisis. Stuff like this should set off alarms:
> I can’t tell you how best to get static—only you can figure that out.
Okay. Is this helping? I guarantee anyone responsible for uptime of critical services is pretty overwhelmed right now, and not going to be immediately receptive to calls to make huge, abrupt architectural changes without any guidance.
Edit: this is how it should be done[1] (HN thread[2])
I think the usual retort is that at any moment and for any inexplicable reason your entire infrastructure can be deleted for some reason you barely know let alone comprehend. This seems to be the case for apps at least.
I neither support nor deny this belief but it's an increasingly common impression.
I think it's hilarious that so many huge companies can't figure out how to run a simple, static web page that can be updated independently of the rest of their infrastructure. It's something that a kid with a Raspberry Pi and an intro to Python book could do in an hour.
Yet here we see example after example of status web pages that break when the status they're supposed to report is anything other than good.
What this indicates to me is that most websites are in a constant state of breaking and needing maintenance, such that no company wants to have even a small distraction / obligation / annoyance of keeping a site up. Has the feel of like, you inherit a free building that's constantly falling apart, might as well get rid of it, no matter how many people find it useful.
This is actually a brilliant counter-example of what not to do. :D
I can think of many services that have rapidly outgrown their ability to serve pages to the users in a seamless fashion (people regularly complain about reddit, though I don't recall encountering it myself (but then I'm only on reddit rarely), and people complain about twitter (were they the guys with the fail whale?)). And various blogging software also spits its lunch (wordpress?)
Then you have MySQL which regularly died under load. I think it's better now than it used to be.
I guess the counter-counter example is that even if your technology foundations are crappy you can still become popular if the service is compelling enough to override minor quibbles like 'stability' and 'scalability' (don't tell the architects I said that :D )
At my last job I had that conversation several times :( Our website would regularly take 30s+ for a page to load, and we had an hour of scheduled downtime each week, because that’s how long it took the webapp to restart each time code was pushed. “Scheduled downtime doesn’t count as downtime, we still have the three 9’s that meets our SLA, and there’s nothing in the SLA about page load times. Now get back to building that feature which Sales promised a client was already finished”...
Aside from being generally shameful, the real kicker was that this was a "website performance & reliability" company x__x
Looking at that status page, unless it's completely wrong, there's outages multiple times every month. They really could just upgrade their instance and get more mileage out of it and it wouldn't require any "refactoring". Site's mostly fine as is
It's mildly depressing and comforting at the same time to realize that none of the code I've written or am writing will even remotely have anything close to 'catastrophic consequences'.
At worst, the number of visitors will drop to 0 for a short while, or clients/internal users won't be able to do their job for said short while. This will quite possibly impact the bottom line of company that relies on that particular site/app/system, but any effect will be lost in the noise (and probably even underestimated, because that's how this happened in the first place!).
While it's sort of nice that there are real-world stakes to the worst-case scenario, it's also both comforting and depressing to contemplate how relatively meaningless these stakes really are, personally.
This would make life truly hellish for Web developers: your app randomly gets terminated on client machines that are temporarily sluggish. Lots of them would just give up on the Web and write apps for other platforms.
"A [Single Page App] will lock you into a framework that has the shelf life of a hamster dump"
Seems like that could be said about a lot of infrastructure services out there as well.
reply