John Kirby's Weblog: A diatribe about life, skiing, cycling, family, friends, Java, Technology, and other things that matter.

cloud NetBeans

In the next era of application development, building and deploying applications to the Cloud should be transparent to the developer as the current IDE paradigm with tools such as NetBeans.

There are a couple of key challenges:

• The developer's process should be familiar to what they are using today, uncomplicated, reliable.
• The model is maintained in the Cloud not the IDE. The IDE needs to be a consumer of Cloud services and not a provider.
• The services offered by the deployment container can vary – how does the IDE/developer utilize these services?
• The full development lifecycle eventually needs to be managed – a deployed app should be manageable via ops (change management process.)
  
  Today, the typical build/deploy process (in NetBeans) requires the developer to have a configured Application Server (local or remote) via the Server Wizard and then create a project with a configured server to attach (deploy) their application to.

  In the Cloud, the “actual” server instance is never known because cloud resources such as Application Server instances are created or destroyed at any time. A server instance destruction in the current NetBeans implementation would break the deployment model because there is no longer a target to deploy.

  Illustration 1 is a high level overview of how NetBeans could work in the Cloud. The illustration also incorporates some potential NetBeans functionality to integrate with Kenai.com.

Potential NetBeans Cloud Integration Breakdown

One of the major changes (under the hood) to NetBeans in the Cloud is to begin migrating some the functionality out of the IDE and into the Cloud. For example, direct communication to a server instance is no longer valid. The IP of a server instance cannot be guaranteed to be static in the Cloud. This is where the concept of a Cloud Proxy (CP) comes into play. The CP is the gateway to all services provided by the Cloud. So in the Cloud environment, a war deployment via a direct call to the server instance will be replaced with CP web services.

In flow #1, the CP will receive a deployment request and route the war to a Cloud Deployment Service (CDS). The CDS will deploy the war to the existing instance (if it exists) or to a new available instance. The change in the IDE functionality via the developer's eyeglass is nil. In the IDE, the server instance still exists, it is just being abstracted via the CP. The constant is the gateway IP, not the server instance IP.

Flow #2 demonstrates the new NetBeans integration with Kenai.com. In this scenario developers utilize Kenai's SCM capabilities as well as build management via Hudson(continuous integration system) to enable more collaborative development efforts. What is missing from this is the next step to not only perform the build, but deploy and test from a single work flow. The proposed enhancement is to extend Kenai.com (for NetBeans integration) to allow it to call the CP to deploy the build into the Cloud. This flow works well for not only release builds but for developer unit testing. Here, a developer can do incremental build/deploy/test via Kenai.com to the Cloud.

There are more details to this concept such as the modeling of cloud resources to easily manage this dynamic environment. The model can also be extended to provide not only a single server instance but an entire topology all abstracted via the Cloud but functionally accessible via the IDE. The key point/goal of this proposal is to enable Cloud development/deployment to be transparent to the developer. It should not be a huge leap but a straightforward evolution

Illustration 1: NetBeans Cloud Deployment Scenarios