- A Go AWS SDK example - Fri, Nov 11 2022
- Getting started with Jenkins - Tue, Aug 16 2022
- Pulumi vs. Terraform - Tue, Jul 5 2022
Programming language
Both Pulumi and Terrform allow you to use programming languages to build infrastructure as code. When we use a programming language for infrastructure deployment, we can take advantage of the software tool chain to perform static tests that are not possible with templating languages.
We can also perform unit tests and property tests without deploying infrastructure by using mocks and policies. Programming languages provide the power of loops, conditions, functions, classes, and more when building out your infrastructure.
Pulumi uses the world's most popular programming languages (TypeScript, Go, .NET, Python, and Java), and as of May 2022 has added the markup languages of YAML and CUE.
In contrast, Terraform uses a domain-specific language (DSL) known as HashiCorp Configuration Language (HCL) to write, plan, and apply changes to deliver infrastructure as code.
Working with IDEs
When it comes to writing our Infrastructure as Code, we look to use an integrated development environment, or IDE. When it comes to Terraform, the number of available plugins for some of these popular IDEs is limited. This is certainly a drawback when using a DSL.
In contrast, with Pulumi, you can use programming languages to tap into many years of developed tooling for your favorite language. Full IDE support provides code completion, strong typing, error squiggles, version control, and much more!
Abstraction
IaC solutions hide the complexity of the interfaces of various cloud providers by abstracting from the implementation details of comparable resources and offering a common interface for the management of these resources.
Pulumi's Component Resources takes this concept one step further by grouping related resources, thereby creating a higher level of abstraction. For instance, you can group virtual machines that share certain properties and interact with these multiple VMs as if they were one single, reusable resource.
Another simple example of a component resource could be a custom S3 bucket with your own lifecycle rule and bucket policy. You can build all of this as a single resource. The Component Resource bucket could be your standard, which is now easily repeatable.
Terraform requires you to use its own DSL which involves the more complex approach of module creation to achieve a similar level of abstraction.
Testing
A typical component in a CI/CD pipeline is the testing phase. Terraform supports integration testing, whereas Pulumi, with its use of general-purpose languages, has many more options.
General-purpose programming languages come with their own frameworks to perform automated testing of our infrastructure. If you need to test individual pieces with unit testing, system components with integration testing, or complete end-to-end testing, then Pulumi has you covered.
Automation API
Pulumi provides an additional mode of execution over the CLI though the Automation API. The Automation API allows you to add Pulumi to your application code. This opens up a host of innovative ideas, such as self-service infrastructure portals, custom CLIs, and richer CI/CD workflows.
Pulumi provides APIs to interact with
Security
Security is high on most people's agendas today. Pulumi protects your state files and the encryption of sensitive values, which can include passwords, tokens, and credential files. Encryption is also applied to secrets that are in transit and at rest. Should your secret be part of a log, state file, or CLI output, Pulumi has you covered by encrypting these as well.
Terraform uses Vault, a separate product, to manage secrets and protect sensitive data. In addition to having to manage an additional product, when Terraform pulls secrets from the vault, you have the issue of the state file not being encrypted and secrets being displayed in plaintext.
Extensibility
Pulumi's extensibility is impressive. Its Dynamic Providers feature allows you to write your own custom resource types.
You might be wondering why you would need such a feature. Well, there might be a time when a certain provider doesn't provide you with the functionality you require, or you want to write a custom provider to interact with something unique, such as creating a provisioner.
Moving from Terraform to Pulumi
If where you work has been using Terraform or even CloudFormation, and you want to consider Pulumi as your Infrastructure as Code tool, then consider this handy feature: Pulumi can convert your Terraform and CloudFormation code into Pulumi in your favorite language!
Pulumi provides a handy online conversion. To demonstrate this, I've used the example provided for conversion to Go:
Convert Terraform to Pulumi
The tool tf2pulumi is open source, which you can also download to run against a more complex example.
Summary
This is by no means a complete list of differences between the two IaC tools, but it does demonstrate Pulumi as a strong competitor. The use of general-purpose languages gives you concise, clean, reusable code that a DSL cannot provide. Interestingly, HashiCorp seems to feel the same, as it has created a similar feature in Terraform CDK.
Subscribe to 4sysops newsletter!
Pulumi has come a long way in a short period of time. Since the version 3.0 release last year, it is currently on version 3.35. Pulumi is continuing to innovate and recently announced support for Java and two markup languages in YAML and Cue. The markup languages are there to help customers who are used to these languages to onboard quicker with more straightforward developments. However, the real power comes with the use of programming languages, which allows more complex and modularized deployments.
Wow… that was a very impressive article.
I have just under 50 years in the computer business, and it all went over my head.
My last employed position was doing PowerShell automation for system deployment.
After reading the above, I see just how much the world has moved on.
Kudos to those who can, and do, work in the above environment.
I’m glad to be retired now.
If you have been working in IT for such a long time, you probably know that this all is not really new. What many don’t know is that teenage Bill Gates started his IT career as a “devops engineer” writing and managing code on mainframes. In these times, companies had to write their own code because nobody would sell it to them. Dev and ops were just the same thing. Then Micro-Soft (as it was spelled at that time) created the software market and dev and ops were separated.
In the cloud, we have now the same situation as previously on mainframes. Companies like Netflix had to write their own code because nobody would sell them the software needed for a streaming company and devops was born. But as more streaming companies pop up, it is only a matter of time until someone will offer this kind software on the market and even Netflix might then separate dev and ops once again simply because it is cheaper to automate by buying software instead of “manually” writing all the code by yourself.
Of course, many new fascinating technologies have been invented since the mainframe era, IaC being one of them. Thus, if you don’t already live in a nursing home, suffering from dementia, I recommend staying involved simply because it is more fun to code than feeding ducks and waisting time on Netflix. Being retired is really no excuse.
There are some great plugins for Terraform, I use the Pycharms on every day: code completion, refactoring support, colour coding etc.