New Features in the Latest Cloud Foundry
We recently updated CloudFoundry.com. With this update, we introduced several exciting new features that pave the way for future development. I want to take this opportunity to describe and explain these features, as well as provide some background in how they came about. We are excited for you to try them out and provide us with feedback.
Cost Tracking
While the pay-per-use model of the cloud can reduce expenditure, it is important to track the actual usage and costs so that it does not result in an unexpected hefty bill. Previously, Cloud Foundry informed the users of their current spending rate of their deployments. This is useful for understanding the meter rate, but it does not give a clear understanding or statistics on how much an application deployment actually costs. The latest update to Cloud Foundry presents a new historical feature to cost tracking. For running deployments, Cloud Foundry displays the cost so far. For deployments that are no longer active, the total cost of running that deployment over its lifetime is shown.
Availability Zone
Many users have requested the ability to specify the availability zone for deployments due to the fact that reserved instances in EC2 need to be launched in specified availability zones. Reserved instances are pre-paid and cost about a third of on-demand instances. Cloud Foundry now offers the ability specifiy the availability zone and the selection input is positioned below the region when configuring deployments.
Maintenance Page
If you need to disable your Java web application for maintenance, the convention is to display a bumper page (a.k.a. maintenance page) informing your user of the unavailability. Cloud Foundry now provides this capability with just a single button. First, when you add or edit an application, you will notice a new field: Maintenance Page. This is the static page (from the application’s root context) that you would like to display when in maintenance mode. Once deployed, you can switch between maintenance and normal operations by going to the Deployment Details page and clicking “Begin Maintenance” to display the maintenance page; and click “End Maintenance” to revert back to serving the application normally. This is a small step towards providing full application lifecycle management support. We introduced the integration with developer tools last month, and we will be analyzing and figuring out the various lifecycle phases/stages that should be supported in the development and deployment of applications into the cloud.Clone Deployment
There are numerous reasons for duplicating environments with the same configuration, and now Cloud Foundry provides a simple way of cloning a deployment with the Clone button on the deployment details page. Creating a duplicate deployment based on an existing deployment is particularly useful when used in conjunction with the maintenance feature to upgrade an application. The Clone button is enabled when your deployment utilizes an EBS volume. You will be prompted to give the clone a name and all the configuration will be duplicated and launched in a new deployment. Once the cloned deployment is launched, you can deploy a different version of the application or a completely different application altogether by clicking on the Redeploy button in the Applications section.
- Upload a tested application to Cloud Foundry
- Enable the maintenance page on the current deployment
- Clone the deployment
- Run a SQL script to migrate the database schema
- Redeploy with the newer version of the application
- Reconfigure the elastic IP so that the new deployment is served from the static IP address
- Stop the old deployment
Additional Metrics and Charts
In this latest release of Cloud Foundry beta, we have improved the monitoring capability by extending the number of metrics collected, as well as adding user-interface features. First of all, Hyperic SIGAR filesystem metrics have been added to provide monitoring of crucial disk usage information on the VM root disks and the database storage. These metrics are now visible in the areas of instance details. Next, the number of client requests has been added as a metric. Cloud Foundry collects this data and converts it to a rate based metric per minute, giving you a measure of usage of your application. This metric appears in the improved deployment details section as a chart with a listing of aggregate values (maximum, minimum, and average).
The user can inspect the jobs that are known to the system. Jobs are either launchable or non-launchable (in the screenshot they are all launchable). The distinction is that a launchable job is defined and configured in the application itself, whereas a non-launchable job is detected as state left by the execution of a job in another process. (Spring Batch uses a relational database to track the state of jobs and steps, so historic executions can be queried to show the non-launchable jobs.)
Launchable jobs can be launched from the user interface with job parameters provided as name value pairs, or by an incrementer configured into the application.
Once a job is executing, or has executed, this view can be used to see the most recent executions, and a brief summary of their status (STARTED, COMPLETED, FAILED, etc.).
Each individual execution has a more detailed view (shown above), and from there the user can click down to a view of each of the step executions in the job (only one in this case). A common reason for wanting to do this is to see the cause of a failure.
The top of the step execution detail view shows the history of the execution of this step across all job executions. This is useful for getting a statistical feel for performance characteristics. A developer running a job in an integration test environment might use the statistics here to compare different parameterisations of a job, to see what effect is of changing (for instance) the commit interval in an item processing step.
The bottom of the step execution view has the detailed meta-data for the step (status, read count, write count, commit count, etc.) as well as an extract of the stack trace from any exception that caused a failure of the step (as in the example shown above).
A job that is executing can be stopped by the user (whether or not it is launchable). The stop signal is sent via the database and once detected by Spring Batch in whatever process is running the job, the job is stopped (status moves from STOPPING to STOPPED) and no further processing takes place.
