Fluent

The idea of populating all clouds with the same templates has remained a pipe dream until now. Although some services offer a compatibility interface for templates from Amazon Web Services (AWS), it being the industry leader, my experience suggests you should not rely on it. Admins are faced with the major dilemma of theoretically having to learn how to use the orchestration tools for various clouds and maintain their own templates (see "The Nebulous Cloud" box). Tools like Terraform (Figure 1) promise to avoid exactly that.

Figure 1: Terraform is considered the top dog when it comes to orchestration, but it comes with its own scripting language. Pulumi, on the other hand, relies on scripting languages that many admins already know.

One relatively new player in the field of these tools is Pulumi. It differs significantly from other tools in that it uses known programming languages instead of its own declarative syntax. So, how does it work, and what does the admin get out of it?

Infrastructure as Code

Pulumi's central promise is infrastructure as code (IaC). Admins provide their virtual infrastructures in the form of code, and Pulumi makes sure that the virtual resources run as desired on the target platform. In itself, this is not a groundbreaking feature, because other multicloud orchestrators like Terraform can do this, too. What Pulumi advertises as a unique killer feature is that it has not invented a new scripting language but relies on proven programming languages. What exactly can admins look forward to?

If you take a look at other solutions (e.g., Terraform), you will see that they use a declarative scripting language. Usually, a markup language such as YAML or JSON lets you define the resources in a single file, which you then hand over to the orchestrator. The orchestrator evaluates the domain-specific language (DSL) file and interprets it accordingly. The disadvantage from the administrator's point of view is that you have to learn and understand the declarative scripting language to work with the program.

Pulumi takes a different tack and instead relies on the syntax of existing scripting languages. For example, if you are familiar with Python (Figure 2), you can package the infrastructure in a Python script. Pulumi provides the appropriate classes for the different cloud providers, which can be imported in the usual way. If you don't work with Python, you have a choice between TypeScript, JavaScript, Go (Figure 3), or C#. Pulumi supports all programming languages from the .NET framework, including VB and F#. Most developers will find a language in this potpourri that suits their taste.

Figure 2: A resource declaration for Pulumi can be written in Python to create a storage account in Azure.

Figure 3: This example performs the same task as the Python example in Figure 2 but is written in Go.

To begin, you load the individual Pulumi modules into your IaC document according to the standard procedures for your choice of scripting language. Pulumi does not force admins to use a special environment for development work. Instead, your standard editor or standard development environment is used, with all the features that are otherwise available.

Nevertheless, Pulumi is a declarative tool. Once you have written your code, you call pulumi up at the command line to start the described infrastructure in the desired environment. In practice, Pulumi tries to balance the declarative approach of classic tools like Terraform with the well-known syntax of common programming languages.

Program, Project, Stack

If you are dealing with Pulumi for the first time, it is best to first familiarize yourself with its programming model. Here, three terms come to mind that need further clarification: the program, the project, and the stack. Each of these three elements has its own task within the Pulumi universe.

What Pulumi means when it refers to a program is more or less all the files that are written in a specific programming language and together form a logical unit. For example, if you write your own Python class for your Pulumi code, it would be part of the program in the Pulumi language.

The project is a little larger. It contains a program and the metadata needed for Pulumi. The pulumi up step assumes that working metadata for the respective program is available, so that Pulumi knows what to do.

Finally, the stack is a concrete incarnation of a project on a cloud platform. The stack state is reached when you have successfully started the infrastructure defined by Pulumi on a cloud platform and can use it.

Working with Pulumi

In theory, the idea behind Pulumi sounds great at first glance. Instead of learning a complex declarative script language, you draw on the skills you already have from working with other programming languages. Indeed, this is one advantage of Pulumi compared with other solutions such as Terraform. However, from the administrator's or developer's point of view, this advantage should not be rated too highly. Even though Pulumi supports the use of well-known programming and scripting languages, you will still need to read a mass of documentation.

The ability to use well-known scripting languages only makes your job easier in the sense that you can work with a familiar syntax. However, if you have a Python program that is intended to start an instance in AWS, you still need to call the appropriate functions to do so. Pulumi does not abstract the cloud APIs from the program so radically at this point that you could rely on uniform commands for different cloud platforms.

In concrete terms, this means that if you want to start a new instance in AWS, for example, you can do so in Go, Java, or one of the other supported scripting languages. However, you do have to deal with how the present task can be solved with the Pulumi modules for the various clouds, and to do so, you need to understand how the Python pulumi_aws module, which provides the corresponding functions, works. Because pulumi_aws is specific to Pulumi, you have to deal with its syntax, which is all the more true if different workloads are to be set up in different environments with Pulumi. Not only do you need to understand how Pulumi's AWS modules work, but also how to use the modules for the other clouds.

To avoid misunderstandings: The Pulumi feature set is clearly oriented to the standards of the market. Other solutions such as Terraform do not fully abstract the respective cloud platform but have different modules for different environments. You have to use these when defining the resources, just as in Pulumi. The only difference is that, in Pulumi, you can use a syntax you already know from your previous work. Whether this really saves as much time as the developers claim in their documentation seems questionable.