One of the more compelling aspects of modern enterprise architecture is the idea of Infrastructure as Code (IAC). By virtualizing entire data ecosystems, organizations gain the ability to design, provision and manage them completely in software, ushering in a new era of infrastructure flexibility and cost-efficiency.
But while this may seem like digital nirvana, there are still some kinks to work out before the enterprise can truly transform itself into one fully functional, data-driven entity, particularly when it comes to tailoring IAC architectures to modern DevOps workflows.
According to Carlos Schults, .NET software developer at Stackify, IAC has emerged in response to the need for highly flexible, highly dynamic infrastructure demands of modern applications and services. As the enterprise business model shifts from providing products to providing digital services, the static legacy approach to infrastructure, in which hardware and software were integrated on a fundamental level, is proving to be too restrictive and costly. These days, successful businesses require broad scalability and substantial flexibility when it comes to deploying, provisioning and orchestrating disparate data resources.
In a hardware-centric environment, these functions must be done manually, with a lot of hands on manipulation of server, storage and networking elements. This is anathema to today’s digital environment, which often requires the creation, and decommissioning, of highly customized data environments on the fly. By switching to a software paradigm, however, the enterprise gains the flexibility to not only streamline infrastructure management for human operators but to extend full orchestration and automation capabilities to allow intelligent, autonomous applications and services to create their own virtualized data environments at will.
IAC is a crucial step in this evolution and is key to the development of DevOps business practices. In DevOps, the linear, monolithic approach to software development is replaced with a modular, flexible scheme in which different teams oversee design, test, configuration, deployment and other tasks all at once. The advantage is rapid turn-around of new features and products on a continual basis, as opposed to the once-per-year (if that) approach of traditional development cycles. This Continual Integration/Continual Development (CI/CD) model is enhanced greatly by IAC because it places all of the complicated, time-consuming resource-provisioning and management operations on an automated footing, meaning the proper infrastructure can be implemented at the speed that modern applications require.
With IAC, in other words, the era of on-demand infrastructure has arrived.
But as mentioned above, not even a full-stack IAC environment is worry-free. As workloads scale and the need for increasingly complex, high-speed development evolves, the enterprise will have to weigh the pros and cons of the various tools they use to implement virtual ecosystems. As Infostretch Labs’ Sanil Pillai noted on SD Times recently, some tools are better for certain jobs than others.
For example, combining HashiCorp’s Vagrant VM management software with Docker containers and the Ansible IT automation stack provides a high-level OS abstraction and simplified software installation and maintenance, but comes at the expense of a lack of Mac OS support and a high learning curve for inexperienced coders. This may save time and effort for JDK 8, IDE and Apache Tomcat projects, but not for some Apple applications. Likewise, combining the Terraform CLI management tool with AWS and Jenkins orchestration allows for easy creation, scale and tear-down of services, but may not provide the support necessary to develop cloud-based GUIs.
Techs Are Still in Charge
Another pitfall surrounding IAC that enterprise executives would be wise to avoid is thinking that they no longer have to worry about things like networking principals, says Rollout.com’s Mark Robinson. Regardless of how resources are managed, operators should still have a thorough understanding of traffic routing, network architectures and configuration processes, otherwise there is no way to ensure that software-driven automation tasks are delivering optimal results.
As well, Robinson says it is important not to view operations and development as one and the same. While they may be conjoined under DevOps, they remain distinct functions. Rather than simply writing network configuration scripts as part of the DevOps process, IAC opens up the possibility of automating scripts entirely, allowing fully scalable, on-demand infrastructure to be configured completely in code.
All of these developments – IAC, DevOps, CI/CD – are pushing the enterprise toward a full service-based operational environment that is fittingly known as Enterprise as a Service (EaaS). In this world, infrastructure is delivered as a set of discrete services in the same way that many enterprise applications like CRM and ERP are delivered today. In this fully virtualized world, IT is delivered at the scale and composition as needed, allowing organizations to define their working environments according to the demands of the business model, not the other way around.
IAC represents that first significant break from the confines of legacy infrastructure, but it should not be viewed as the end-game of IT evolution.