Today terms such as Agile development, the Cloud, automation, and legacy modernization are hot in the IT sector. This blog talks about how infrastructure as a code (IaC) plays a crucial role in these areas.
Traditionally, Infrastructure setup was a manual and mundane task and generally taken care of by operations team. Being manual it used to be error prone, time consuming and people had to wait until the procurement process would complete. Cloud computing brings in on-demand provisioning concept that wipes out traditional physical procurements cycles and infra can be provisioned on selection of infra config parameters and click of a button. This helped to reduce time for infra provisioning to a great extent. But considering huge competition in market this method also takes quite considerable time as development team is not aware of infra terminologies and what would be the optimum infrastructure for them. Moreover, if teams are working in multiple environments like Dev, QA, Pre-prod, Prod, etc. then every time configuring similar environment is quite painful for Ops team.
To address these issues IaC is a great life saver. Here, infra team could write code that defines detailed configuration of infrastructure to be provisioned. In addition to configuration of infra (e.g., for EC2 what is instance type, instance size, memory, any user data required, etc.), we can define dependencies of various infrastructure components on each other (e.g., Elastic IP cannot be assigned unless EC2 instance is created, or Subnets cannot be defined unless VPC is in place) in this code.
The code can further be made configurable means that the values of certain parameters can change dynamically depending on the target environment we are planning to generate. This code can be reused again and again to generate multiple environments. This will help when we are migrating thousands of legacy applications to new cloud or modern infrastructure in-premises.
Because of IaC developers now Deployments like blue-green and canary - can easily be generated and tested successfully. In Blue-green deployment production like environment is created (green) and then 50% of production traffic is diverted to this environment and performance is monitored. On satisfactory performance all traffic is migrated to a new environment and it is made as blue. In case of failure old environment is rolled back. In case of canary small portion of production traffic is diverted to canary environment and certain parameters are monitored to make certain design decisions. After successful testing canary environment can be deleted.
For IaC there are multiple popular tools available in market as given below,
Based on their way of working they can be categorized into two types i.e., push type and pull type
- In the pull method, the server to be configured will pull its configuration from the server having infrastructure as a code
- In the push method, the server having IaC code pushes the configuration to the destination system
Similarly, IaC is done using either of two approaches viz: declarative (functional) vs. imperative (procedural). The declarative approach upfront defines desired state and then system executes required tasks to achieve that state. Imperative approach defines specific tasks/commands to be performed in pre-defined sequence leading to final state. Following table indicates different tools used for IaC their type, infrastructure they create, the architecture and approach they adopt to achieve that state, and in which language they are developed.
Join the conversation! Your thoughts help the community grow.