One of the primary objectives for any DevOps effort is to automatically provision and manage physical infrastructure through code, rather than through manual, hardware-centric processes. But building infrastructure-as-code (IaC) capabilities can be challenging in practice. The three principles described here can help your DevOps team shorten and simplify development cycles, and accelerate the business in ways that weren't possible even a year ago.
Why you need infrastructure as code
It’s not hard to see why infrastructure as code is soaring to the top of the DevOps agenda. Historically, developers created a software product and handed it off to the IT operations team, which built the infrastructure to run it. That hardware might have looked very different from the infrastructure the development team used, so it might not have delivered the expected results. Quickly provisioning infrastructure was a challenge, too. You had to create a business case, get it approved, and then choose and purchase the hardware. The whole process could take weeks or even months.
That's why software teams started building more automated development and test processes. It enabled them to run separate code modules and then check them into the larger code base for systemwide testing. From the developer's point of view, moving from the system test area to the production environment is simply the next step in the release process chain. As you gain greater confidence in the code, you take it from one step to the next until it finally moves into production. This should be a single, continuous process, without any disruption at the point when the infrastructure is allocated.
The operations side of the DevOps team knows a lot more about how the infrastructure works than the developers know—or want to know. The development side of the DevOps organization doesn’t care where infrastructure comes from. They just want it to be available when they need it, and they want it to be flexible enough to make changes easy. In short, they want an infrastructure layer that they can deploy, configure, and manage in much the same way as the application software they’ve developed.
Why not just put it into the cloud?
The public cloud is an attractive approach for many developers, as it offers very fast, programmatic access to infrastructure. For example, if you’re building a custom, online application that will be accessed by a global set of customers, a cloud-based infrastructure as a service (IaaS) is a natural. You can easily test and make changes, and then roll them up automatically.
But this approach has a downside in that the cloud becomes a new silo. In fact, the more clouds you use, the more silos you create. Applications deployed in these different clouds must be managed uniquely and differently from apps running within the enterprise data center. This two-track, or multi-track, approach can create friction within the organization by separating teams into those who support the shiny new, cloud-based digital economy apps and those focused on traditional infrastructure and applications.
Dev and ops teams need one infrastructure that spans both IT modes and can be managed in the same way. If you're using the same team and the same tools, you don’t have to worry about creating and managing a new silo. IaC calls for on-premises infrastructure, with all the programmability and speed of cloud.
3 principles of IaC
So what does such an infrastructure look like? It must have the following three capabilities, which together define a new category of infrastructure called composable infrastructure. Modern software development is shifting to the use of microservices that you can easily compose to form complete applications. Similarly, composable infrastructure combines the elements that make up data center systems into the greater whole that you need for your applications. These elements include:
Fluid resource pools of compute, storage, and network fabric
In a development environment, you need to know that the infrastructure can match whatever your needs are from a software standpoint. How much compute and storage do you need? To which networks are you going to be connecting? You need infrastructure that has all three elements in place, ready to go, without the headaches of configuring them or writing thousands of lines of code to provision, say, a single server.
Infrastructure becomes a set of flexible building blocks that can be assembled and re-assembled on the go to meet changing workload needs. Capacity for physical, virtual, or container-based workloads can be continually aggregated, disaggregated, and re-aggregated to support the needs of specific applications and services. Data storage resources can be defined at the block, file, or object level, based on application requirements, and you can assign bandwidth dynamically, for multiple protocols.
One advantage of this approach is that by treating compute, storage, and networking as fluid, disaggregated resource pools, you reduce the occurrence of over-provisioning and stranded capacity, which contribute to capital expenses. As soon as a resource is no longer needed, it returns to the pool, where it can be allocated to another application.
Software-defined intelligence
A native software-defined intelligence within the infrastructure composes and recomposes resources to match application needs. It uses repeatable templates to provision resources, together with their state (BIOS settings, firmware, protocols, etc.) and the operating system image, to create logical infrastructures at near-instant speeds.
Developers and operations team members work together to develop the appropriate templates. IT ops understands the minutia of how the physical infrastructure works. The templates enable them to abstract that knowledge so that all the developers have to do is pick the template they want to be able to provision resources for an application.
Developers can specify the version of firmware they want, the networks to which they want the app to be connected, and the operating system they want to load, all without having to understand the hooks into those systems. Change operations are hugely simplified, reducing manual work and human error, and a single management interface eliminates the need for multiple teams and tools.
A single, unified API for automated infrastructure deployment
Since fluid resources are now served up IaaS-style, all you need is a single line of code that requests the compute capacity, network connectivity, and storage resources necessary to run a workload in production for that capacity to be dynamically allocated at runtime. This unified API gives developers control and eliminates the time-consuming scripting associated with low-level tools and interfaces. Intelligent software handles the details, delivering exactly the right amount of compute, storage, and networking that the application needs.
The API handles physical resources in the same way it does virtual and containerized resources, so developers don't need a detailed knowledge of the underlying infrastructure. In a composable infrastructure, the API is REST-based and includes language bindings for common languages such as Java and Python, allowing developers to access it directly from those languages. In addition, the APIs typically integrate seamlessly into tools like Chef and Ansible, so developers can continue to use the DevOps tools they already know to deploy applications and associate them with the infrastructure.
What you can do with IaC
A composable approach to IaC helps DevOps teams do many things better. For example, it can:
- Eliminate the need for two environments. You can create your new IT-style mobile and cloud-native applications using the DevOps methodology and load them directly into the same environment you’re using for your traditional apps. For the development team, that means the IT ops team can manage the ongoing lifecycle of new applications. Developers are interested in writing new code and deploying it; they’re not usually as excited about doing the maintenance of the applications, operating systems, and infrastructure underneath it. IT may not be supporting apps that run in the cloud, so developers end up being responsible for the ops side of things, which isn't their forte. IaC provides a unified environment, enabling the continuous development process that DevOps teams need while providing a natural way for IT to continue to support the application lifecycle.
- Accelerate deployment cycles. DevOps shops develop and deploy apps faster when they use a programmatic interface that allows them to allocate infrastructure quickly by specifying the app's resource requirements.
- Simplify day-to-day management and updating. Using IaC with composable infrastructure enables routine tasks like updating firmware, adding more storage, or modifying network connectivity to happen automatically. For software development projects, it can accelerate day-to-day builds as resource requirements change. Hardware configurations are maintained as software templates that get stored in the same repositories as the application code.
DevOps teams don’t care about what infrastructure is running in the data center. Their goal is to create and run their apps more efficiently and help the business stay ahead of the competition. IaC gives them instant access to the infrastructure resources they need to speed the application development process, deliver better experiences for users, and bring ideas to market faster.
Image credit: Flickr
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
