For most of the history of IT, building an application was done in a "box-based" model. In this model, components are linked into a machine image, and the image is hosted on a static server in a data center. The cloud, with its goal of resource flexibility and agility, demands a more dynamic association among app components and their resources. Cloud orchestration is the way that's achieved -- but only if planned and implemented correctly.
- Deploying application components, including software components and database components; and
- Creating network connections to allow for intercomponent communication and connections to users and other apps.
While this definition applies well to all of the various orchestration options and tools, there are sharp differences in approach.
Integration works as simple orchestration for hybrid cloud apps
The simplest orchestration type is integration, which makes connections between cloud-deployed components and fixed applications and resources. For some hybrid cloud applications, cloud component integration with the data center may be the only orchestration process needed.
There are a number of commercial tools for cloud integration available from major software vendors and third parties, and these will often have pre-packaged "recipes" for integrating specific applications in hybrid cloud configurations. Check with the vendors to be sure your application needs are covered.
DevOps orchestration tools take a script-based approach
The majority of the more full-featured cloud orchestration tools fall into the DevOps product category. DevOps is based on the principle that an application developer knows how the app must be hosted and how the components are connected. During the development process, the developer would then create a DevOps "map" of this deployment/connection, and this map is used to deploy the app when needed.
DevOps tools are procedural or script-based; in the most simple form, a DevOps program or script might be nothing more than a set of commands an operations team member would enter to deploy and connect the application. Information such as IP addresses that would be developed only during deployment are given symbolic names, which are filled in when the component is hosted, and these can then be referenced to create component connections.
Script-based tools have the advantage of being easily derived from manual processes. Their greatest disadvantage is that they describe the process and not the outcome; a script must provide instructions for everything that may be encountered. Some users report that DevOps scripts can be harder to maintain than software because it's hard to know from reading them just what the expected outcome is. If script-based orchestration is used, it's critical to document exactly what's being done and to note any conditions that the scripts are not equipped to handle.
There are open source and commercial DevOps tools available, so it's necessary to research the best fit for your company and development team.
Model-based approach speaks to cloud providers
Script-based orchestration is the rule in virtualization, but network operators and cloud providers favor model-based approaches because they offer better service lifecycle management. In model-based orchestration, you describe the structure you're working on and create constraints -- such as what components run on and the type of connections -- and software builds the structure you defined. These models are typically easy to read and understand because they define what you're trying to achieve rather than the steps getting to that state, as with the DevOps approach. IT departments can use the models to recommission failed app elements, tear down applications or make lifecycle changes -- all of which would require their own separate scripts if script-based orchestration is used.
Hybrid script- and model-based approaches, however, have become common in the cloud because of users' and operators' divergent needs. In OpenStack, for example, the model-based approach can be used on applications to create a series of subnets on which components are hosted and then connected into higher-level networks. OpenStack Neutron, its network portion, defines network models, but to deploy app and database components, it's necessary to use other OpenStack services. An OpenStack DevOps tool would likely create Neutron network models then deploy components --using compute resources or DBMS/block storage -- into the defined network elements.
A step-by-step approach to cloud orchestration
No matter what tool your company chooses, the first step in cloud orchestration is to do a complete manual application deployment and record the steps carefully. In particular, note all places where the result of a step will be used later on -- for example, a component's address. This will establish the baseline that the orchestration is expected to complete, and the manual record of steps can be used to build either the script or the model.
Model-based orchestration will require grouping steps according to their goal -- host components on a previously defined subnet, for example. These groups must correspond to the models available.
Testing is the last step in cloud orchestration. Your orchestration script or model should, when activated, deploy a functioning software system. Any deviations from your manual process should be reviewed to ensure that there's not an error in your orchestration. Be sure to record your test/validation steps as well, because cloud orchestration is a critical element of application lifecycle management and the stable operation of your applications to support your business. Get it right and keep it right with a completely auditable software lifecycle process, or you'll regret it later.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in January 2014