Clustered hosting cloud infrastructure

The Challenge

Easy deployment to hosting environments and out of the box scalability are required to make Grails even more attractive. Currently there is a solution for Cloud Foundry, but there is no turnkey solution for Heroku at this point. There are other cloud hosting provides out there and will be more in the future. In addition, clustering in general on a company's own existing server farm (non-cloud, or home-spun cloud) is also not catered for out of the box.

The areas of functionality that the CloudFoundry plugin covers provide a starting point:

1. Provision of libraries and scripts specific to the hosting solution (Cloud Foundry), for deploying, scaling etc.
2. Wiring of deployed environment resources into the beans and plugins of the Grails app
3. Configuring key plugins to work with clustering

Proposal

This is a proposal for a 2-tier system.

A "grails-hosted" plugin would provide base services covering items (2) and (3) above. Individual hosting environment plugins would leverage this and provide the information need for the base functionality to work, and any other tools required i.e. scripts for managing CloudFoundry or for generating a heroku stack/deployment.

The current CloudFoundry approach takes on responsibilities that it arguably should not - it is configuring quartz, hibernate, mongo for example. Plugins should be responsible for this themselves.

Grails needs to have a concept of a hosting environment and clustering. i.e. at the very least grails.clustered = true in Config and/or BuildConfig will be used to indicate that plugins need to configure for clustered scalability.

The grails-hosted framework plugin

This framework would be responsible for:

• Executing something like a buildForHostingEnvironment event on xxxxGrailsPlugin.groovy classes, if declared. This gives Quartz, Hibernate and any other plugin the hooks they need to do any build-time configuration based on the target hosting environment: def buildForHostingEnvironment = { clustered, buildConfiguration -> ... }
• Executing something like a runForHostingEnvironment event on xxxxGrailsPlugin.groovy classes, if declared. This gives Quartz, Hibernate and any other plugin the hooks they need to do any run-time configuration based on the target hosting environment: def runForHostingEnvironment = { clustered, config -> ... }

This mechanism would give plugins the tools they need to self-configure for clustering.

Use Case: CloudFoundry or Heroku plugins would read values from ENV or System properties and push these into some standard config/other beans that plugins like Mail pick up. e.g: grails.host.* will store these values such as grails.host.smtp.host

This provides the config abstraction needed between the plugin that needs to configure itself and the hosting platform. The grails-hosted plugin knows nothing at all about Quartz, Mail, Hibernate etc. The plugins themselves know nothing about the specific hosting environment. They just know to look for information under grails.host.* - the values that can exist there will be defined as part of the grails-hosted spec.

The CloudFoundry / Heroku / other plugins

These would depend on the grails-hosted plugin, and would use the buildForHostingEnvironment and runForHostingEnvironment events, along with doWithWebDescriptor, doWithSpring etc to:

a. get the app built with any tweaks to the deployment descriptor / create extra deployment files needed etc b. get the grails.host.* values populated at runtime based on the ENV or System property conventions that the host uses so that the other plugins can pick this all up.