Answers: <p>Before explaining what it exactly is, let me quote a really nice definition, straight <a href="https://en.wikipedia.org/wiki/Infrastructure_as_Code" rel="nofollow noreferrer">from Wikipedia</a>:</p>
  <blockquote>
  <p>Infrastructure as Code (IaC) is the process of managing and
  provisioning computing infrastructure (processes, bare-metal servers,
  virtual servers, etc.) and their configuration through
  machine-processable definition files, rather than physical hardware
  configuration or the use of interactive configuration tools.</p>
  </blockquote>
  <p>Okay, now let's look at one such IaC tool, <a href="https://www.terraform.io/" rel="nofollow noreferrer">Terraform</a> to understand the concept better:</p>
  <p>Also, this is what Terraform say about itself:</p>
  <blockquote>
  <p>Terraform enables you to safely and predictably create, change, and
  improve production infrastructure. It is an open source tool that
  codifies APIs into declarative configuration files that can be shared
  amongst team members, treated as code, edited, reviewed, and
  versioned.</p>
  </blockquote>
  <p>This means, one can code the entire infra. which includes creation of cloud(/infra) resources like the server instances, load balancers, etc, along with the complete configurations (which includes the basic settings tweaks, security settings, regions, etc) as code, which can be editable, versionable and of course, reviewable.</p>
  <p>This is a sample example of Terraform code for provisioning AWS resources:</p>
  <pre><code>resource &quot;aws_elb&quot; &quot;frontend&quot; {
    name = &quot;frontend-load-balancer&quot;
    listener {
      instance_port     = 8000
      instance_protocol = &quot;http&quot;
      lb_port           = 80
      lb_protocol       = &quot;http&quot;
    }
   
    instances = [&quot;${aws_instance.app.*.id}&quot;]
  }
   
  resource &quot;aws_instance&quot; &quot;app&quot; {
    count = 5
   
    ami           = &quot;ami-408c7f28&quot;
    instance_type = &quot;t1.micro&quot;
  }
  </code></pre>
  <p><strong>Bonus PS</strong>: Also, one needs to understand the differences between <a href="https://en.wikipedia.org/wiki/Provisioning" rel="nofollow noreferrer">provisioning</a> and <a href="https://en.wikipedia.org/wiki/Orchestration_(computing)" rel="nofollow noreferrer">orchestration</a> tools. Devs confuse one for the other very often and tend to make the mistake of trying to tweak and use a tool for what it is not intended to be used for.</p>
  
