Why Infrastructure as code?
What does Infrastructure as Code mean?
Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, Kubernetes clusters, etc.) in a descriptive model through codes instead of following manual steps. Like the principle that the same source code generates the same binary, an IaC model generates the same environment every time it is applied. In other words, it is Infrastructure being described using a high-level configuration syntax. This allows you to picture a diagram of your infrastructure to be versioned and treated as you would do with any other code using the same versioning as the DevOps team uses for source code (GitOps). The following Terraform example will create a VPC, a subnet within the VPC, a network interface, and an EC2 instance on AWS:
resource "aws_vpc" "techspire_vpc" {
cidr_block = "172.16.0.0/16"}
resource "aws_subnet" "techspire_subnet" {
vpc_id = aws_vpc.techspire_vpc.id
cidr_block = "172.16.10.0/24"
availability_zone = "eu-west-1a"
tags = {
Name = "tf-techspire-example"
}
}
resource "aws_network_interface" "foobar" {
subnet_id = aws_subnet.techspire_subnet.id
private_ips = ["172.16.10.100"]
tags = {
Name = "primary_network_interface"
}
}
resource "aws_instance" "techspire_test" {
ami = "ami-063d4ab14480ac177" # eu-west-1
instance_type = "t2.micro"
network_interface {
network_interface_id = aws_network_interface.foobar.id
device_index = 0
}
tags = {
Name = "techspire-test-ec2"
}
}
How does it help?
- Agility: No doubt that Infrastructure as code’s first benefit is speed. it helps you to create your infrastructure as fast as possible and even deploy your application on it. You can use the same code for every environment repeatedly, from development to production.
- Repeatability: There are many scenarios and mostly for test and development purposes that you would need to create identical environments from scratch. Infrastructure as Code eliminates the tedious work of creating identical staging environments by automatically initiating your infrastructure. i.e. You have a micro-service structured type of application being deployed on a Kubernetes cluster. To create distinct identical Kubernetes clusters for each stage you need to follow tedious steps and then deploying your application on the created K8S cluster is another challenge. By using IaC, you could easily create and manage multiple identical K8S clusters and then deploy the application on them. In addition, when your test is finished or you don’t need that cluster anymore, you can destroy all created infrastructure with a single command.
- Stability and consistency: Having your infrastructure being managed by a declarative language that describes the desired state of your infrastructure minimizes the manual human change’s errors and increases the fault tolerantly of your infrastructure. i.e. If someone by a mistake deletes an EC2 instance or someone with access to the K8S cluster deletes a wrong namespace, by running the IaC code again it reforms the desired state for you. It also helps you with minimizing the time to recover from infrastructure failures and makes disaster recovery procedures much easier.
- Auditability: Like any other source code files, you can manage and versioning the IaC source code. Also, it grants you the benefit of managing your desired state with a single source of truth repository(GitOps).
- Security: By having Git and your IaC code as a single source of truth for your infrastructure, every change should come from that specific set of files. Therefore, whoever can push to that repository has access to change your infrastructure. Also, by passing all the secure data within the IaC code, no one outside the IaC configuration could change and access sensitive resources.
- Integrity: Implementing IaC has the benefit of integrity in many cases. For instance, let’s get back to our Micro-service architected example deployed on K8S. Assume that we want to create the K8S cluster on GCP. As you can see in the following code, in a K8S cluster module, we are creating the GKE cluster and pass sensitive data to the application deployment module. Therefore, by using IaC, we are able to create the underlying infrastructure and also deploy the application.
# GKE module
resource "google_container_cluster" "techspire_cluster" {
name = "techspire_cluster"
location = var.region
initial_node_count = 1
network = var.network
subnetwork = var.subnetwork
}
output "host" {
value = google_container_cluster.techspire_cluster.endpoint
sensitive = false
}
output "client_key" {
value = google_container_cluster.techspire_cluster.master_auth.0.client_key
sensitive = true
}--------provider "kubernetes" {
host = module.gke.host
client_key = base64decode(module.gke.client_key)
}
resource "kubernetes_namespace" "namespace" {
metadata {
name = "techspire_test_namespace"
}
}
How we can have a more collaborative infrastructure as code model?
As I mentioned in the integrity part, by using IaC tools you can use the same workflow to provision resources on most of the providers. You might have heard about multi-cloud architecture. Using the same tool to declare infrastructure as code is capable of regulating the complex relationships between infrastructure resources on different providers(clouds), and then sequentially create, modify, and even destroy resources on providers.
- Complex infrastructures require more expert teams to manage, scale, and maintain them. To define a better way of working together on complex infrastructures, we have to create a well-delegated model and assign each set of resources to the proper team without any conflicts and manage audits. For instance, in a complex multi-cloud implementation, a team could be in charge of AWS resources and the other manage Azure ones, and another team manages relations and connections.
Infrastructure service mesh design?
Using IaC also helps with the benefit of implementing a well-architected service mesh design. How? Implementing various linked services with diverse types of infrastructures creates a complex service mesh(service-to-service communication). By using IaC, you can also manage services connection points and how they would be connected together. Assume that you have a couple of connected services naming S1, S2, S3… IaC creates each service’s relevant infrastructure in a separate module. By calling them in the root code, you can manage inter-service communications with better visibility and more securely.
Who am I?
I am a passionate site reliability engineer and a cloud solutions architect working for Techspire Netherlands and dedicated to assisting businesses smoothing out their System Engineering and Security Operations, improving availability, scalability, and QoS for their services using infrastructure as code concepts, a wide range of monitoring and logging tools, digging into Linux based operating systems, using my deep knowledge in Network concepts and big-data analytical tools.
See all Techspire blogs?
Originally published at https://techspire.nl on June 8, 2021.
