IT management continues to grow in complexity -- as does the constant drive for innovation and the development of new technologies. The need to increase our digital capabilities gives rise to an ever-increasing number of applications and hardware within our IT environments, leading to widespread bottlenecks and performance issues, writes Alex McMullan, Chief Technology Officer, International, Pure Storage .
Increasingly, we’re seeing the adoption of modern infrastructure solutions such as Infrastructure as Code (IaC), which lets IT operations teams automatically manage, monitor and provision infrastructure instead of through manual processes, solving many of the complexities associated with the management of sprawling IT environments. IaC is well-established as a model and is rapidly growing in popularity. In fact, the Infrastructure as Code market is projected to be worth $3.5Bn By 2030, according to Global Market Insights Inc.
This is no surprise, given that IaC prioritises flexibility, agility and speed in addition to enabling reliability and performance. IaC platforms integrate self-service IT experiences and scale-out, on-demand solutions that rise above physical architecture limitations. They enable organisations to adopt a cloud-like operating model on top of their infrastructure to deliver an agile experience to IT teams, empowering developers.
The emergence of Infrastructure as Code: How we got here
Infrastructure as Code has its origins in the rise of server virtualisation, which itself was driven by a need for a better way to manage critical IT infrastructure.
From my own experience, I remember well the challenges that preceded its advent. Working in banking in the mid 90s, I could have told you the server name of all the critical infrastructure services in all of the banks’ worldwide domains.
However, radically increasing amounts of data and workloads created a situation that demanded better infrastructure management and virtualisation was the solution. Combining servers using the ‘pets and cattle’ methodology multiplied the number of configuration items that infrastructure teams had to look after and manage. Instead of having one big server to run applications, you had that one big server to run many virtual machines, each doing smaller pieces of the overall workload.
This drove a need for the automation of monitoring and alerts, as it quickly became clear that when you’re dealing with a large fleet of physical servers, all of which are running many virtual machines, the complexity of management becomes exponentially more challenging. As a result, we saw an acceleration of configuration management database (CMDB) approaches to document which virtual machines ran on which physical servers. Over time, this process evolved and improved, and became the genesis of Infrastructure as Code as a requirement.
Why should CIOs and CTOs care about Infrastructure as Code?
Infrastructure as Code can deliver significant benefits to your organisation, particularly in terms of efficiency gained through repeatability and vastly reduced error rates. Humans are great at many things, but performing the same task repeatedly and without error isn’t one of them. Infrastructure as Code ensures lower levels of human error, speed, improved efficiency, cost reduction and the elimination of configuration drift, which occurs when changes to software and hardware are made and not systematically tracked. It also facilitates excellent scalability, whether you’re concerned with one server or thousands, without any impact on resourcing.
How IaC can help CIOs & CTOs overcome legacy technology complexity
One of the biggest challenges today’s CIOs and CTOs face is dealing with complexity, which often results from the way their infrastructure has evolved over time. Many large companies tend to have aggregations of business units that have been formed either organically or through mergers and acquisitions. As a result, it’s common to have a range of different technologies - each of which will have particular strengths and weaknesses. Adding to the challenges is the fact that these solutions often overlap. An effective Infrastructure as Code strategy will take overlap into account. There may be very good reasons to retain multiple Infrastructure as Code solutions for specific use cases, but it’s important to have clear, auditable policies and protocols in place around their utilisation.
Infrastructure as Code solutions need to be able to account for, and overcome the aforementioned issue of configuration drift, which is probably the biggest challenge when developing management strategies and considering how specific tools are used – especially when considering DevOps integration.
Best practices for Infrastructure as Code management
Issues are often only identified when an incident or accident happens in a live environment. That’s generally a result of testing and disaster recovery scenarios being very carefully staged and prescribed in terms of what actually takes place. A best practice approach for Infrastructure as Code management is to ensure your configuration management database (CMDB) is valid, clean and well monitored, and that your tooling for drift is accurate. Also, consider consolidation of tools to allow you to have one set of definitions of what the infrastructure looks like rather than many.
Additionally, it’s important to consider how you extract configurations from third-party devices, such as firewalls, network switches or storage arrays. It’s not just about the technology assets you own, but the equipment supplied by third parties and how they can be incorporated into your Infrastructure as Code model.
From a business continuity perspective, these configurations can be hugely helpful when attempting to recover quickly from a ransomware attack or loss of a datacenter. This is because Infrastructure as Code can help reinstate large elements of infrastructure quickly and cleanly using those configuration backups. The time it takes to recover 1 application from a backup is relatively small, but recovering 500 applications at once is a huge undertaking if done manually.
Getting the most out of IaC
Often when we talk about Infrastructure as Code, the emphasis is on infrastructure. We need to be paying greater attention to the code component too, to get the most out of Infrastructure as Code. Today, many more developers consume infrastructure directly from either an automated system from their own internal IT. Developers want to be able to build their own infrastructures, test them and sometimes take them through to pre-production, without having to encounter delays in raising multiple help desk tickets or other processes. Facilitating this way of working enables organisations to harness the true power and potential of Infrastructure as Code, especially as modern applications are written to be cloud-native using containers and S3 as the building blocks.
The future of IaC
Infrastructure as Code holds great promise and its popularity is set to continue as the trend towards cloud migration continues. That should come as no surprise, given its many benefits, including its cloud-like operating model for more speed and agility, its ability to both enhance and transform the role of the developer and to achieve business objectives while managing costs. The challenge for CIOs and CTOs is to adopt policies that allow its benefits to be maximised.
