Google Reader will shut down on July 1st, 2013. It is only a few weeks till then and time
to look for a replacement. The best feature of Google Reader is the sync feature. You can
use multiple devices to read your feeds and switch between all of them at will. This is
possible because of the use of a central server.
Reading the Node.js group, I found Megafilter by Callan Bryant, a web-based RSS reader
following this principle. It works great and is now deployed to our platform.
Welcome to the relaunch of our Cloudnode blog. From the beginning it has been hosted on
Posterous. After the acquisition of Posterous by Twitter, their new owners have decided to
close Posterous down on April 30th, 2013. Its time now to find a new home for our blog.
Were To Go?
Posterous suggests to move to WordPress or Squarespace.
There are also Tumbler and Blogger.
But as we had to experience ourselves, hosted blogs have big disadvantages. We wanted more
flexibility and were looking for a solution that could be hosted on multiple providers like
Amazon S3, Google App Engine, GitHub and others.
Jekyll And Octopress
While looking for a blog engine that can be hosted on several platforms, one solution showed up
several times. It seems to be best to have no engine at all, but generate static
content which can be hosted everywhere. No database is needed and the performance is top
notch. Octopress which is built on top of Jekyll is such a solution and a clever way to
create a static blog.
And here it is, our new, fast, responsive and easy to maintain blog:
Our web site cloudno.de runs as a Node.js app among all the other apps hosted on Cloudnode. Our top goal is to provide excellent performance and maximum uptime for all apps including our own.
When a Node.js application is running at Cloudnode it is started as a dedicated server process using its own port. A reverse proxy routes requests targeted at the app to its corresponding port. Thus many apps share a single proxy instance making it a critical component and a single point of failure.
We are using Nodejitsu’s node-http-proxy which normally runs stable. But some apps can give it a hard time, because they are experimental or contain resource leaks. When our monitoring detects such a situation, it takes care by restarting the proxy. Everything is fine after that, but the restart causes a short downtime for all apps which are served by that proxy. Until now…
High Availability Proxy To The Rescue
Since 33 days we are running two proxies behind a balancer, which directs traffic through the other proxy during restarts.
The admin panel shows the following statistics for the last 33 days:
proxy01 has been restarted 5 times with a combined downtime of 09:48 minutes
proxy02 has been restarted 2 times with a combined downtime of 03:53 minutes
The overall downtime is zero over the period of 33 days 22 hours.
This combination works fantastic, supports websockets, keeps away bad traffic and scales to as many proxies and servers as are needed to handle Cloudnode’s future traffic.
Our new monitoring helps you to watch the CPU and memory usage of your apps and to identify problems early. If an app is breaking the govenor limits for an extended period, if will be automatically shut down to ensure the best overall performance of all apps. In a later version we will also support switching to a higher level making your app truely elastic and only consuming as much resources as needed.
The new app management page shows each of your apps with its current resource usage values:
RAM Usage - The permanently and exclusively allocated RAM
Virtual RAM - The total size of all allocated virtual RAM
CPU Load - The load of the virtual CPU (1.0 = full load)
CPU Time - The Accumulated CPU time used since the app has been started
We are also storing these values in a Redis database to allow graphic output over a time period. (coming soon)
There has always been the “cloudnode npm install <package>” command to add packages to your hosted node.js application. These steps were manual and could easily miss a dependency.
NPM has this great feature npm install, that reads a meta file called package.json which describes all required packages and versions.
This command is now part of the git workflow. During git push operations the platform code looks for a package.json file in the main app directory and executes “npm install” on it. All dependencies are now resolved by the package manager.
This works also during updates. Whenever a new package or package version is needed by your app, just edit the package.json file and see NPM doing its magic.