Ein Beitrag von Thomas Mohrbacher
Why Terraform? – Part I
As Terraform has firmly established itself as a framework of choice across multiple projects, we aim to acquaint you with this tool and impart our insights. Terraform’s primary role is to provision infrastructure, thus making the central theme of this blog post revolve around the domains of IT-Administration and DevOps.
In this blog post we want to answer the following questions:
- Why we use Terraform?
- What are the pros and cons?
- Are there some alternatives and how they differ from Terraform?
To get a better understanding of how Terraform works and how to classify it, the first step is to explain some basics and historical further development of IT-Administration.
Progress of Infrastructure Administration
The classical way to implement IT-infrastructure for a business is to order and assemble hardware, install the OS and software and finally configure the interfaces and applications. But because of a dynamic requirement or an evolving technology, the current setup must be changed continuously.
This can lead to multiple challenges:
- Increasing complexity: because of historical growing setup and configuration
- Error-prone processes: Lots of manual work or lack of information
- Unused potential: Idle hardware, forgotten servers or indefinite requirements
- Unclear responsibility: Hard defined responsibilities can have gaps, which could result in unhandled issues
The answer to the increasing complexity was a modularization and standardization of hard- and software components. During time more and more manual work was replaced by automated pipelines and scripts, which reduce possible errors, making it a lot easier to debug issues and speed up the replacement of complete infrastructure parts.
To reduce the unused (hardware) potential, nearly all systems where changed to virtual replicas. A virtual system is just an instance of an abstract definition, which can be switched to other hardware. Or on the other side, a single hardware (Memory, CPU) can be related to multiple system instances.
Cloud, the next step
Today’s cloud technology combines the modularization, standardization, automatization and virtualization and provides services for tasks such as implementing resources or changing configurations. Those services just need a definition of what to implement and hide the entire creation or change process behind an interface.
DevOps merging the responsibilities
Because of this simplification, also user without in-depth administration knowledge can manage infrastructure. A very common example is the developer, which can now define, create and maintenance the platform for its application from its own.
For classical administrators it is more relevant to focus on operation experience like monitoring, backup and recovery or security and less on how to install something, how to manage updates or how to restart a system. They also have to learn common standards of software development to manage the infrastructure definition at repositories with versioning and commits, because of IaC.
Infrastructure as Code (IaC)
With infrastructure as code, the definition of infrastructure resources or configurations is stored in text format (code) as part of a repository. The versioning of a repository allows parallel working (branch or merge changes), easy rollbacks and documenting the entire change history.
As a final step, this infrastructure code gets used to fill the parameters of an interface, which creates or updates the resources of a (cloud) provider.
The next blog post will be all about classification and operating principle at Terraform. You can find it here.
Keep you updated!