<commit_before>---
title: 5 things you've heard about Pulumi that aren't true
layout: post
category: blog
tags:
- infrastructure-as-code
- infrastructure-as-software
- pulumi
---

Engaging with the Pulumi community has been one of the most enjoyable parts of my time so far at Pulumi. If you've used the [Pulumi Community Slack](https://slack.pulumi.com/) or asked about Pulumi on [Twitter](https://twitter.com/search?q=pulumi), [Reddit](https://www.reddit.com/user/jaxxstorm/) or [Stack Overflow](https://stackoverflow.com/users/645002/jaxxstorm) there's a reasonable chance interacted with me! 

In the 18 months I've been at Pulumi answering community questions, I've also found that the same topics tend to reappear regularly. 

So why don't we answer some of those questions? I love answering questions, and I haven't written a blog post in a while, so let's get right to it.

## Doesn't Pulumi use Terraform "under the hood" ?

Let's start by asking what "under the hood" actually means? Pulumi does sound like a good name for a car (McLaren Pulumi, anyone?) but I've never understood exactly what people are asking when this question is asked.

This misconception is pretty easy to understand, and it's because Pulumi "bridges" Terraform providers for many popular cloud providers (and perhaps one day, maybe even some [unpopular ones](https://github.com/pulumi/pulumi/issues/6446)). 

### So Pulumi _uses_ Terraform providers?

Well, yes and no. 

When we say Pulumi "bridges" Terraform providers, what we mean is that Pulumi _some_ Pulumi providers use the Terraform schema in order to be able to map the cloud provider API.

In order for Pulumi to be able to create resources in your cloud of choice, Pulumi needs to know what resources are available, what parameters are available on that resources API and what the return and response attributes are. If you've taken a look at one of the major cloud providers recently, you'll notice that there's at _least_ 1 trillion different resources and parameters for those APIs. Mapping the entire surface of the cloud provider itself is going to take a very long time.

Luckily, someone has already done this! The lovely folks at Hashicorp set out building providers for those cloud providers years ago, and like the lovely folks they are, they used a permissive MPL 2.0 license. The maintainers and community using the Terraform providers have already painstakingly mapped the surface area of cloud providers so that the [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) operations needed to create resources are embedded inside the Terraform provider schema.

Pulumi simply reads that schema to understand what those operations need to be. 

Of course, in an ideal world, the cloud providers would have mapped those operations themselves, and many cloud providers _are_ doing just this.

Pulumi builds _native_ providers from the cloud provider APIs, where they're available. If you see `-native` in the name, you can be sure Pulumi is figuring out the CRUD lifecycle of resources directly from the cloud provider.

The actual execution logic, the engine, the CLI and state management are all unique to Pulumi, and differ in large ways from Terraform.

### Summary

Pulumi doesn't "use" Terraform under the hood at all, it uses Terraform _providers_ in order to map the cloud provider API surface. 

## Isn't Pulumi imperative?

_(In the last 10 years of my career, I must have used the word declarative so many times I've lost count, and yet I still have to look up if there's an "e" or an "a" after the "l")_

If you've provisioned infrastructure with other infrastructure as code tooling, you've probably used a DSL that compiles to JSON or used JSON/YAML directly to define your infrastructure. Using those configuration languages means you're defining the end state of your infrastructure, and the intermediate tool drives towards that desired configuration. It's declarative.

When you see Pulumi, with its scary application language workflow, it's easy to panic. 

 -"Hang on a minute, do I have to check if my provisioning operation is successful?" 
 - "Am I going to have to _check errors_?" 
 - I swear to god if I have to use a `try` or `catch` I'm going to quit.

These are all understandable reactions. They are thankfully, premature reactions.

If you were unlucky enough to write a provisioning script at any point in your life, you'll have remembered you have to create a sequence of statements in order to desire your end goal. Take this bash, for example:

```bash
if create_kubernetes_cluster(); then
    echo "Welcome to YAML purgatory, Kubernetes cluster creator"
else
    echo "Congratulations, your Kubernetes cluster failed to create and now you're in actual hell"
fi
```

The fact you have to check for these errors means you're writing imperative code. Defining your creation steps, chaining them in a series of statements and deciding how your program proceeds when things happen is a hallmark of imperative creation and it can be _really_ hard work.

However, Pulumi only uses imperative languages to define your infrastructure, but Pulumi itself is still declarative.
<commit_msg>fix some typos<commit_after>---
title: 5 things you've heard about Pulumi that aren't true
layout: post
category: blog
tags:
- infrastructure-as-code
- infrastructure-as-software
- pulumi
---

