Guido Vrola - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Infrastructure as code complicates hybrid, multiple cloud management

With every action, there is an equal and opposite reaction. The same rule applies to IaC: While it's beneficial, it creates some problems.

This is the second part of a two-part series on using infrastructure as code for hybrid and multiple cloud management. Read part one here.

Infrastructure as code is a powerful tool to help streamline hybrid and multiple cloud management because it automates the deployment and configuration of servers, containers and VMs. But it can also lead to inefficient processes, deployment errors and general chaos. How you address the challenges of an infrastructure as code implementation will determine the outcome.

The first challenge most organizations encounter during an infrastructure as code implementation is creating a smooth relationship between developer and operations teams. In the past, developers had little to do with the setup of hosting platforms for applications. This created issues, especially during the transition from application testing to production. DevOps tools -- which are most commonly used in large organizations -- help drive cooperation between developer and operations teams. But, for companies without a DevOps culture, a hybrid or multiple cloud implementation might be the first time this cooperation is required.

An infrastructure as code implementation is easier to accomplish if organizations associate an application with a specific platform when development begins, and then let those platform requirements drive infrastructure policy through application lifecycle management to production. It is also easier to achieve when there are a manageable number of virtual platforms. These virtual platforms are the targets for application development, and are used to deploy an application on all cloud or data center resources on which it will run. Carefully define these virtual platforms and let both developer and operations teams use them as the focus of their own activity.

Don't blur the lines between roles

The second challenge is ensuring that infrastructure as code and DevOps play their proper roles in a hybrid and multiple cloud management strategy. DevOps is about application deployment, and infrastructure as code is about resource configuration management. The fact that Amazon Web Services (AWS) offers the DevOps tool Chef as the deployment management tool for its cloud service shows that the boundary between the two can blur. In fact, the most common infrastructure as code tools are part of DevOps. This can create ongoing confusion between development and operations teams.

The most common infrastructure as code tools are part of DevOps. This can create ongoing confusion between development and operations teams.

Unless you use cloud services purely for server consolidation, expect to also need DevOps to automate deployment and streamline application lifecycle management. Deploying multi-layer, multi-component applications and orchestrating their response to cloud or data center failures is too complicated for organizations to do consistently and correctly -- without the right set of tools. Pick a DevOps tool, such as Chef, Puppet, Ansible or Salt, and then adopt its infrastructure as code approach, even if you don't need all the DevOps capabilities immediately.

Don't treat all cloud providers the same

The third challenge when using infrastructure as code to simplify hybrid and multiple cloud management is addressing disparate cloud hosting environments. Most users will eventually have a hybrid or multiple cloud model, and many already do. Every public cloud provider has a different management framework, reports problems differently and requires different remedies if something goes wrong. Managing these issues will blur the boundaries between application deployment with DevOps, and configuration control with infrastructure as code.

Follow the recommendations of your DevOps tool supplier to define which conditions are handled at the infrastructure as code layer and which are reported -- as "events" -- at the DevOps layer. Determine whether any changes you plan to make will affect how a virtual platform is deployed, or how the application itself is deployed. In the first case, consider redeploying the resource, such as a VM or container; in the second case, consider redeploying an application component. For example, if you have to scale an application component, changes must occur at the DevOps layer, but if you have to replace a failed component, you may be able to do that at the infrastructure as code layer.

Allan Shone, senior software engineer
at Expert360, takes a look at ways to
manage infrastructure and introduces
the pros and cons of various tools,
including Ansible, Chef and Puppet.

The next challenge stems from the fact that cloud providers have different web services. Infrastructure as a service and basic container services provide minimal middleware outside of application images. But some providers, such as AWS and Microsoft Azure, offer web services that are essentially cloud-hosted middleware. Cloud providers offer these web services in different forms, or, in some cases, don't offer them at all.

Applications are not portable across hosting environments that don't offer the same features. If it's not possible to harmonize web services among cloud providers, name your virtual platforms to indicate they are not portable. If the necessary web services are available on all cloud platforms you use, but require different deployment configurations, define multiple hosting options for your virtual platform in your infrastructure as code script.

Don't approach infrastructure as code in pieces

The final challenge in infrastructure as code implementation is tinkering with outside configurations. It's difficult to make infrastructure as code work in disconnected pieces, or when organizations make some configuration changes without infrastructure as code tools or scripts. For example, operations teams often make configuration changes to adapt to new software versions without changing infrastructure as code scripts or models. This means that those scripts will no longer deploy the correct version of the hosting configuration.

Solving this problem requires operations discipline. No operations team should ever make a change to a system or cloud configuration without documenting the change through a formal change management system. When they do make a change, they should change the infrastructure as code script and reconfigure it as such, and then document the changes. Any time operations teams change infrastructure as code scripts, they must feed that change back to development teams to validate it against application requirements.

Infrastructure as code is an evolution from both configuration management and DevOps, but it's also an emerging paradigm. It's important to plan for the future of infrastructure as code, or you'll risk falling short of its full potential for your hybrid and multiple cloud management and deployment.

Next Steps

Learn the difference between DevOps and orchestration

Understand IaC and DevOps infrastructure

Weigh your choices for automation and orchestration tools

Dig Deeper on Cloud automation and orchestration