3 ms·

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

by tferris 14y ago

> 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: http://www.tulek.org/2011/03/08/installing-node-on-aws-linux-ami/ http://www.tulek.org/2011/03/08/installing-node-on-aws-linux... (just one example showing how easy it is) 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)?

rpwilcox 14y ago
> ... 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.
- tferris 14y ago
  Good post! 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.
  - rpwilcox 14y ago
    > 7. Just install and use Git?? I made that point generic for a reason. :) 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.

by tferris 14y ago

rpwilcox 14y ago

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

tferris 14y ago
Good post! 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.
- rpwilcox 14y ago
  > 7. Just install and use Git?? I made that point generic for a reason. :) 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.