E-Handbook: How to get the most out of automation in the cloud Article 2 of 4
This article is part of our Essential Guide: Follow this enterprise cloud automation and orchestration guide

Let cloud orchestration tools do the hard work

A smart cloud strategy requires a smart automation strategy. These steps will help position your cloud to benefit from automation and orchestration technologies.

Organizations want IT operations to work. They might describe their approach as orchestration or automation or even DevOps. Whatever label they use, the intent is to improve the efficiency of operations personnel, quicken application deployment and redeployment and reduce human errors that can take down whole systems of applications. Many think it's just a matter of picking the right cloud orchestration tools, but it's a lot more than that.

The critical step toward a smart automation and orchestration strategy is to think about domains. Virtualization and cloud computing create a series of swirling, interlocking swarms of resources and application components. There's no way to track and orchestrate them one by one, so you have to think about collecting them into domains that can be handled efficiently.

Every grouping of resources in your IT infrastructure is a domain, a resource domain. Each public cloud provider is a separate resource domain, and within your own data center, there's a domain for every type of virtualization you use -- VMware, OpenStack, bare metal, Docker and so forth. If you have the option, orchestration and automation will be easier if you minimize the number of domains. Trying to achieve hosting optimality by using dozens of hosting partners and technologies is going to make orchestration and automation almost impossible.

Resources form domains, but so do the various virtualization technologies. Each of them creates its own deployment framework, the presumptive strategy for application deployment, redeployment and connection.

Frameworks for success

Defining these deployment frameworks is the second critical step.

Containers, IaaS or virtual machine, and bare metal are the three dominant frameworks. Again, your life will be easier if you have as few deployment frameworks as possible. More and more organizations are now settling on containers as their deployment framework in and out of the cloud for this very reason.

Every deployment framework is linked with cloud orchestration tools and related automation strategies. Kubernetes is associated with container orchestration in both the data center and the cloud, and Heat is an OpenStack standard. Cloud providers all offer orchestration tuned to their own deployment models, too, but there's considerable overlap in the available cloud orchestration tools. Look for the combination that covers your deployment frameworks with the smallest number of tool options.

By minimizing the number of deployment frameworks in use, you'll minimize the number of different orchestration and automation approaches you'll have to harmonize to create an overall .

Identify and organize

Events are conditions that need to be handled, and responding to them is what orchestration and automation is all about. It's the process of taking an application in a current state and transitioning it to the desired state.

That is the third step. You'll need to synch your deployment frameworks with your VPN. This gives users access to applications, and workflows can be integrated across application boundaries. Cloud orchestration tools will almost always go as far as exposing the application or component interfaces you'll need to access, but you'll have to organize how they're exposed. That starts with an addressing model for your organization. Users, for example, should be given a range of IP addresses; applications should have another range.

You might want to separate your users according to geography, their roles, or both, which means dividing the user IP address range into smaller segments. Keep all your groups contiguous so you can easily write firewall and forwarding roles. Never intermingle internal user addresses with internet addresses. This complicates security.

On the application side, some businesses prefer geographic groupings, and some like to group by the security requirements of the applications. Keep payroll, personnel and customer-data-management applications separate from other types. For all applications, remember that you will deploy the application within a resource domain using your selected deployment framework and tools and then connect it to the VPN. Deploy and connect is the rule.

The state of events

This sets up the fourth step, which is to think of application operations in terms of states and events. An operating state is a condition that an application is in, ready being a common name for the state that indicates the app is working properly. Some deployment frameworks, like containers, offer specific guidance on operating states, and you can use those as a reference.

Events are conditions that need to be handled, and responding to them is what orchestration and automation is all about. It's the process of taking an application in a current state and transitioning it to the desired state.

For each of your deployment domains, you'll need to create a conceptual state or event . What does a correctly running application look like? That's the ready or goal state. What conditions do you need to handle failures of servers or connections, overloading that demands you scale an application, etc.? Orchestration and automation is the application of the tools you've selected for the deployment framework to the state or event conditions within that framework. One aspect of the process is always the reconnection of the deployed applications to your company VPN.

It's also worth thinking about special conditions, primarily those that would require deployment of something across domain boundaries. If you can keep your redeployment of applications within a single resource domain and a single deployment framework, then assume you won't have special problems here. This is the of special concern for cloud users, because cloudbursting between the data center and the cloud, or using one cloud provider to back up another in multi-cloud, always generates deployments that cross domain boundaries.

Every resource domain has gateways onto your company's VPN, and it's through such a gateway that orchestration and automation processes will connect your resources and users. When you move something to a cloud, the normal procedure is to deploy and connect, remember? The connect is now a two-step process: connect deployed resources to the company VPN and then connect the gateways to integrate your application components.

That's orchestration and automation. You deploy, using tools according to the selected deployment frameworks. You connect, via the company VPN, with your users and with other applications hosted in other domains. The best automation technologies and cloud orchestration tools will be those that cover the largest number of your resource and deployment domains, and the way that you organize the process will make more of a difference in the outcome than any tool selections.

Dig Deeper on Cloud infrastructure design and management

Data Center