Getting past the “Cloud Computing” Hype
There’s a lot of talk about “Cloud Computing” right now, including from Caucho, but much of it seems vague or over-hyped. You hear more talk about benefits of scaling, redundancy, and cost savings than about actual features. We recently put out a whitepaper talking about Resin 4.0’s support for cloud that hopefully shows what we’re providing. However it is a pretty big document with quite a bit of behind the scenes technical detail, so I thought I’d break it down a bit here to give you a look at where we fit into the cloud environment. In other words, here are the actual features in Resin 4’s cloud support.
Let’s start with a basic scenario of using a cloud ISP like Amazon EC2. What they give you is the ability to run a virtual machine at a metered rate. You can run Resin on these virtual machines, then your Java or PHP application on top of Resin. You can start up as many of these nodes as you’re willing to pay for. The Resin instances running on these nodes will communicate with each other to provide the following features:
Remote Deployment throughout the cloud
Resin 4 maintains a distributed application repository to which you can publish applications remotely. Once you send your app to one of the nodes, all of the nodes will then receive the new code. Moreover, if you upgrade an application, only the changes will be sent so that you’ll get running faster and use less bandwidth. Of course you can take advantage of the versioned webapps that are already in Resin. This feature lets you upgrade your application seamlessly by running both new and old versions at the same time. Users with sessions on the old version will stay with the old version while users with no session will be directed to the new version. Thus you get simple deployment with no downtime.
Distributed Caching and Sessions
Current Resin users know that we’ve provided distributed sessions for years, but with Resin 3.x and earlier, you have to specify the complete cluster layout at configure time. Resin 4 keeps the same application-level functionality without code changes, except now you can add and remove servers at will. Along the same lines, we’ve added support for object caching with the Java Cache API. Just put an object into the cache on one node and get it out on another. It doesn’t matter if the node on which you put the object is still running when you retrieve it. It doesn’t matter if the node on which you retrieve the object was running when you put it. The cache behaves reliably regardless of whether nodes go up or down.
Smart Cloud Load Balancing
Resin’s load balancer already does sticky sessions, failover, and distribution based on load factors like number of connections and CPU load. Resin 4 extends this functionality to work with dynamically added and removed nodes. But it also adds a green load balancing mode - we try to load up nodes one at a time rather than going round-robin so that once a node is up, it handles as much as it can. Only when a node is loaded do we go to the next machine. In a traditional cluster environment, this means avoiding waking idle machines unnecessarily, saving electricity and wear. In a cloud ISP environment, it means avoiding using unnecessary nodes, saving money. Either way, it’s green. 
If you’ve been following the cloud world, you probably know what the cloud ISPs can do for you, but now you can see what your app server can do. A lot of examples of using Java on cloud with other app servers show how to start up a bunch of worker nodes that can’t talk to each other. Resin 4 allows you to start your application in the cloud as a genuinely integrated deployment.