A brief history

I once wrote an article that was a little controversial here about why I would choose CDK over terraform. So here is another one relatively around the same topic.

Benefits of pulumi

Much like CDK, pulumi can be used with an actual programming language instead of being restricted to HCL. You can argue that HCL is declarative, and most languages which are meant to write applications, aren’t. That’s valid but also what makes HCL that much more restrictive.

When writing code like this

1
2
3
4
5
6
7
8

resource "aws_instance" "app_server" {
  ami           = "ami-830c94e3"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

it looks very clean and concise compared to…

1
2
3
4
5

const server = new aws.ec2.Instance("webserver-www", {
    instanceType: size,
    vpcSecurityGroupIds: [ group.id ] 
    ami: ami.id,
});

This however allows you to use most, if not all, of typescript. So you can use loops, conditions, classes, etc…

Pulumi also uses terraform in its backend with specific providers. So much of the benefits for terraform can be found on pulumi.

Benefits of terraform

Terraform filled a need where there weren’t any state management sytem for many resources, including cloud providers.

It is /very/ easy to use and it has a wide list of providers it can support.

Cons of pulumi

Documentation isn’t always the best, there are a lot of “todo’s” in the documentation for some of the languages. Although Typescript seems to get first class support there.

Cons of terraform

Because of its declarative restrictions, scaling terraform on a big project can be a bit difficult to manage.

Conclusion

Most of these tools are used by “DevOps” engineers, but the term DevOps came from “developers performing and automating operation processes”. With that in mind, I would have to select pulumi and CDK over terraform. You want something developers are already used to, you don’t want to be restricted by a language, and you want something that is easy to scale.