Of OpenStack and Cloud Orchestrator

Untangle your infrastructure and service spaghetti

Tangle of cables attached to a telegraph pole

Tomorrow’s computing systems will extend from legacy hardware and applications inside the company, through to virtualized, API-friendly applications still on-premise in the data centre, and further out to cloud-based systems off-premise. These in turn will divide down still further into dedicated, single-tenant cloud-based services and multi-tenant public ones.

OpenStack is becoming a pivotal component in many of these deployments. Developed by RackSpace and NASA, it is effectively an open source operating system for cloud environments, managing distributed physical infrastructure that is abstracted into logical resources for IT administrators. It gives you API-level access to all these resources, so that you can combine them into various configurations.

The software is becoming increasingly important to many companies, whether they run their applications on a hosted version of OpenStack, or use it to drive efficiencies into their in-house infrastructure. It makes vendor lock-in less of a problem, and can often introduce new levels of flexibility into your IT infrastructure. But it also introduces another layer of complexity.

OpenStack rarely runs alone, or in one place. It must coexist with everything else that you have built up over the years. This has been one of the biggest challenges for companies marrying newer, cloud-based architectures with existing ones.

Cloud management systems have existed for a while now, and can help companies to manage OpenStack, often in concert with other cloud-based infrastructure services. Before choosing one, take a dive into the kinds of thing that they’ll be expected to do, and the underlying orchestration capabilities already within OpenStack.

Templates for different configurations are becoming an increasingly important part of this equation. They encapsulate best practices when putting together applications of different types, such as web apps, transactional databases, or business process management software.

OpenStack’s HEAT

OpenStack’s approach to patterns revolves around HEAT, its orchestration service. HEAT is a way of controlling complex cloud resources using a templating system. Underpinning it is the concept of a stack, which is a collection of cloud resources such as virtual machines, storage volumes, and network connections.

These stacks are defined using templates, which are human and machine-readable descriptions of the resources that a stack will be using, and how they work together. The templates enable IT admins to put together a stack that scales automatically, delivering the elasticity that people expect from cloud deployments.

OpenStack’s HEAT orchestration templates (HOT) are useful tools for defining the pieces of IT infrastructure that you want to use when deploying an application or service.

You can define access to these resources programmatically in a human- and machine-readable template, and this is a good example of OpenStack’s API-driven resource provisioning and management. You can also define the underlying software configuration needed to make the applications run, along with the necessary resources to delete when the application is to be removed.

HEAT is also designed to be compatible with Amazon Web Services’ CloudFormation, a proprietary templating language that describes AWS resources in its own stack.

Infrastructure templating tools like these already put IT admins furlongs ahead when it comes to application provisioning and deployment, but it may not get them all the way to the finish line. Workflow management is a big part of the orchestration process, and it isn’t strong in either HEAT or CloudFormation.

Service and workflow automation support

To make the cloud really sing, the infrastructure services that it provides should be folded into a higher level set of workflow and management services. Here, we look for things like integration with IT service management and workflow automation. It might be nice to integrate your VM and storage provisioning with your helpdesk, say, or connect your cloud configuration more intimately with your backup management or workload balancing process.

There are templating standards for this stuff, too. The OASIS standards group offers its Topology and Orchestration Specification for Cloud Applications. This works higher up the stack than HEAT, enabling administrators to describe the way that services and applications will work together in the cloud. TOSCA effectively approaches the problem from the top of the stack, while HEAT comes at it from the bottom up.

You can use the XML-based TOSCA language to describe operational behavior such as deployment and patching. You could fold your infrastructure provisioning and scaling into your DevOps program, making it easier for developers to scale up their testing infrastructure resources dynamically for ad hoc application stress testing, directly from within their tools.

Integrate all of the things

Then, let’s not forget that legacy stuff humming away quietly in the corner. Where does it fit into this happy cloud universe? Ideally, template-based management would also be able to cope with this stuff, too. IBM committed early to OpenStack, and provides several components that draw them all together, while also joining the dots between OpenStack HEAT’s infrastructure-centric templates and higher-level management services.

Admins can snap management services into Cloud Orchestrator to create a cloud ecosystem that manages services and infrastructure together. This lets them use services like Remedy, ServiceNow, or IBM’s own ControlDesk, among others.

IBM developed a technical committee to work on a translator between TOSCA and HEAT that would enable people to generate HOT documents from a TOSCA template. This has been helped by extensions to HEAT that deal with functions like software configuration, for example. It also supports TOSCA service templates directly, and is able to map functions into HEAT.

In addition to handling multiple levels of the service stack, Cloud Orchestrator also extends support to various platforms. It supports IBM architectures like Power, System z, and SoftLayer, but it also supports VMware. Outside the customer data centre, it integrates with Amazon EC2, and IBM also provides a Cloud OpenStack Service option that lets companies get up and running with OpenStack in a hosted environment.

As an open-source system, OpenStack can be daunting to set up and manage, and tricky to integrate in a hybrid cloud context, especially if you’re hoping to layer other services on top. Cloud management systems provide a little glue to bind it all together, and give implementation teams a more cohesive approach to the problem.

Look at the breadth of your implementation, and the level of integration that you’re hoping to achieve with your workflow automation and service portfolio, before making a choice.®

Sponsored: The Joy and Pain of Buying IT - Have Your Say

Biting the hand that feeds IT © 1998–2017