With the spectacular rise and growth of (public) Cloud platforms, it has become possible to radically change the way IT infrastructure is handled. Think, for example, of Infrastructure as code.
Because the scale of public Clouds is so large, there are few restrictions on how many resources can be requested. Because many physical components (servers, networks) are virtually available, setting up and tearing down resources is much less labour-intensive.
Where previously tickets were created with a management party that then ordered hardware and then sometimes manually configured and made it available, the entire process can now be completed with a few clicks and in just minutes.
This radical acceleration has led to a different way of dealing with infrastructure. Because the costs (in time and money) for setting up and dismantling infrastructure have decreased considerably, the threshold for applying for new infrastructure and dismantling old ones has been lowered.
Major growth in the number of infrastructural components
In many cases, the result is a large growth in the number of infrastructural components, with a shorter lifespan on average. Moreover, the infrastructure can be much better attuned to the needs of the moment, because it is now possible to make adjustments when they are needed, instead of far in advance.
What is the downside?
The combination of growth in infrastructure and its shorter life cycle also has a downside. Manually maintaining configurations and managing infrastructure components becomes more complex as the number of actions to be performed increases. For example, it is easier to manually keep the configuration of three equal servers in sync than 100 virtual machines. Performing a configuration change three times or a hundred times makes a big difference in the management capacity required. It is also not surprising that various tools have been available for some time to, for example, roll out configurations to multiple (virtual) machines.
The next step: infrastructure as code
In a (public) Cloud environment it is possible to take the next step. This not only automates the configuration of infrastructure components, but also their creation. An entire environment can then be defined in one or more files, which are readable by a system that can set up the infrastructure components with this definition. This next step in the IT infrastructure automation process is known as “Infrastructure as code”, and the systems that can turn this code into actions are called “Resource Managers”.
Benefits
Speed and reliability
One of the most obvious advantages of applying infrastructure as code is speed gain. Instead of having to “click together” each resource by hand, a configuration file can be presented, after which the Resource Manager does the rest. This speed gain can also lead to a cost reduction, because less management capacity is required. Reducing the number of manual actions also reduces the chance of errors.
More time for other work
By capturing infrastructure in code, and having it rolled out by a Resource Manager, time can be saved on managing this infrastructure. Instead of having to make manual changes (several times), these are now done entirely in the code. That means more time is left for work that adds more value.
Predictability and maintainability
As with application code, it is also the case with infra code that the same input always gives the same output. For example, if 20 Kubernetes clusters are created based on a template, it is certain that these 20 clusters also meet exactly the same specifications. By using infra-as code, it is also possible to prevent different environments that should be alike from drifting apart in the long run. Changes to infrastructural components can also be carried out quickly and reliably.
Version control
The code used to define infrastructure can be included in version control, just like application code. For example, changes can be tracked, actions can be rolled back if problems occur, and associated infrastructure can be defined for specific application code.
Impact on People, Processes and Technology
New tooling
Because infrastructure can be recorded in structured files, it has also become possible to have these code files read by software. AWS and Azure both have their own JSON and YAML based infrastructure deployment mechanism with CloudFormation and ARM templates. Hashicorp Terraform goes one step further, and even allows users to create templates that can be deployed on AWS, Azure and GCP. It is therefore not necessary to write software yourself that reads infra-as code and converts it into the correct commands to Cloud providers.
Pay as you go Infrastructure Licensing
Infrastructure has largely become virtual due to layers of abstraction from Cloud providers, and the use of infrastructure-as-code enables customers to provision infrastructure for both short and long term. Licensing structures have also changed; where previously a purchase price per hardware was charged with on top of that a periodically recurring fee, now payment is made per hour or per minute. This way of calculating costs can be cheaper or more expensive depending on use. However, it is becoming more difficult to predict the costs of IT infrastructure. After all, the costs can be different every minute.
Work differently
A switch from traditional infrastructure management to infrastructure-as-code use requires a change of approach on the part of the managing party. Instead of working on the infrastructure itself, it is now the code that defines this infrastructure where the work needs to be done. Changing a setting on a server, or opening a port in a firewall is no longer an issue, because with a next run of the Resource Manager these manual changes are all overwritten with what is included in the infra code. This means that the traditional role of the infrastructure manager
will have to be restructured, or even partially disappear.
A switch to infrastructure as code offers the opportunity to think differently about the division between management and development. With the skillset required to maintain infrastructure code more aligned with the skillset of software developers than traditional infrastructure management, it becomes easier for development teams to maintain their own infrastructure as well. This is in line with the DevOps idea, in which the person who builds a system is also responsible for the operational work on that system.
Governance changes
The faster pace of change and the ability to decentralize infrastructure management pose challenges for organizations embracing infrastructure-as-code. There may be less control over which infrastructure components are set up and which are configured correctly. The division of responsibilities needs to be rethought. If there is no central department that manages infrastructure, how can it be ensured that all standards and (security) requirements are met?
Conclusion
A switch from physical infrastructure, or separately configured Cloud infrastructure, to infrastructure-as-code raises issues regarding working methods and governance. Once these issues have been resolved, the use of infra-as-code will enable users to better utilize the possibilities of a (public) Cloud. By defining which infrastructure should be available, and how it should be configured, it is easier to control large amounts of resources. By using available tools, an entire landscape can be rolled out, updated, or demolished at the touch of a button.
It is important to bear in mind, however, that a switch from centrally managed infrastructure to infrastructure established in code entails issues regarding working methods and governance. If you want to be able to act quickly and accurately in a (large) Cloud landscape, you cannot ignore the advantages of capturing infrastructure in code.
