It turns out that it’s pretty difficult to tap into cloud’s promise of elasticity and agility. Some companies like Netflix and Amazon have it figured out, so you know it’s possible. And tools like Amazon’s Elastic Beanstalk, Azure’s Auto-scaling Application Block, Rightscale, etc. make auto-scaling virtual machines (VMs) easier. However, these auto-scaling tools only work for VMs that all come from the same image and apply the same configurations.

In truth most users of cloud are still a long ways off from realising the cloud nirvana of on-demand, auto-scaling, and cloud-bursting, all related to business service level agreements (SLAs).

For example, how does auto-scaling translate to multi-tier applications? Consider a typical three-tier application composed of a web, application, and database tier. The relationships across the overall deployment matter. It is not enough to scale one tier, but to scale the bottleneck at each time. For example, if the bottleneck requires spins off both an application tier instance and a database tier instance, then it is important to consider the relationships when adding those two instances.

Or how about that dynamic cloud-bursting use case? There are dependencies among the servers and the sites. For example, the database server in site 2 cannot be started until the database server is alive in site 1, in order to avoid the problem of data inconsistency. Or, when starting the virtual machine for the web server, its cache server needs to be working properly before the server instance can be initiated.

To handle this complexity, much of today’s “cloud-bursting” often consists of setting up capability much ahead of a planned promotion or a predicted event like Cyber Monday. This is because the traditional approach to deploying multi-tier application is time-consuming.

The administrator may rely on documentation to manually install and configure the servers. Or leverage scripts to automate the process. Advanced scripting management tools such as Chef and Puppet help alleviate the burden of managing scripts. However, the administrator still needs to write the scripts and configure the tools to bring new instances and a new site to life.

The provisioning process must be made much easier before considering automatic scaling and dynamic cloud-bursting use cases. Enter the role of the application blueprint which is a template that decouples the application configuration from the instantiation.

The administrator who deploys the application does not need to work with installation or configuration scripts, or to memorise the dependencies between components. Simply put, it is easier to do and minimises the chances of messing up!

The blueprint specifies the architecture of an application and includes all the components such as, the application server, the database server, as well as the operating systems. Each component is a logical building block, i.e., it contains installation and configuration scripts that are compatible with a Windows or Linux system.

Therefore, the blueprint is decoupled from any specific environment until the blueprint is deployed at which time the configurations occur. The blueprint automates the application deployment when provisioning a new application, scaling up an application, moving the application among different environments, and optimising resource allocation.

Consider the following examples:

Blueprint Captures Expert Knowledge
: An expert creates a vanilla version of the blueprint with the essential components of a multi-tiered application. Since the blueprint is not configured for a specific environment, it serves a reference from which others can customise to extend its functionality. This vanilla blueprint can be used as a building block to create a more complicated application.

Blueprint Automates Provisioning: Assume the current site is saturated; we need to start a new site. With the application blueprint, we can easily deploy the application to a new site. On top of that, we are capable of not only scaling up the whole application, but also the individual components.

Blueprint Helps in Change Management: With the blueprint, change management is easier as updates are propagated to the deployment.

With the blueprint, administrators do not have to repeat the installation and configuration for a multi-tier application. As the deployment is accelerated and automated, we can now focus more on the business agility and how to make the application elastic at the minimum cost. We can leave the setup of underlying configuration to the experts and begin deploying applications in a more of a Platform-as-a-Service (PaaS) model.

Posted by Teresa Tung, Senior Manager, Accenture Technology Labs and Qian Zhu Researcher, Accenture Technology Labs