Any time an operations process becomes more dynamic, IT teams face increased complexity. When applications change...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
dynamically, agile or continuous application development is a good response. But what about when IT resources themselves dynamically change?
Multicloud and hybrid cloud are part of this new, more dynamic IT paradigm -- and present new risks. To address this, some organizations use infrastructure as code.
Configuration management (CM) has long been a fixture in large-scale IT infrastructure. There are a number of CM tools, both from cloud providers, such as Amazon Web Services or Microsoft Azure, and from virtualization or private cloud software providers, such as OpenStack or VMware. Infrastructure as code extends CM by creating a virtual hosting model for applications. This virtual hosting model spreads across multiple clouds and data center platforms.
While infrastructure as code is an extension of CM, it's been popularized as an extension of DevOps. You can't deploy applications onto servers or cloud services that aren't set up. As a result, DevOps tools and scripts had to incorporate these configuration tasks. This made DevOps scripts and tools configuration-specific; if you changed from one cloud platform to another, you had to change the scripts. Infrastructure as code provides a way to separate the virtual world of applications from the underlying resources, including cloud. The more hosting options there are, the more valuable infrastructure as code becomes.
An infrastructure as code model creates an intermediate layer for describing deployment; you deploy applications to an abstract hosting model created with infrastructure as code, and infrastructure as code then fits it to whatever cloud, multicloud or hybrid configuration is in use at the moment. Changes to infrastructure are invisible at the application and operations level, and adding a new cloud provider is simply a matter of defining it in infrastructure as code.
IT teams can deploy infrastructure as code on any environment for which a configuration script is defined, and adapt applications to almost any public cloud service or data center platform.
However, there are three important steps infrastructure as code users often overlook:
1. Separate infrastructure as code and resources from DevOps
IT teams need to define an abstract model of IT resources, based on which infrastructure as code will deploy configurations. Infrastructure as code tools and practices vary widely. Some users build infrastructure as code models for each application, while others build general models for each type of cloud hosting environment, such as infrastructure as a service, platform as a service or Docker.
Generally, it's best to minimize the number of abstract hosting models you create, because you'll have to tune each of them when you add new hosting options. Where tools permit, consider building models in a hierarchy, so that the infrastructure as code model for deploying an application component -- or a piece of an application -- is referenced in the model for deploying the whole application.
2. Secure infrastructure as code support for all cloud or data center environments you use
Once you understand the models you'll need, make sure they can support the specific cloud providers and data center configurations you plan to use. Nearly all infrastructure as code tools, such as Chef and Puppet, let you define your own configuration rules for any environment, but popular public cloud, private cloud and platform choices -- such as hypervisors, container systems and server operating systems -- are also offered as part of infrastructure as code toolkits. There may also be community support where other users contribute their configuration rules. It's easier to adapt to configurations that already work, than to start from scratch and build your own.
3. Generalize the flow of events from infrastructure to deployment tools
The most subtle, difficult and important issue to address with infrastructure as code is the event flows that integrate infrastructure as code with other tools; in most cases, that means with DevOps tools. Operations management of application lifecycles using software means responding to conditions -- and these conditions are considered events in infrastructure as code. These events, which are generated by hosting resources, act as a signal to do something. They usually activate an automatic process, such as replacing a failed application component by hosting it somewhere else.
Infrastructure as code events and processes are closely linked, which is why most organizations that plan for hybrid or multicloud deployment will look for infrastructure as code support in their DevOps tools, rather than in separate tools. Integration of infrastructure as code and DevOps ensures proper design and implementation of event-triggering processes.
The integration of infrastructure as code into DevOps also helps users avoid common mistakes. It's much easier to plan hosting resources with infrastructure as code if you have a specific tool in mind, and if infrastructure as code is integrated with DevOps. This is because it's easier to visualize the entire deployment process and the role of infrastructure as code resources. DevOps tools and packages advertise the public cloud services they support, and if the DevOps tool contains an infrastructure as code component, you know the tool will work with the public clouds listed.
To be effective, infrastructure as code has to work closely with DevOps, but retain its own identity. If you're not careful, you'll develop configuration and deployment practices that blur the boundary and gradually erode the resource independence -- the biggest benefit of infrastructure as code. It's crucial to maintain agile infrastructure in multicloud and hybrid cloud deployments, so that should be a specific objective.
This is the first part of a two-part series on using infrastructure as a code for hybrid and multiple cloud management. Read part two here.
Find out if a configuration management system is right for you
Control your infrastructure with IAC
Overcome these common multicloud challenges