<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Infrastructure as Code on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/categories/infrastructure-as-code/</link>
		<description>Recent content in Infrastructure as Code on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 01 Jun 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/categories/infrastructure-as-code/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Infrastructure as Code Is Software</title>
				<link>https://dplabs.tech/blog/infrastructure-as-code-is-software/</link>
				<pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/infrastructure-as-code-is-software/</guid>
				<description>&lt;p&gt;Infrastructure as Code emerged as a response to the problem of undocumented, inconsistent, manually-managed infrastructure. Click-ops servers where nobody knows what&amp;rsquo;s actually configured. Snowflake environments that differ from production in undocumented ways. Infrastructure that can&amp;rsquo;t be reproduced.&lt;/p&gt;&#xA;&lt;p&gt;IaC solved these problems by treating infrastructure as code. The irony is that many teams write infrastructure code with none of the engineering rigor they apply to application code. No reviews, no tests, no code quality standards, no documentation. The result: IaC that has the same problems as the click-ops it replaced, plus the added complexity of Terraform state files.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Immutable Infrastructure vs Configuration Management: Choosing Your Operations Model</title>
				<link>https://dplabs.tech/blog/immutable-infrastructure/</link>
				<pubDate>Mon, 18 May 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/immutable-infrastructure/</guid>
				<description>&lt;p&gt;Two schools of thought in infrastructure management have different answers to the same question: when the configuration of a server needs to change, what do you do?&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Configuration management&lt;/strong&gt; answer: connect to the server and change it. Tools like Ansible, Puppet, and Chef automate this process.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Immutable infrastructure&lt;/strong&gt; answer: build a new server with the desired configuration, route traffic to it, terminate the old one. The server itself is never modified after provisioning.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Terraform: Modules, State, and the Hidden Complexity</title>
				<link>https://dplabs.tech/blog/terraform-modules-state/</link>
				<pubDate>Mon, 21 Apr 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/terraform-modules-state/</guid>
				<description>&lt;p&gt;Terraform is the dominant infrastructure as code tool for AWS, GCP, and Azure workloads. Getting started is straightforward. Operating it at scale — across multiple teams, environments, and hundreds of resources — surfaces complexity that the getting-started tutorials don&amp;rsquo;t address.&lt;/p&gt;&#xA;&lt;p&gt;This article focuses on the operational lessons: state management, module architecture, and the patterns that keep Terraform manageable as infrastructure grows.&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt;: Terraform is developed by HashiCorp under the BSL license. OpenTofu is the open-source MIT-licensed fork, API-compatible with Terraform 1.5. For teams that require a fully open-source toolchain, OpenTofu is the alternative to evaluate.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