Engaging with the Pulumi community has been one of the most enjoyable parts of my time so far at Pulumi. If you've used the [Pulumi Community Slack](https://slack.pulumi.com/) or asked about Pulumi on [Twitter](https://twitter.com/search?q=pulumi), [Reddit](https://www.reddit.com/user/jaxxstorm/) or [Stack Overflow](https://stackoverflow.com/users/645002/jaxxstorm) there's a reasonable chance interacted with me! 

In the 18 months I've been at Pulumi answering community questions, I've also found that the same topics tend to reappear regularly. 

So why don't we answer some of those questions? I love answering questions, and I haven't written a blog post in a while, so let's get right to it.

## Doesn't Pulumi use Terraform "under the hood" ?

Let's start by asking what "under the hood" actually means? Pulumi does sound like a good name for a car (McLaren Pulumi, anyone?) but I've never understood exactly what people are asking when this question is asked.

This misconception is pretty easy to understand, and it's because Pulumi "bridges" Terraform providers for many popular cloud providers (and perhaps one day, maybe even some [unpopular ones](https://github.com/pulumi/pulumi/issues/6446)). 

### So Pulumi _uses_ Terraform providers?

Well, yes and no. 

When we say Pulumi "bridges" Terraform providers, what we mean is that _some_ Pulumi providers use the Terraform schema in order to be able to map the cloud provider API.

In order for Pulumi to be able to create resources in your cloud of choice, Pulumi needs to know what resources are available, what parameters are available on that resources API and what the return and response attributes are. If you've taken a look at one of the major cloud providers recently, you'll notice that there's at _least_ 1 trillion different resources and parameters for those APIs. Mapping the entire surface of the cloud provider itself is going to take a very long time.

Luckily, someone has already done this! The lovely folks at Hashicorp set out building providers for those cloud providers years ago, and like the lovely folks they are, they used a permissive MPL 2.0 license. The maintainers and community using the Terraform providers have already painstakingly mapped the surface area of cloud providers so that the [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) operations needed to create resources are embedded inside the Terraform provider schema.

Pulumi simply reads that schema to understand what those operations need to be. 

Of course, in an ideal world, the cloud providers would have mapped those operations themselves, and many cloud providers _are_ doing just this.

Pulumi builds _native_ providers from the cloud provider APIs, where they're available. If you see `-native` in the name, you can be sure Pulumi is figuring out the CRUD lifecycle of resources directly from the cloud provider.

The actual execution logic, the engine, the CLI and state management are all unique to Pulumi, and differ in large ways from Terraform.

### Summary

Pulumi doesn't "use" Terraform under the hood at all, it uses Terraform _providers_ in order to map the cloud provider API surface.

## Isn't Pulumi imperative?

_(In the last 10 years of my career, I must have used the word declarative so many times I've lost count, and yet I still have to look up if there's an "e" or an "a" after the "l")_

If you've provisioned infrastructure with other infrastructure as code tooling, you've probably used a DSL that compiles to JSON or used JSON/YAML directly to define your infrastructure. Using those configuration languages means you're defining the end state of your infrastructure, and the intermediate tool drives towards that desired configuration. It's declarative.

When you see Pulumi, with its scary application language workflow, it's easy to panic. 

 - "Hang on a minute, do I have to check if my provisioning operation is successful?" 
 - "Am I going to have to _check errors_?" 
 - I swear to god if I have to use a `try` or `catch` I'm going to quit.

These are all understandable reactions. They are thankfully, premature reactions.

If you were unlucky enough to write a provisioning script at any point in your life, you'll have remembered you have to create a sequence of statements in order to desire your end goal. Take this bash, for example:

```bash
if create_kubernetes_cluster(); then
    echo "Welcome to YAML purgatory, Kubernetes cluster creator"
else
    echo "Congratulations, your Kubernetes cluster failed to create and now you're in actual hell"
fi
```

The fact you have to check for these errors means you're writing imperative code. Defining your creation steps, chaining them in a series of statements and deciding how your program proceeds when things happen is a hallmark of imperative creation and it can be _really_ hard work.

However, Pulumi only uses imperative languages to define your infrastructure, but Pulumi itself is still declarative.

{'fraction_non_alphanumeric': 0.049980702431493634, 'fraction_numerical': 0.0034735623311462757, 'mean_word_length': 4.584590517241379, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 12, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4100233', 'n_tokens_mistral': 2685, 'n_tokens_neox': 2554, 'n_words': 1571}