Answers: CC BY-SA 4.0
Answers: 2017-03-18T03:51:44.400Z
Answers: 2023-06-23T11:38:08.313Z
Answers: 2023-06-23T11:38:08.313Z
Answers: Dawny33
Answers: <p><strong>TL;DR</strong>: <a href="https://en.wikipedia.org/wiki/Infrastructure_as_Code" rel="noreferrer">Infrastructure as Code</a> is a way to automate and backup your environment. In ideal case, after a disaster, you <em>could restore</em> your Infrastructure <em>fully and automatically</em> by Provisioning new resources, Restoring Configuration from Code Repository and Recovering Data from Backup.</p>
  
  <h2>Overview</h2>
  
  <p>Infrastructure as Code relies on three main concepts:</p>
  
  <ul>
  <li><p>Automation of <a href="https://en.wikipedia.org/wiki/Configuration_management" rel="noreferrer">Configuration Management</a>, called <a href="https://en.wikipedia.org/wiki/Continuous_configuration_automation" rel="noreferrer">Continuous Configuration Automation</a> a field pioneered by prof. <a href="https://en.wikipedia.org/wiki/Mark_Burgess_(computer_scientist)" rel="noreferrer">Mark Burgess</a></p></li>
  <li><p><a href="https://en.wikipedia.org/wiki/Version_control" rel="noreferrer">Code Repository</a> for changes to Infrastructure, where changes are first committed, documented, reviewed, <a href="https://devops.com/agile-infrastructure-infrastructure-deserves-tests/" rel="noreferrer">tested</a> and then deployed through automation.</p></li>
  <li><p><a href="https://www-935.ibm.com/services/us/en/it-services/server-services/integrated-managed-infrastructure-services/index.html#solutions" rel="noreferrer">Managed Infrastructure</a> Provisioning. <a href="http://www.gartner.com/it-glossary/infrastructure-as-a-service-iaas/" rel="noreferrer">Infrastructure as a Service</a> (IaaS). Either through <a href="https://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29" rel="noreferrer">Cloud Computing</a>, <a href="https://www.oracle.com/cloud/iaas.html" rel="noreferrer">Private or Managed Cloud</a> or Managed <a href="http://www.wipro.com/services/infrastructure-services/services/data-center-services/" rel="noreferrer">Datacenter Services</a>  </p></li>
  </ul>
  
  <h3>Automation</h3>
  
  <p>Configuration Management is in its 3rd generation of tools. Building on CFEngine a new set of tools for Automated Configuration Management is being widely deployed now. The most popular in alphabetical order are <em>Ansible, CFEngine, Chef, Puppet, PowerShell DSC and SaltStack</em>. Each will have a <strong>Language</strong> to describe state of your infrastructure, <strong>Code Modules</strong> to apply those changes and provide ability to extend the tools, some <strong>Agent</strong> to execute those on the servers and a <strong>Central Repository</strong> of information.</p>
  
  <p>They will generally operate in push or pull mode, either connecting to servers from a central location(s) and executing changes remotely or running on each server and pulling information about state from central location and that either in client/server model or in a distributed way.</p>
  
  <p>The <strong>important concept</strong> is for the system administrator or site reliability engineer to <strong>not make changes directly</strong> to the infrastructure, but let the automation do changes. Anything <strong>done manually by a human</strong> should be considered either perishable, being soon corrected back by automation or in stricter form <strong>violating the integrity</strong> of the infrastructure and triggering destruction and rebuild of the affected components.</p>
  
  <h3>Code Repository</h3>
  
  <p>Code Repository, ideally separate from Repository holding Software, would be used to manage all changes to the Infrastructure and related Automation. It should hold Configuration files and templates, Playbooks (Cookbooks) describing process of changes to be reviewed, Code extending the CM automation tools, Provisioning configurations, Infrastructure Tests and Alerts, Staging/Deployment Tests, Documentation, Manual (not yet automated) Process Descriptions.</p>
  
  <p>The important concept is to institute peer reviews for changes, to have record of all changes and ability to automatically revert to previous state in case of unpredictable and/or untested issues, ability to deploy to staging environment and test configuration changes and ability to automatically deploy changes without variation caused by human error.  </p>
  
  <h3>Managed Infrastructure</h3>
  
  <p>Managing Physical Infrastructure is a real world task that goes beyond software and requires very different set of skills. By being able to abstract this layer through Cloud Computing or a Managed Datacenter, you have your team focus on the part of managing Infrastructure that adds business value. </p>
  
  <p>While Cloud Computing offers a way to start and scale quickly at a later stage companies often realize some benefits and even significant savings in moving parts of the Infrastructure in their own data centers for a hybrid model. Owning or renting the hardware does not mean that you also have to employ the people who handle it. At this scale you need data centers geographically distributed around the world and having people with all the required skills in all places would be very expensive. Flying them around the world adds high latency to any changes and additional level of operational inefficiencies, which is another reason for outsourcing the datacenter management.</p>
  
  <p>The important takeaway is that <strong>Managed Physical Infrastructure</strong> is often forgotten or <strong>overlooked concept</strong>, but just as important. Even if you've got everything automated, all configuration stored in a backed up code repository, unless you have a way to <strong>quickly provision</strong>, you have a <strong>huge bottleneck</strong>, which could easily <strong>erase all the benefits</strong> you've gained by the other two steps.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-18T05:16:11.697Z
Answers: 2017-03-18T05:16:11.697Z
Answers: Jiri Klouda
Body: <p>The phrase "Infrastructure as Code" has been mentioned several times in the last two weeks in different contexts.  What does it actually mean in a practical sense to have Infrastructure as Code?</p>
  
