>Let’s not beat about the bush here. As a rule, Node JS’s target audience probably doesn’t know enough to safely and securely run their own Internet-connected servers. It isn’t their skillset. A customer using Node JS really needs someone to look after all of that for them.
This remark kind of surprised me. Perhaps it's out of ignorance but I feel like I can safely setup and maintain my own web servers without much hassle. Don't you still need to be security-wise if you need to build anything other than the most simple of websites?
Wow, this is one uninformed review of node.js. So the threshold for acceptability of a technology is hosting solutions and a community meetup? Come on.
> Node JS’s target audience probably doesn’t know enough to safely and securely run their own Internet-connected servers.
First, the presumption about the "target audience" for node.js is garbage. This is basic ignorance of the community at-large. This same comment could be made in the context of any technology set, if you presume the target audience.
But to answer the question: where is the ecosystem? It's all around -- repositories like Github, commercial providers like Joyent, contributors like Nodejitsu, hosting providers like Windows Azure, and yes -- there are meetups as well.
Charlie Robbins (CEO and Co-Founder of Nodejitsu) here. I think your thoughts are really poignant. I’d like to make clear that public availability is the absolute top-priority for us over here but we chose to make a couple of choices that other Public Cloud PaaS companies did not. These choices enable us to offer the truly best-of-breed hosting opportunity for Node.js developers:
1. Early on we recognized that we would not exist as a company if the node.js community was not successful. That is why we have built and maintain over 200 open-source modules on npm.
2. Infrastructure agnostic (that’s right, you get to choose where your servers live).
3. Multiple platforms (currently Ubuntu and SmartOS).
4. 100% node.js up and down the stack. This is all we do and I think we do it better than anyone else. We also have provisioning, monitoring, and configuration management tools similar to our jitsu CLI for enterprises.
5. Commitment to immediate support: If you have a problem, you have a problem now, not tomorrow, not 3-days from now. As such, we want to make sure we grew our support team to support increased on-boarding and support requests resulting from public availability.
6. Private cloud support: this is currently where most of our customers reside. We license them software that they run in their datacenter or self-managed IaaS account.
So rest assured we ramping up for a public release. Feel free to email me at charlie [at] nodejitsu [d0t] com if you’d like to talk more.
you might want to check out this awesome podcast by very serious node contributors/programmers: http://nodeup.com They often talk about upcoming conferences, meetups and other interesting stuff like good modules, good ways to do things, etc.
Node is not Rails though. It's pretty low-level and really ins't targeted to the same people imo.
> With all the buzz and hype around Node JS, it seems reasonable to think that there’d be plenty of cloud providers out there offering Node JS hosting services.
Node hosting is not your grandpa's Rails hosting anymore— deploying Node is much easier. If you want to be really quick and deploy to the cloud, take AWS and you are done in 13 steps:
Maybe the simplicity is the reason that there's just no business modell for one-click-hosters because it's too easy. The added value putting some wrapper around AWS is too small to establish a dedicated business.
And BTW: check Rails automated hosting providers like Heroku: there're just a very few and Rails is there for 7-8 years now! There're just EngineYard, Brightbox, Heroku and maybe two more. And you definitely need automated hosting with Rails like Heroku or you die. Or check Java hosting, I don't know any one-click-hoster for Java and the JVM. If you want the classic PHP and LAMP stack hosting where you put files via FTP on a web server you are not the right target audience for Node.
> Where Are The Community Meet-ups?
Node.js meetups are often integrated in local JS meetups; with conferences it's similar—a JSconf heavily covers Node as well.
> As a rule, Node JS’s target audience probably doesn’t know enough to safely and securely run their own Internet-connected servers.
Sorry, but this is a stuck-in-the-mud view on hosting web apps. With Node borders between web server and app server blurred. Node devs have to know more about deploying and hosting when they code in Node because it's integral to Node (Node is more low level than other stuff). A dedicated sys admin or an automated environment like Heroku is nice but you won't die without one and AWS for example IS already managed hosting and that's all you need. And if you would have your personal sys admin—what should he do? Look that you created the http server one liner in Node right or that he knows how to scale your Node app by modeling how nodes and childs interact with each other? No that's exactly the Node dev's jobs, that makes Node so special. If you face heavy traffic it makes sense to dedicate one engineer just to hosting and scaling but until then AWS or Nodejitsu is your friend.
Server vulnerabilities usually come with complex standard deployments like LAMP stacks, Wordpress installations etc. The less you have on the server the safer it will be. The OS stack comes from you hosting provider like AWS, is managed and is safe and the rest (Node) is so simple and little that you get it managed yourself.
> We’re just outside London, which is a veritable hive of startup activity these days.
London, a hive of startup activity?
> I’ve recently built a product in Node JS, and it was a very positive experience
If you really liked it and if you agree that there's is a lively ecosystem for Node (just check all the 9,000 modules, this is also the ecosystem) why don't you just help/contribute/improve Node's ecosystem instead of ranting (or kind of)?
> ... deploying Node is much easier. If you want to be really quick and deploy to the cloud, take AWS and you are done in 13 steps:
Those 13 steps were about compiling node, not about serving node.
Serving node is more complex. The real steps in hosting node:
1. Step up node environment. (explained in the "13 steps blog entry")
2. Make sure your node app handles exceptions and doesn't just die when something goes wrong (aka: "don't use the built-in one line http start server line")
3. Install monit/munin/god/upstart/whatever-else to restart your node servers if they die
4. Set up cluster or node.js's built-in new cluster API
5. Set up a load balancer, just in case you have performance issues in your app and you end up doing bigger work than you think you do, or have more traffic than you planned for
6. Set up database, potentially worrying about scaling issues there
7. Deployment and version rollback system, and dealing with the servers when you deploy code (need to restart them?).
8. DDOS defense.
I can see why you would want an automated PaaS to take care of all these things for you.
I see two target markets for node.js:
1. "Hey, you know Javascript, now you can write server side code too!"
2. "Hey, server side guy, hate how hard it is to do async programming in Ruby/Python (because the majority of the libraries are synchronous?) Javascript can be used on the server and doesn't have that synchronous baggage!"
The second target market certainly knows about all these 8 things I listed, but the first might want/need a managed host.
Ad 2.: Ok, that's right but rather a general prerequisite, so I would remove it from the list.
Ad 3.: Yes, this is recommended.
4. and 5. are good steps but optional and should be done in later stages otherwise it's typical premature optimization
6. Optional you could use hosted solution like MongoHQ
7. Just install and use Git??
8. DDOS defense? There's no standard recipe
> I can see why you would want an automated PaaS to take care of all these things for you.
I agree with you that automated hosting is nice but somehow the bizmodel doesn't seem to appeal. But again, compare this to the Rails world: How many automated hosters do you see there? Not many more.
So you git push to your remote, now you (may) have to tell the servers to reload. Along with other things (database migrations if you're using SQL, compiling native code if you have any of that, potentially updating configuration files if your app needs that, updating assets on a CDN/cache etc).
Yes, sure, a post-receive hook can be wired to do these things, but you have to know that and do the wiring.
Great link, which (oddly enough, because I don't think this was your intention) backs up the OP's point.
Out of that list of a dozen managed providers, 3 are officially out of beta. One, no.de, the OP talks about. One, Heroku, is listed an using an ancient version of Node.js. The other one looks like an interesting platform.
There are certainly a near infinite number of unmanaged providers, but the OP stipulated (potentially rightly?) that he really prefers a managed solution. Can't say I blame him - having all the infrastructure take care of for you lets you concentrate on code.
This remark kind of surprised me. Perhaps it's out of ignorance but I feel like I can safely setup and maintain my own web servers without much hassle. Don't you still need to be security-wise if you need to build anything other than the most simple of websites?