The Beauty Of Auto Deployment On Grids

Deployment in grid environments is always a big issue. Many grid companies provide super-tooling support to make sure that a simple JAR file is distributed across all nodes. Often users have to create Maven or Ant scripts that deploy their applications onto servers that run remotely. To me this whole thing just sounds like a big headache. Developer still has to spend time to writing an application locally, then launch a build script that would deploy it remotely, and then spend enormous amount of time debugging their applications with remote debuggers to find out why the heck their app does not work the way it should when deployed within a grid infrastructure.

The latest shift in the industry is to remove the deployment step altogether. Why spend time on explicit deployment when Java provides all the necessary support to do it automatically?

For example, JavaRebel from ZeroTurnAround introduced deploy-less way to work with J2EE. They have a pretty cool implementation of Java class loading (which supports class unloading and reloading by the way) which allows you to simply change your class in IDE and immediately observe the new behavior on the application server without any deployment at all. Although not supporting some edge cases, the product does indeed provide a great productivity boost for developers.

The same "Change->Compile->Run" approach you can find in GridGain. I know that we got our grid deployment right when I hear it from our users. Our users really appreciate not having to spend any time on deployment, especially in development. When working with GridGain, you simply write your code as you would locally. Then you can start several stand-alone GridGain nodes (often on the same box), hit the Run button in your IDE and watch your code execute on the grid. There are no build scripts to run or grid nodes to restart. Whenever you change your code, again, hit the Run button and watch your new code execute while the old version is automatically undeployed.

Imagine how useful this becomes in production. You can transparently deploy new code in production without bringing down your environment at all. Lets say that you have 10 worker grid nodes constantly running in production and several master nodes constantly emitting grid jobs to the worker nodes. Now, if you want to deploy a new version of your application onto the grid, you don't need to bring down your production environment at all. You can simply stop master nodes one by one and restart them with new code in the classpath. The restarted nodes will execute the new version of code while the old ones will still work with the old code version. The remote worker nodes will happily execute old and new versions of code side by side without any problems while providing all the required class-loading isolation. Once the last master node is restarted, the old code will be automatically undeployed from all the worker nodes. All this is achieved with absolutely zero down time. We used this approach when deploying under load onto a large Amazon EC2 cloud and it worked nicely.

When using our GAR deployment, you would not even have to bring down the master nodes in the above example. Simply deploy new GAR files onto master nodes and the new code will automatically be deployed on the worker nodes. All the tasks currently running with old version of code will be allowed to complete and then the old version will be automatically undeployed.

Zero deployment is just one of the many productivity enhancements you can find in GridGain. For example, when debugging you can start multiple grid nodes within the same VM and step through the code in debugger while your job executes on the grid. When writing unit tests, you can start several grid nodes right from within your test case, simulate any scenario, and validate results.

We provide all these productivity enhancements because we are developers ourselves and have the first hand experience with all the daily pain factors developers usually run into.