Using the principles of IaC lowers the total cost and improves the quality of any software installation. It also reduces the setup time for a complete and scalable cloud-solution.
Infrastructure as Code (IaC) enables software development teams to set up an IT infrastructure without being dependent on system administrators. Using the principles of IaC lowers the total cost and improves the quality of any software installation. It also reduces the setup time for a complete and scalable cloud-solution. IaC has been embraced by the IT industry and is increasingly used by modern development teams for software development and IT operations. Does this mean we can manage without the ‘Ops’ in DevOps now? Well, maybe not – but it definitely changes the way we work.
What is IaC?
Infrastructure as Code is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools [1].
In other words, the software developer writes a description of the required hardware and software. This description is then read by a program and the hardware and software is setup automatically. Writing such descriptions is like writing software code and this is the basis for some of the benefits of using IaC. Before looking at the benefits, let us take a brief look at the problems IaC set out to solve.
Why do we need IaC?
In the early days of computers, people relied on mainframes to run computer programs. Mainframes were powerful computers you could access through a terminal, perhaps without knowing where the physical mainframe was located. Then came the era of the personal computer which allowed us to run programs on our own hardware. The last decades we have seen a shift back to central servers through cloud computing.
Through this evolution of IT infrastructure, we have depended on system administrators to configure the hardware. Setting up and maintaining mainframes certainly requires operational knowledge. Even when running programs on our own laptops, most of us prefer that someone installs the operating system for us. When public cloud providers like Microsoft, Google and AWS first gave us access to large data centers, we still needed someone to configure the hardware through the tools available in the cloud portals. With Infrastructure as Code, this has changed.
The benefits of using IaC
Speed
Setting up a server manually takes time. Ordering and setting up physical servers takes days or weeks. Even if you use a public cloud provider and do not have to go through the process of buying the physical hardware, you spend time. You might need to wait for someone with the knowledge and privileges to do the job. Even if you can do it yourself, there is often a long checklist you need to follow to get the configuration right.
It also takes time to scale an application to meet higher traffic. Upgrading servers with memory or more powerful CPUs, or even adding more servers, is a slow process.
With IaC this is automated. A new server can be provisioned within minutes, depending on the complexity of the server.
Cost
The tedious work to manually configure IT infrastructure is expensive. Automating this work does not just reduce the cost, it also makes qualified personnel available for more rewarding tasks.
With public cloud, we pay for the resources we use. We have access to unlimited amounts of hardware. Yet, if we set up more hardware than we need, the resources are under-utilized and the cost will be unnecessarily high. Hence, we want to adjust the resources based on the needs of the users. It is important to be able to scale up, providing enough power to meet the user’s needs. In addition, it is also relevant to scale down to keep cost low when there is no user activity. In the IaC-description of our servers, we can specify the conditions for when to scale up and down, which is then handled automatically.
Quality
After the initial setup of hardware and software, you often modify the configuration to optimize performance or fix errors. If there is a need to restart the server or perhaps even replace it, traditional IT operations make it hard to reproduce all modifications and reach the exact same configuration. This is the reason for many recovery failures. IaC help address this challenge known as configuration drift.
With IaC you handle the description of your infrastructure in the same way as software code. This means you can apply the same automation techniques for your infrastructure as for your code. You can also store it in the source code configuration system, test it using automated tests, and you can include it in continuous integration (CI) and deployment (CD).
As for the software code, you can trace errors in the system back to a change in the IaC-description. It is easy to roll back to a previous version to get back to a working state. Through CI and CD you can deploy fresh testing environments by the click of a button. You can create the exact same environment repeatedly, without the risk of introducing manual errors. All of this increases the quality of the total system. You can use the same description to set up a test environment on the developer’s machine, a staging environment on a server and ultimately the production environment.
Turbulent Flux and IaC
In Turbulent Flux our goal is to automate all provisioning of our software and IT infrastructure. A cloud-native solution and IaC makes this possible.
There is a number of tools that support IaC. The tools can be divided into two categories. The first category are tools for automating the deployments of servers and infrastructure. The cloud providers have their specific tools but there are also independent tools. The second category are tools for automating the configuration of software and systems already provisioned on this infrastructure. In Turbulent Flux we prioritize tools that are independent of the cloud providers, like TerraForm [2] and Kubernetes [3], in order to be cloud agnostic.
Docker containers [4] provides a way of packaging applications and their dependencies into containers that can be run in any environment. Docker is an important part of our adoption of IaC. We package all our software components (like the multiphase flow simulator, our public API and the user interface) as Docker containers. The containers are deployed in a data center, in public cloud or on a local desktop.
We use continuous deployment pipelines to set up production environments for our clients, including API servers, databases and file storage in addition to the multiphase flow software. This ensures that we can quickly deliver a well-tested scalable infrastructure with a very low risk of introducing human errors.
So what about the system administrators, do we still need them?
The tasks performed by the system administrator have certainly changed. That is to say, the system administrator needs to know programming and scripting, and the developer needs to acquire knowledge about the environment which the software is running in. It is truly the distinction between the developers and system administrators that is fading, not the need for knowledge in the fields.
The Turbulent Flux software team uniquely combines knowledge about development and operations with domain knowledge in multiphase flow and data analytics. IaC is one of the tools which enables our modern DevOps team to deliver high quality end-to-end solutions. In short, IaC is that zone between Dev and Ops where the work of the system administrator morphs with that of the developer. Referring this back to the article title, this is where the power lies!
[1] – Wikipedia – https://en.wikipedia.org/wiki/Infrastructure_as_code
[2] – Terraform by HashiCorp https://www.terraform.io/
[3] – Kubernetes https://kubernetes.io/
[4] – Docker www.docker.com