Tags: <terminology><culture><infrastructure-as-code>
Title: What is "Infrastructure as Code"?
UserDisplayName: Richard Slater
ThreadText: # What is "Infrastructure as Code"?
  
  (Asked by: username_0 on 2017-03-17)
  
  The phrase "Infrastructure as Code" has been mentioned several times in the last two weeks in different contexts. What does it actually mean in a practical sense to have Infrastructure as Code?
  
  **Tags:** terminology, culture, infrastructure-as-code
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-03-18. Score: 12 | Accepted answer
  
  **TL;DR**: [Infrastructure as Code](https://en.wikipedia.org/wiki/Infrastructure_as_Code) is a way to automate and backup your environment. In ideal case, after a disaster, you *could restore* your Infrastructure *fully and automatically* by Provisioning new resources, Restoring Configuration from Code Repository and Recovering Data from Backup.
  
  ## Overview
  
  Infrastructure as Code relies on three main concepts:
  
  * Automation of [Configuration Management](https://en.wikipedia.org/wiki/Configuration_management), called [Continuous Configuration Automation](https://en.wikipedia.org/wiki/Continuous_configuration_automation) a field pioneered by prof. [Mark Burgess](https://en.wikipedia.org/wiki/Mark_Burgess_(computer_scientist))
  * [Code Repository](https://en.wikipedia.org/wiki/Version_control) for changes to Infrastructure, where changes are first committed, documented, reviewed, [tested](https://devops.com/agile-infrastructure-infrastructure-deserves-tests/) and then deployed through automation.
  * [Managed Infrastructure](https://www-935.ibm.com/services/us/en/it-services/server-services/integrated-managed-infrastructure-services/index.html#solutions) Provisioning. [Infrastructure as a Service](http://www.gartner.com/it-glossary/infrastructure-as-a-service-iaas/) (IaaS). Either through [Cloud Computing](https://en.wikipedia.org/wiki/Cloud_computing#Infrastructure_as_a_service_.28IaaS.29), [Private or Managed Cloud](https://www.oracle.com/cloud/iaas.html) or Managed [Datacenter Services](http://www.wipro.com/services/infrastructure-services/services/data-center-services/)
  
  ### Automation
  
  Configuration Management is in its 3rd generation of tools. Building on CFEngine a new set of tools for Automated Configuration Management is being widely deployed now. The most popular in alphabetical order are *Ansible, CFEngine, Chef, Puppet, PowerShell DSC and SaltStack*. Each will have a **Language** to describe state of your infrastructure, **Code Modules** to apply those changes and provide ability to extend the tools, some **Agent** to execute those on the servers and a **Central Repository** of information.
  
  They will generally operate in push or pull mode, either connecting to servers from a central location(s) and executing changes remotely or running on each server and pulling information about state from central location and that either in client/server model or in a distributed way.
  
  The **important concept** is for the system administrator or site reliability engineer to **not make changes directly** to the infrastructure, but let the automation do changes. Anything **done manually by a human** should be considered either perishable, being soon corrected back by automation or in stricter form **violating the integrity** of the infrastructure and triggering destruction and rebuild of the affected components.
  
  ### Code Repository
  
  Code Repository, ideally separate from Repository holding Software, would be used to manage all changes to the Infrastructure and related Automation. It should hold Configuration files and templates, Playbooks (Cookbooks) describing process of changes to be reviewed, Code extending the CM automation tools, Provisioning configurations, Infrastructure Tests and Alerts, Staging/Deployment Tests, Documentation, Manual (not yet automated) Process Descriptions.
  
  The important concept is to institute peer reviews for changes, to have record of all changes and ability to automatically revert to previous state in case of unpredictable and/or untested issues, ability to deploy to staging environment and test configuration changes and ability to automatically deploy changes without variation caused by human error.
  
  ### Managed Infrastructure
  
  Managing Physical Infrastructure is a real world task that goes beyond software and requires very different set of skills. By being able to abstract this layer through Cloud Computing or a Managed Datacenter, you have your team focus on the part of managing Infrastructure that adds business value.
  
  While Cloud Computing offers a way to start and scale quickly at a later stage companies often realize some benefits and even significant savings in moving parts of the Infrastructure in their own data centers for a hybrid model. Owning or renting the hardware does not mean that you also have to employ the people who handle it. At this scale you need data centers geographically distributed around the world and having people with all the required skills in all places would be very expensive. Flying them around the world adds high latency to any changes and additional level of operational inefficiencies, which is another reason for outsourcing the datacenter management.
  
  The important takeaway is that **Managed Physical Infrastructure** is often forgotten or **overlooked concept**, but just as important. Even if you've got everything automated, all configuration stored in a backed up code repository, unless you have a way to **quickly provision**, you have a **huge bottleneck**, which could easily **erase all the benefits** you've gained by the other two steps.
  
  
  ---
  
  ### Answer by username_1 on 2017-03-18. Score: 6
  
  Before explaining what it exactly is, let me quote a really nice definition, straight [from Wikipedia](https://en.wikipedia.org/wiki/Infrastructure_as_Code):
  
  > Infrastructure as Code (IaC) is the process of managing and
  > provisioning computing infrastructure (processes, bare-metal servers,
  > virtual servers, etc.) and their configuration through
  > machine-processable definition files, rather than physical hardware
  > configuration or the use of interactive configuration tools.
  
  Okay, now let's look at one such IaC tool, [Terraform](https://www.terraform.io/) to understand the concept better:
  
  Also, this is what Terraform say about itself:
  
  > Terraform enables you to safely and predictably create, change, and
  > improve production infrastructure. It is an open source tool that
  > codifies APIs into declarative configuration files that can be shared
  > amongst team members, treated as code, edited, reviewed, and
  > versioned.
  
  This means, one can code the entire infra. which includes creation of cloud(/infra) resources like the server instances, load balancers, etc, along with the complete configurations (which includes the basic settings tweaks, security settings, regions, etc) as code, which can be editable, versionable and of course, reviewable.
  
  This is a sample example of Terraform code for provisioning AWS resources:
  
  ```
  resource "aws_elb" "frontend" {
    name = "frontend-load-balancer"
    listener {
      instance_port     = 8000
      instance_protocol = "http"
      lb_port           = 80
      lb_protocol       = "http"
    }
   
    instances = ["${aws_instance.app.*.id}"]
  }
   
  resource "aws_instance" "app" {
    count = 5
   
    ami           = "ami-408c7f28"
    instance_type = "t1.micro"
  }
  
  ```
  
  **Bonus PS**: Also, one needs to understand the differences between [provisioning](https://en.wikipedia.org/wiki/Provisioning) and [orchestration](https://en.wikipedia.org/wiki/Orchestration_(computing)) tools. Devs confuse one for the other very often and tend to make the mistake of trying to tweak and use a tool for what it is not intended to be used for.
  
  
  ---
  
  