Pat Shuff's Blog

  • Iaas
    August 2, 2016

Orchestration 2.0

In this blog entry we are going to look at how to automate installations and provisioning of compute instances. There are a variety of ways of making this happen with a wide variety of tools and methodologies that you could use. The foundation of all of these tools define how to configure systems that run in the cloud or in your data center. The configuration data includes compute resources, network resources, storage resources, user definitions, packages, processes, and services. These definition languages allow you to not only define one service but a collection of services. For example, if we want to define a WordPress blog, we can define a single server that contains the WordPress blog software, the web container that runs the blog, as well as typically the MySQL database to contain state and user information for the blog server. For a multi-site blog entry you typically want to split the database from the application server and allow you to create a high availability configuration with failover of the database files and multiple web containers on the front end to handle a large number of users and web requests.

If we tried to describe this system with sentences it would be relatively complex and confusing. For example, we would like to run the web container on a single processor computer with 8 GB of memory and 20 GB of disk and have it connected to a single processor computer with 16 GB of memory and 40 GB of disk running a MySQL server. The web container should also have PHP installed and be able to answer request for http and secure http. The web container should run the WordPress package and connect to the database instance to store user and web page information. Both systems should run Oracle Linux 6.7 and be configured with all ports locked down other than web services and the ability to remotely log into the web service using a secure shell. We would also like to define what to do if the web container consumes over 80% of the processor assigned to it as well as the database instance as well as what to do if either of the services stops or fails.
There are a variety of configuration management tools available to help define what is described in the above paragraph. Most of these tools use JSON to describe the configurations and start up and scaling procedures. The three that we will touch upon in this blog are Chef, Puppet, and Orchestration.


Puppet is a public domain package produced by Puppet Labs and is available on Linux and Windows systems. More information can be found at

Puppet uses a declarative language to describe a system configuration. These files are called manifests and are typically stored in JSON format or something similar to it. With puppet resources are typically defined using the following format

  resource_type { ‘resource_title’:



present or absent,

attribute :


attribute :


attribute :



Chef is a similar configuration tool first released in 2009 by a company called Chef to describe system configurations similar to Puppet which was released five years earlier. More information on Chef can be found in the following links.

Chef uses “recipies” to describe application configurations and system configurations with a little more emphasis on the application configurations that Puppet. A typical Chef configuration consists of a set of files rather than putting everything into one json file. The typical folder structure, for example, looks like


The rb files support the Ruby programming language syntax so attributes are defined slightly differently.

  default[‘Linux’][‘version’]              = ‘6.7’
default[‘Linux’][package_name’] = ‘OEL_6_7’
default[‘Linux’][‘dir’] = ‘/home/oracle’

The rb files can also have conditional control structures that allows you to do if then else or case selection to change configurations between installations. If, for example, you configure a web container different on Windows or Linux, you can collect all of these recipes in one location and update them as needed. You can also aggregate operating system configurations in one directory and application configurations in another file or directory and create dependencies between the configuration files.

Oracle Orchestrations

Oracle uses a third configuration management tool call Orchestrations. This is more puppet like than chef like in use and definition. Oracle Orchestrations and Amazon CloudFormation templates are very similar in nature and configuration since they both use JSON as the foundation. From the orchestration documentation, an orchestration defines the attributes and interdependencies of a collection of compute, networking, and storage resources in Oracle Compute Cloud Service. You can use orchestrations to automate the provisioning and lifecycle operations of an entire virtual compute topology. A sample orchestration file would look like

attribute: value,
attribute: [ {
attribute: subvalue,
attribute: subvalue
} ]

There are not any books on Oracle Orchestration but there are a few links that can help you understand the technology and this is the second major revision of this technology. The second version is designed more towards cloud automation of systems rather than individual servers.

Amazon CloudFormation

Amazon CloudFormation uses a similar template and configuration utility. The key differences are what attributes are required and what attributes are optional. More information on CloudFormation can be found in the following links

Azure Runbooks

Microsoft Azure takes a radically different approach and uses Runbooks that require Windows PowerShell or PowerShell Workflow to define configurations and parameters for configurations. These tools are Azure specific and operate differently than they do for on premise systems. We will not look at this system during our evaluation because it is too specific to one vendor.

In summary, there are a variety of ways to create definitions of what a service is in the cloud. There is not a single tool that performs a configuration for on premise and in the cloud. You can configure tools that will do this but they typically don’t work for all cloud vendors. Each cloud vendor has their own implementation and to get a comparison of what works and does not work do a Google search for “cloud orchestration tools comparison” to get a review of public domain and commercial tools that solve this problem. These tools are all relatively new and in their infancy. There is not a single tool that dominates the market and should be adopted over the other. In later blogs we will dive into the Oracle Orchestration definition and look at how it compares for building a system like WordPress in a single server and highly available cluster on multiple servers. These same principals can be applied to building an E-Business Suite, PeopleSoft, or JD Edwards configuration based not only on IaaS but PaaS.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.