Pulumi – Modern Infrastructure as Code

The issue is that your static configs often have lots of boilerplate sections that have to be kept in sync. Further, you can use an imperative language like Python, JS, etc and still write in a completely declarative fashion (or you can use a functional language which tend to be declarative out of the box). Conversely, you can model an AST in YAML (which is what CloudFormation is trending toward) and get the worst of all worlds. Bottom line: don't conflate "reusability" with "imperative" or "static" with "declarative".

Then again, code has to be run in order to analyze its output -- that or code has to be data you can analyze (like a Lisp), but that can be very difficult to reason about.

So my preference would be to have libraries for constructing configuration data. Then you can execute a program to generate the configuration, and that you can use without further ado. The output may not be easy for a human to understand, though it should be possible to write code to analyze it.

1) The project does support config. So if you want to change (e.g.) the number of AZs, you can say

    $ pulumi config set numberOfAvailabilityZones 3
    $ pulumi up

2) You can make this into a library using standard language techniques like classes, functions, and packages. These can use a combination of configuration as well as parameterization. If you wrote it in Python, you can publish it on PyPI, or JavaScript on NPM, or Go on GitHub -- or something like JFrog Artifactory for any of them. This makes it easy to share it with the community or within your team.

3) We offer some libraries of our own, like this one: https://github.com/pulumi/pulumi-awsx/tree/master/nodejs/aws.... That includes an abstraction that's a lot like the Terraform module you've shown, and cuts down even further on LOC to spin up a properly configured VPC.

I am a big Go fan too, so I very much know what you're saying. (In fact, we implemented Pulumi in Go.) Even with Go, though, you've got funcs, structs, loops, and solid basics. Simply having those goes a long way -- as well as great supporting tools -- and you definitely do not need to go overboard with abstraction to get a ton of benefit right out of the gate.

Again, I'm biased and YMMV :-)

The reality is that all programming languages have significant copy paste codebases using them, but there are features which help reduce the amount of it. Terraform is missing some of those features, and many of the features it does have were introduced in tf 12, which is less than a year old.

Well, the problem is that a majority of people don't want to / don't have the time to learn HCL, because it's not the most effective use of their time / not worth the "investment" to do so.

Learning HCL is not very rewarding, unless you are an ops person. Learning a general purpose language language like Python, TypeScript or whatever language your company uses is rewarding both for ops and dev people (or devops people if you like that term) and typically can be used for a much wider set of use-cases.

When introducing a new language the pros and cons of doing so should always be carefully considered, however unfortunately for devops tools new languages like HCL,Jsonnet,Starlark,zillions of YAML pseudo-programming DSLs etc. are often introduced very lightly, mentioning a handful of use cases where the new language shines, but ignoring the cons and intrinsic costs (learning curve, new tools, editor integrations, package manager etc. to be built).

Terraform works great for teams where you have a strict separation between ops and dev people. The ops people will spend their time learning HCL, the dev people will learn Python, TypeScript or whatever that is. However if you are trying to truly embrace a "DevOps" model Terraform shows its flaws. Developers will either still heavily rely on ops people to "help them" even for trivial infra changes or they will write sub-par copy pasta HCL code that tends to be verbose.

TF 0.12 may have a bunch of new constructs which make it easier to reduce duplication, but the boilerplate that is required to create an actual reuse module with variables and import it (and overall awkwardness of the module system/syntax compared to any other language) vs the simplicity of creating a reuse function/file in Python/TS is like night and day. Furthermore the subpar editor support for TF makes it actually hard to follow references between modules and safely refactor code, so there is a much lower threshold at which an abstraction appears "magic"/incomprehensible in HCL, compared to typed TS/Python where you can easily follow references.

Source: ~2 years worth of Terraform (incl. 0.12) and ~1 years worth of Pulumi use within multiple companies and teams.

Yeah, it seems a bit silly to say that a benefit is saved lines of code, yet the Terraform example is setup to do quite a lot more than the Pulumi example. The resources are just there and turned off with the "count" configuration. The Pulumi example isn't doing any of the RDS, Redshift, Elasticache, Database ACL, VPN gateway, etc things. This example is a pretty substantial module and I'd guess the LOC would be pretty similar between the two if the functionality were closer.

You'll have to articulate your said benefits to be sure, but I would wager that the principle reason to be turing incomplete is to address the halting problem and that the benefits you're thinking about come from other properties of the language (functional purity, immutability, limitations on I/O, type safety where applicable, etc).

Notably, there are lots of hacky workarounds employed in HCL and YAML because people don't understand the problem properly. The problem requires that we can generate arbitrary static configuration from a fixed set of inputs. If your organization is so inept that they keep adding in infinite loops and/or I/O, then by all means, try something like Dhall or Starlark (unfamiliar vs not-type-safe, pick your poison); however, if this is a consistent problem in your organization you probably need to replace your humans because these programs aren't hard to write correctly.

> Or don't do static configuration and just use something like Terraform where you can just reference a resource and pass it around.

Because this only addresses reuse at the resource level. You can do the same thing in CloudFormation; it's not adequate. For example, not everything is a resource. You ultimately need the ability to generate arbitrary static configuration. Terraform probably has lots of other disparate features that collectively address a good portion of the solution space, but programming languages have a unified concept ("functions") that satisfy the whole solution space and programmers are already familiar with them. Terraform's job should be taking static configs and applying them to infrastructure--let a real programming language generate those configs, or at least offer dynamic configuration language that is designed with a proper understanding of the problem (to use your words).

Well, then maybe you should try it before you decide it doesn't work! I'll definitely be giving Pulumi a try, but honestly Terraform works really well and I'm happy using it.

It's a nice idea to be able to have a programming language you're familiar with available to do infra work, but deploying and managing infrastructure is a totally different problem domain than writing an application. If the concern is letting developers that don't have much ops experience architect an infrastructure, or you have recent graduates that "don't know HCL", then you have quite a higher learning curve than you actually think you do.

I've never once thought "I really wish I could just use TypeScript for configuring my infrastructure". If that's you, great! Call me when you hit scale and your ops team needs to refactor it.

The simplest is if you start renaming modules or moving resources in and out of different modules. Terraform will get confused and try to destroy everything rather than modify in place, even though it's the same resource, or it will sometimes just fail altogether, like it's trying to resolve some module that used to exist but no longer exists. Basically it doesn't comprehend that its logical resources are really real-world things, and leans so heavily on its logical mapping (based on things like module inheritance, which is a Terraform logic thing, not a real-world AWS resource thing) that it often just becomes unusable, and you have to perform heroics of moving about pieces of code and importing various things to work around it, if it works at all.

The bigger problem is when you have a resource which might be associated with another resource, like the various ways to represent IAM policies and roles in terraform resources. You can create the resource one way and deploy it, and then maybe someone modifies the existing real-world resource in a way that now depends on some other resource... but that resource isn't in a Terraform file. Terraform doesn't know what to do, so it will either clobber the modified state, or just die because it doesn't know how to resolve the conflict.

I would need to go back and curate a list of all the times that Terraform has just failed to do anything because something changed that it didn't expect, but basically it refuses to "fix" things that are unexpected. That, and the lack of automatic importing of existing resources is just absurd.... If Terraformer can make it work, Terraform could have too.