Cloud bursting. [kloud burst-ing] verb, is the action when an application suddenly reaches internal performance limits and is extended or moved to a public cloud environment.
Cloud bursting is a powerful concept for modern businesses running their apps in hybrid cloud environments. By completely automating this process companies can save money and improve their SLAs at the same time. Cost savings are realized because infrastructure can be more fully used, allowing IT departments to carry a more conservative number of servers in-house, while still having a strategy in place where the application can be expanded or full-on moved to a external public cloud like Amazon’s EC2 during times of peak performance. Automation also saves time and reduces the opportunity for human error in migrating these important applications.
Today’s video is the first in a series on this topic where David Winterfeldt, the VMware lead engineer for Application Director 5.0, will demonstrate how Application Director is used to first create and deploy an app on a corporate network. Then, a few environment variables are changed, and he is able to redeploy the app on to Amazon’s EC2. Here are the six steps covered in the video:
1. Creating the Blueprint for the Corporate Network
Within Application Director, an application blueprint is used to define the app. In this case, a logical template of Centos 32-bit is used along with a logical network. A logical template can be mapped to an actual template in the cloud catalog. Logical templates allow an application blueprint to remain cloud agnostic. The vFabric tc Server service is grabbed from a catalog, and the WAR file is dragged-n-dropped on the blueprint where several properties are “auto-connected.” A few properties and values (e.g. context) are set manually to finalize the blueprint.
2. Defining the Deployment Profile for the Corporate Network
A “dev” deployment profile is defined. The profile is a collection of deployment settings for a blueprint, including cluster size, CPU, memory, cloud templates, and networks.. In this case, the logical template used is mapped to a vCloud Director cloud template within a corporate network. The network settings can be configured for the different tiers of application based on the cloud provider selected in the deployment profile. Deployment profile properties can be set to over-ride the blueprint—memory, CPU, hostname, tc Server services, and WAR file properties—can all be changed. We will see this when preparing the EC2 deployment.
3. Deploying the App on the Corporate Network with an Execution Plan
The execution plan shows details around the order in which virtual machines are created and action scripts for catalog components are installed, configured, started, and updated. A dashboard with four panels is included in the execution plan. The task details panel shows properties of the deployment itself. The blueprint is referenced as a visual in another panel. In a third panel, the VM details are also shown with information about status as it provisions, and the app execution plan steps and status are shown in a fourth panel. From this dashboard, you can also see the IP address being resolved, the scripts running, the properties used, and quickly get to logs for debugging. The final step in this deployment is logging in to test the app on the corporate network.
4. Deploying the Same Blueprint in Amazon EC2
The application blueprint is cloud agnostic, and as a result, there is nothing to change on the blueprint. This means that once an application architect creates a blueprint, it can be deployed on any of the supported cloud providers without any changes to the blueprint itself. A different deployment profile however will need to be created in order to deploy this application on Amazon EC2.
5. Updating the Deployment Profile for Amazon EC2
This step is where the majority of changes happen to deploy the application on Amazon EC2. Within the deployment profile, we choose an EC2 profile instead of vCloud. A large chunk of the process of mapping the logical templates used in the application blueprint to existing cloud templates was done when the EC2 profile was originally set-up. For reference, there are two prior articles that explain how our logical models deals with cross-cloud complexity and why model-driven deployments (with workflow) are better than workflow driven deployments alone.We do make some changes to the profile here by altering a global value for proxies that are not needed in Amazon’s cloud. Additionally, we change the installation artifact location variables for tc Server and the WAR file to point to Amazon’s S3 storage for performance reasons. It’s worth noting the security model here—Application Director speaks to Amazon via a cloud tunneling system—this is a secure channel between EC2 (i.e. a public cloud) and the private corporate network where Application Director is running. The tunnel is used to proxy both Application Director and RabbitMQ. With RabbitMQ messaging available via this channel, we can now have triggering events on either side pass via the tunnel—a powerful feature for hybrid cloud scenarios.
6. Deploying the App on Amazon EC2 with an Execution Plan
The deployment plan is specific to a deployment and can also be altered at different points of the process. For example, a script can be added after any step to send an email, make a REST call, etc. This becomes powerful for hybrid cloud scenarios. In the demo, the deployment button is pressed again, and the same dashboards are used to see the IP resolve, the VM provisioned, tc Server installed and running, and the WAR installed. Then we log in to test the app on the EC2 cloud.
The Video: Auto-Deployment on Amazon EC2 AND vCloud
| >> David will be speaking this Wednesday, January 30 in NYC for Java SIG – Deploying Spring Apps to Amazon EC2 and VMware vCloud. Click here to register. |
Learning more about vFabric Application Director:
- Learn How Apps will be Deployed in the Future on services like vFabric Application Director
- Learn what “Cross Platform Cloud Application” means
- Learn about Model-Driven and Workflow-Driven Apps
- Read how VMWare IT is managing Policies with Provisioned Apps to Save Money
- Download a free trial and learn more about vFabric Application Director
