Declarative vs Imperative IaC: Infrastructure as Code

IaC approaches declarative and imperative works in slightly different manner. The declarative approach aims to define the desired state of the system, properties it should possess and resources required. Imperative approach defines specific commands which let you achieve the desired state of systems and infrastructure. 

Deploying infrastructure on demand without any issues could be a big challenge for larger enterprises. As the digital IT landscape grows, deployment vows multifold. Infrastructure as a code (IaC) deals in managing deployment or provisioning of infrastructure using a code instead of manual. 

With IaC configuration files are created with specific infrastructure related settings which makes it easier to edit and distribute configurations uniformly across systems. It ensures provisioning is uniform and the same every time. By documenting and coding configuration specifics to infrastructure IaC helps in configuration management and reduction in Adhoc configurations.

In today’s article we will understand the difference between IaC declarative and imperative approaches, their key differences and how to use them. 

What is Declarative IaC

A declarative approach defines what you want your infrastructure – define the outcome. For example, you need a virtual machine with x specification’s, x memory, x number of CPUs, HA database with geo redundancy and tools to figure out what system to design here. This is just like setting a destination on a map and route is chosen by the navigation or GPS system on its own. Some known IaC tools which use declarative approach are Terraform, Puppet, Ansible, CloudFormation and Salt. 

What is Imperative IaC

In an imperative IaC approach every single step is written down which needs to be executed to have a desired outcome – system or infrastructure as you wanted it to build or change your environment. This approach is about more control on the overall IaC process and you are responsible to handle errors, sequencing and state tracking. Some known IaC tools which use imperative approach are chef. Both Ansible and Salt support an imperative approach to some extent. 

However, most IaC tools available in the market are designed keeping in mind a declarative approach as it is easier to maintain and it is less prone to configuration issues. Also it is easily integrated with automation tools which are meant to identify any mismatches between current and desired state of infrastructure and fix them automatically. 

Comparison: Declarative vs Imperative IaC

Features	Declarative IaC	Imperative IaC
Coding skills	Requires little knowledge of coding skills	Require more coding skills as manually each step needs to be defined
Nature of deployment	Ideal for voluminous and repetitive setups	Ideal for small simple one off tasks
Configuration drifts	Reduction in configuration issues near to zero	Requires step by step carefully crafted approach to avoid configuration issues
Control	DevOps engineer has very little control over overall process	DevOps engineer has full control over overall process
Use cases	Predicable, repeatable infrastructure setups  Simple and scalable infrastructure setups	Full control over infrastructure provisioning is required  Complex and fine-grained control requirement
Features	Reduced scripting requirements	Ideal for small deployments
Maintenance	It is easy to maintain and can be automated using IaC tools	It is difficult to maintain
Human error	Human error risk is lower due to automated configurations states	Chances of human error are higher due to manual steps
Example code	Defining an EC2 instance  Instance_type = t1.test	Aws ec2 run-instances  Instance_type t1.test

Download the comparison table: Declarative vs Imperative Iac

To Summarize

Declarative IaC describes the desired end state of infrastructure (what) and lets the tool determine the steps to achieve it, enabling idempotence and easier drift correction. Imperative IaC specifies exact commands or procedures (how) to perform changes, offering fine-grained control but more complexity and potential for non-idempotent outcomes.

Related FAQs