Every Nodejitsu app is down
status.jit.su
status.jit.su
Check http://twitter.com/nodejitsu for updates.
Sorry for the inconveniences and thanks for your patience.
- Deployments often fail with a nonspecific 500 error. I'd say near 50% of my deploys end up failing because of this.
- Downtime occurs at random times. It's usually just a few minutes (maybe 10)
- In the past I've had problems with certain routes always returning 500 errors when loaded in groups, but not alone. This problem hasn't happened for a while.
- The admin panel is at its best only "kind of" responsive. Most of the time it's a complete mystery as to whether commands issued there ever make it out to your instance(s).
Curious what opinions HNers have on this is, though:
How important is it to have pretty downtime screens, or nothing at all? In this case it's 404-ing, which is inaccurate. Would it be better to just not respond to the HTTP request than to show this?
Also have other PaaS services like Heroku got these messages right?
An HTTP 500 would definitely be more appropriate in this case, but it seems a 400 is accurate -- it's down because it has somehow forgotten where the apps are (their Twitter stream says a problem with load balancers).
If nodejitsu was returning any 4xx errors during its downtime, that's a bug that should be fixed. In this situation, they should have returned either a 500 or a 503, and I'd probably pick 503, and leave 500 to any web apps that suffered an internal error. This way you know that it's not your app but the platform it's running on.
As always, the best place to look up the details is in the spec: http://tools.ietf.org/html/rfc2616 -- long, but quite readable.
Depending on the kind of error they're experiencing, Heroku will show a quite unhelpful and generic "Application is down" screen.
I know they're limited in what they can show back given a certain kind of error but it's real crappy to let your users or clients hung out to dry.
It's especially loathsome with clients because it's indistinguishable from you fucking up. I do wish they showed a "Oh hello we're having a spot of trouble. Please hang tight" instead. Mad points for letting you style the page to match your site.
Of course, as a service provider this would not quite be something you spend a lot of time thinking about or optimizing for.
Having been with nodejitsu for 4 months now, I can say with confidently that they provide the best support out there. 24/7 IRC support with guys that go beyond the call of duty is worth way more than $3.
Yes, jitsu deploy used to have its 500 problems, but when we reduced our package size these all went away. We've had +98% deploy success for the last 4 weeks.
Yes, they are working on enterprise solutions, and if you're paying for enterprise, nobody forced you to buy into a provider that is less than 3 months old.
Nodejitsu have teething problems, but as far as I'm concerned, I'm happy with the experience, and nobody has a gun to my head to stick with nodejitsu if I didn't want to.
"Sorry for the inconveniences, we found that our database provider (@IrisCouch) is down at the moment, we are bringing up the cloud."
I'm pretty surprised to learn that they don't run their own databases (and also that their database is CouchDB, but maybe I'm just old fashioned).
It's like every other argument in the community, how much control over ease do you want?
Not to mention "database queries can be costly do to transaction over http" => Not gonna get into this too much, but couchdb has an optimistic concurrency model, yeah?
An implementation that uses a technology ( or like iriscouch is a db as a service) is not that technology. If heroku postgresdb's go down because they configure things incorrectly is that the fault of the project? Could be, could be documentation was lacking, or it was a real footgun. It is also possible to deploy technology within a budget where failures are the expected outcome, it is also very possible to deploy technology in a manner which does not support a use case, or may not even be something the technology can support, that does not make it 'bad' or 'great', and has nothing to do with "control vs ease" or http vs a yet to be named wire protocol...
I just don't see how this is helpful, accurate, or adds to the discussion, sorry if I am jumping down your throat about it.
Let's just give them some space to improve and they will!
I think Nodejitsu is a great company! They are cheap, and awesome in support! :)
The employee page is unavailable right now. But if you look through the bios, they have a bunch of young open source hackers, but virtually zero operations experience, and virtually zero ops culture, unless you count hanging out in an IRC channel sometimes.
That said, there is also a tremendous seduction in leaving the problems to others. Nobody really wants their programming or configuration mistakes to call them up in the middle of the night.
Scaling is hard and it's why many products die when they find they can't scale. But it also keeps good devops people in high demand. So I really can't complain.
If you actually look at the open source projects listed you'll see most of them are from Nodejitsu and are used internally.
404
No application found for "adams.jit.su"
JavaScript has exceptions. It has booleans. It has integers. What more do you need to handle an error?
But I miss those colorful exceptions like javax.management.modelmbean.InvalidTargetObjectTypeException :P
a) throw an exception, which will crash your app
b) emit an error event, which will crash your app if you aren't handling it
c) include the error in the first response of the callback
Domains are a knee jerk reaction to try and remedy this, but it's a pretty gross bandaid. I doubt that Nodejitsu's specific issues here are related to this, but it's one of the main reasons that I've moved away from building things in Node.