Agreed, I don't really see the upside of getting a "proper" programming language for this.
I just got done with a client of mine migrating a considerable amount of infrastructure code that used Troposphere (Python -> CloudFormation) into Terraform 0.12. The old code was very difficult to reason about, had all sorts of inter-related components that caused infrastructure changes to be scary, and really there seemed to be no benefit of being able to write Python for it.
They now have over 100 services in Terraform 0.12 and they feel confident even making network routing changes in prod during the middle of the day with the new system (something that was unheard of before).
I've found it much easier to write declarative configs in Terraform over the years. Back when I was at Engine Yard we used a project called fog to write infrastructure code in Ruby. It was nice for the time (must have been 2012 or so). But again, I really don't think the problem is that I need a programming language to define my infrastructure. I need a way to declare my infrastructure and manage that state so that I know that what I declare is what is running.
I totally can see teams choosing to write infrastructure code in TypeScript, and Go, and Python. And now you have a mess.
The idea is reuse. YAML (and probably Terraform, though I can't speak to it directly) doesn't give you many facilities for reusing blocks of config, especially if they vary subtly in some parameterized way. CloudFormation gives you some reusability in the way of nested-stacks and macros, but it's seriously heavy-handed.
We do use Troposphere in a handful of cases, and it has its own problems, mostly in that it makes it hard to write declarative Python code with it (which is generally what you want--declarative code but with more expressive power than YAML). I have a prototype of an improvement to Troposphere that I built for my own amusement, and I think I'm on to something:
Note that this example is type-safe and declarative while Troposphere is not.
Basically I don't think Troposphere is a good representation of what infrastructure-as-code(-not-yaml) could look like. Not sure about Pulumi as I haven't tried it. But I know the answer isn't YAML, it's not hacking an AST on top of YAML a la CloudFormation, it's not a different static dialect with its own dynamic hacks a la HCL, and it's not generating YAML with text templates a la Helm.
That's what Terraform modules are for. If I need to bundle up things for, say, multiple environments, I can just write it as a module and configure it through the variables I've exposed.
I can't speak to Terraform because I haven't used it, but I'm skeptical that modules are sufficient for many of the same reasons that CloudFormation templates are insufficient. I think at some level you need the ability to programmatically generate arbitrary static configuration, and you end up needing something very like a real programming language to do that.
If you need something very like a real programming language, you should just use a real programming language instead of a tool that accidentally reinvents programming language concepts and the corresponding unnecessary learning curve that that implies for developers. I think the reason these tools are surviving in the "marketplace" is because they market is inexperienced and they conflate "generating static configs (to be passed into a tool that can apply the configs) with an imperative language" with "imperative provisioning of infrastructure". The market sees static/declarative solutions like Terraform and CloudFormation as the only alternatives to "imperative provisioning of infrastructure".
I think as our industry gets more experience and tools for generating YAML/static-configs improve, it will be clear that these are the ways forward.
"I can't speak to Terraform because I haven't used it"
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.
> Well, then maybe you should try it before you decide it doesn't work!
Based on the assumptions I called out about it, it necessarily can't work as well as a general purpose language. I intend to try it to see if my assumptions are correct or not.
> 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.
It's not a hard domain. Developers can write a program that evaluates to YAML--it's not hard. The hard part is applying that YAML to the infrastructure in an efficient way, but programmers don't need to worry about this because Terraform, CloudFormation, Kubectl, etc do it for them.
> 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.
"Learn Ops + HCL" is a bigger learning curve than "learn ops". Notably, learning two things at the same time is a bigger problem than learning them both individually. But you're right that using a standard programming language isn't a substitute for learning how to architect infrastructure--I never said it did--only that it removes the unnecessary complexity and unfamiliarity imposed by HCL.
> 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.
Ha! If the industry hasn't moved past Terraform in 5 years time, it will only be because HCL has adopted enough of the general purpose programming language featureset as to remain competitive. That's certainly its trajectory.
Are you really arguing that deploying and managing infrastructure is not a hard domain? Please. The very existence of tools trying to solve these problems speaks to this difficulty.
I'm going to drop it at this point because it's starting to feel like you're either trolling or have never run a substantial application in production before.
It seems like you’re violently agreeing with me. Like I said, rectifying the infrastructure is the hard part and generating YAML is not. Let the tools do the hard part. They’re good at that. Not so much at the expressiveness and reusability part.
> Ha! If the industry hasn't moved past Terraform in 5 years time, it will only be because HCL has adopted enough of the general purpose programming language featureset as to remain competitive. That's certainly its trajectory.
Quite a statement to make for somebody who has never used Terraform.
Yeah, I meant that Terraform is more rigid with respect to reusability than a general purpose language like Python. This isn't a controversial point; the controversy is whether that's a bug or a feature. I think it's a feature, and to the extent that Terraform is becoming increasingly flexible, I would say I'm vindicated in my position.
I think the person above is mostly pointing out about dynamic blocks , since that do allow abstracting blocks of config and also allow subtle differences
want to point that ever since Terraform 0.12, all terraform params and modules etc are transformable in objects, what I mean by that is you can use functions like yamldecode or jsondecode to decode any yaml or json into terraform objects and pass into modules or resources or locals, also "real" programming language is always funny to me when ops are going to be much more comfortable with HCL. JSON/YAML are not in the same class as HCL. YAML maybe can do nesting with & but they can't just create simple config style interface, where the user facing side is a simple yaml file, and the terraform code underneath take it in and pass it to its modules
> want to point that ever since Terraform 0.12, all terraform params and modules etc are transformable in objects, what I mean by that is you can use functions like yamldecode or jsondecode to decode any yaml or json into terraform objects and pass into modules or resources or locals
This sounds like an important development for Terraform, but it also sounds like it's proving my theory that TF is reinventing a standard programming language badly.
> also "real" programming language is always funny to me when ops are going to be much more comfortable with HCL.
Maybe (and I think it's a big maybe), but if you want to empower developers to do their own ops (read "DevOps"), then HCL is a strict loss over a language they're already familiar with.
> JSON/YAML are not in the same class as HCL. YAML maybe can do nesting with & but they can't just create simple config style interface, where the user facing side is a simple yaml file, and the terraform code underneath take it in and pass it to its modules
Right, as previously mentioned, HCL is accidentally reinventing a programming language. The YAML-based infra-as-code solutions also reinvent programming languages but they build them by building out programming language features on top of YAML (instead of extending the language layer itself) or by generating YAML via text templates. If I had to choose between these, I would pick HCL for sure, but thankfully I can just generate static configs with Python or similar.
I just got done with a client of mine migrating a considerable amount of infrastructure code that used Troposphere (Python -> CloudFormation) into Terraform 0.12. The old code was very difficult to reason about, had all sorts of inter-related components that caused infrastructure changes to be scary, and really there seemed to be no benefit of being able to write Python for it.
They now have over 100 services in Terraform 0.12 and they feel confident even making network routing changes in prod during the middle of the day with the new system (something that was unheard of before).
I've found it much easier to write declarative configs in Terraform over the years. Back when I was at Engine Yard we used a project called fog to write infrastructure code in Ruby. It was nice for the time (must have been 2012 or so). But again, I really don't think the problem is that I need a programming language to define my infrastructure. I need a way to declare my infrastructure and manage that state so that I know that what I declare is what is running.
I totally can see teams choosing to write infrastructure code in TypeScript, and Go, and Python. And now you have a mess.