I think we somehow missed to consider two desirable properties of configuration systems that are nevertheless orthogonal: being declarative (which Excel, Terraform, Prolog mostly are) and being Turing-complete (which every Turing-complete programming language is, by definition). If we consider both properties, one can see that there is no hope Prolog is the answer.
Thats how Mark Burgess started (Prolog) and ended up with cfengine. I’d say the modern approach to this would be Erlang :) But I’m betting the only users will be you and I.
Here’s the problem with this argument: Pulumi is also a DSL.
It’s an internal DSL, like hashicorp’s own Vagrant, but it’s still a DSL. One could argue it’s closer to a library in the library - internal DSL spectrum, but when you’re using Pulumi, you’re mostly programming against its own model, not writing general purpose code, so I think it still is a DSL.
DevOps is a declarative game, in the end. Any tool that wants to play will have to at least wet its feet in DSLness, because it’s just a superior approach to the task at hand.
The main difference is that with Pulumi and similar, you at least have the whole rest of a proper programming language at your hands to use as needed.
The convenience of it mapping pretty well to existing concepts in the language is very useful as well. I’ve helped quite a few people get on with it without much prior DevOps experience but with experience of the language used, and I can confidently say that it would be a much harder job to bring them up to speed to using Terraform with it’s DSL.
Yeah, familiarity is a major advantage of internal DSLs in general, and so is flexibility of having the whole host language to draw from.
But having the whole complexity of the host language available is also one of the major downsides of internal DSLs, as well. I haven’t used Pulumi, but from the docs, I can see how easy it could be to end up with spaghetti code in what should be your mainly declarative infrastructure configuration.
I haven’t encountered any spaghetti code when working with CDK (similar, but slightly different to Pulumi), but admittedly I was mostly working with experienced developers (that had little DevOps experience). Maybe with more junior developers it’s more likely, but I think the DSL spaghetti in Terraform from them would be just as bad if not worse.
Though, as an anecdote, I chatted with a full DevOps guy I worked with for migrating a project from Terraform to Terraform CDK, and the only reason he didn’t go with CDK for the next project he worked on was that other DevOps wouldn’t quickly understand it, rather than any technical reasons.
the author advocates Pulumi vs Terraform (and I assume vs Ansible, Puppet, etc).
that is they advocate a general-purpose programming language SDK to aid Infrastructure as Code (IaC) configuraton development.
I was, at one time, fluent in Ansible, and somewhat familiar with Salt.
I would prefer a configuration language where evaluation of configuration decisions and dependencies – is built into the language itself (eg like in Dhall),
rather into IDE + general programming language SDK – like in Pulumi.
To me, dependency management, constraint evaluation, type-checking is a function of a language (and those feature are necessary for good developer experience in IaC tech).
And those features, then, enable advanced/but additive IDE features like refactoring, pattern analysis, recommendation engines.
Perhaps there is a ‘middle ground’ somewhere – where something like Pulumi would use annotations to instruct a general programming language compiler as to specific idioms. But then, it would be like a DSL.
FWIW I have struggled to find a way to like Dhall. It seems too powerful to be a configuration language and too weak to be anything else. I’m curious what you mean by evaluation of dependencies being built in.
I think Puppet is the best designed thing in the configuration management space by far, to the extent that it hurts a little bit to see it in an “etc” with Ansible. It’s a dynamic DSL which is constrained to output a (mostly-)well-typed static description of the desired state of a system. The language is a little weird, but it makes simple things easy, and is generally aware of the right things. Compared to Ansible or Salt it’s very hygienic—there’s no abuse of text templating anywhere!—and data generally flows in the right direction. It’s easy to make code reusable and codebases scale without becoming unmaintainable messes. I find it hard to imagine the same being true of, say, Python programs of similar size.
Nix (the language) comes to mind, especially viewed against NixOS competitor Guix’s use of Scheme. But I don’t know if I’ve ever encountered a tool written in Scheme, so it’d probably feel as much like a DSL to me as Nix does.
There’s some proposals to refactor Nix to make the layers more separable, which would eventually allow languages other than Nix to be compiled down into derivations and realized in the Nix store. I wonder if there’s a general-purpose language that would be good for that, other than Scheme.
I’m also following that Nix proposal. I think it’s a great idea and am glad the RFC was accepted.
Here’s one reason this is no panacea though: Anything that people will actually want to use will have to be able to call into Nix. Because otherwise, you get no access to nixpkgs, losing you one of the biggest benefits of adopting the Nix ecosystem.
That still leaves you with a few options: You can shell out to nix-instantiate, you can compile to nix code or you can use the little-knowm plugin system of nix that allows you to extend the interpreter. However, tooling for existing general-purpose languages is not really there yet.The only thing in this area I’ve seen is https://github.com/purenix-org/purenix
I like Terraform language (HCL). Unlike Ansible, which depended a lot on how each module was done, HCL it’s really declarative. Simple things are easy to understand. And I think that’s okay. Something more complex is vastly more difficult to write in HCL? Well, yes, but maybe then you should reconsider your architecture.
At $dayjob, due to the history of our DevOps stack, we don’t actually use plain Terraform. We use Jinja2 templates instead, this makes it easier to introduce some stuff that is more complex but every time I need to use that is because some historical stuff or something like that. If I wanted to do something from scratch, I would probably keep it very close to the plain Terraform style.
Author misses the point. Guitar hero is a 5 button + rocker switch abstraction that anyone can pickup. HCL, or any of these other infra DSLs are built as that same type of abstraction so that you don’t have to know how to do real chord progressions and complex fret dancing for infrastructure.
I think the author is actually arguing in favor of DSLs. They clearly never wanted to learn guitar.
I think you’re completely missing the effect of gamification and plain fun as a motivator here. Guitar Hero is a thing you pick up, can have fun day one, and progress. Learning to play the guitar is painful (I’m doing it right now) and I didn’t see real progress until I practiced for an hour a day for a week.
I suppose it’s different if you’ve never learned to program, but as someone who was programming in several languages, picking up Puppet and Terraform was… not exactly fun, but kinda easy?
I mostly think the comparison falls flat because GH doesn’t produce the real outcome, but DSLs are just a mix of “don’t care” and “shortcut to reach my goal”.
By not using DSLs you don’t automatically grasp the internal concepts, just as you can write a web app with a framework without understanding HTTP.
But on the other hand, I don’t see how knowing the internals helps you in any way in using the DSL.
I would synthesize the analogy by saying: GH is fun and easy, but it has a low ceiling. If you just want to sink 100 hours into a game, have fun with GH. If you want to put 10,000 hours into something, don’t make it GH, make it a real guitar. In the same way, a DSL can be good for a small devops team doing simple stuff, but once you have large teams creating their own modules, the benefits of using a real language will outweigh the costs.
Yes they do, speaking from experience. If a person knows how to program in a language, it’s way easier to bring them up to speed for Pulumi or some flavor of CDK, rather than Terraform or Puppet. “Create this object hierarchy” is a pretty simple job for people at least vaguely familiar with object oriented programming, and they only need to understand what the objects map to, while for Terraform and Puppet, you have to learn both what the objects map to, and the language and it’s idiosyncrasies, all mostly related to reducing repeating code (and very rarely, configuration).
Back when Puppet was popular, I kinda preferred it over Chef after a quick look at both. When Terraform came it was usable and nothing comparable existed (imho), it was fine.
Now, 10 years later I’m using the AWS TypeScript CDK and while I don’t like the implementation (and especially the dreadful documentation), but it’s really nice to be able write code against a library and most of the stuff we write is a) short, maybe 20 lines per module and b) understandable to people who are more on the ops side than the software development side
I agree and it doesn’t even stop there. Most people praise terraform and the like while comparing it to not having anything at all to re-provision their resources in case of accident or disaster. It’s not too tough of a competition when you’re competing against nothing, is it?
I have used puppet, ansible, terraform, cloudformation and perhaps a couple other infrastructure as code thingies whose name I can’t recall.
In two occasions though, we called the providers directly (aws in both cases) using python and shell scripts.
Both these systems were simple and fast and had everything we wanted and even things you won’t find on terraform, puppet, etc.
It is not that difficult to put together a good script that creates things from a declarative definition such a json file. Even state changes detection is not too difficult to implement if you really need it.
If I need to create a reproducible set of vpcs, network policies, ec2 instances, route53 zones, and so on… No problem, it’s perfectly doable with aws-cli and I would reach to it every day instead of terraform. “Oh, terraform is how everyone expects it to be done”… That didn’t work out too well, did it,
It is not that difficult to put together a good script that creates things from a declarative definition such a json file.
Strongly disagree, at scale.
At $previous_job, we had 5 regions * 3 environments * over a 100 applications, between managed and user services * 10s of resources per application.
Just on kubernetes resources alone, managing that with custom code would be a very big effort. Adding all the cloud resources, monitoring? Writing scripts to deploy, update, and manage state of all of that would be a massive undertaking, that the 5 of us would probably not be able to tackle by ourselves, never mind also helping other teams use the platform.
Leveraging existing tools that encapsulated complexity was essential. You might argue one tool is better than the other, that they have leaky abstractions, but you can’t operate platforms at scale with cobbled together scripts.
And weren’t even that big of a fish. Imagine 10s of clusters, thousands of services. That’s easily found in multinational corporations. Good luck managing that with ad-hoc scripts.
What does “at scale” mean? Much traffic/end users or an extensive complicated setup? Those are at best mutually independent. I even believe them to correlate negatively based on personal work experience.
Writing scripts to deploy, update, and manage state of all of that would be a massive undertaking
I meant scale of complexity, and you’re kinda right, it doesn’t necessarily correlate with traffic, as much as with business complexity.
My point being: start by not writing all of that.
That doesn’t make sense. Multiple departments have many, complex applications, to solve many, complex business needs. They need to deploy those applications, and need the corresponding resources for it. What should I do? Tell tem to fuck off?
Most complexity is accidental.
I don’t disagree entirely, but on the other hand, software developers tend to grossly underestimate the complexity of things outside their scope.
This “you don’t need all of that, let’s rewrite from scratch to make it simpler” attitude seldom survives contact with actual business requirements.
In both cases we went that path, it worked better, faster and was simpler to grasp than terraform.
There is nothing mystical about terraform. I don’t understand why another implementation of parts of what it does need to be “poor”. The fact that terraform is a popular project doesn’t mean it is the end all be all. In fact many people already had their infrastructure as code years before terraform existed.
I think it’s very bold to claim Terraform is a DSL… HCL is a data format that is more usable than JSON, but there are almost no devices for expressing domain-specific concerns; even worse, things like loops, conditions and multiple instantiation are obviously bolted on.
I think we somehow missed to consider two desirable properties of configuration systems that are nevertheless orthogonal: being declarative (which Excel, Terraform, Prolog mostly are) and being Turing-complete (which every Turing-complete programming language is, by definition). If we consider both properties, one can see that
there is no hopeProlog is the answer.Thats how Mark Burgess started (Prolog) and ended up with cfengine. I’d say the modern approach to this would be Erlang :) But I’m betting the only users will be you and I.
Doesn’t being Turing-complete mean that termination is not guaranteed?
Yes, that is why I want my configuration language to not be TC.
Here’s the problem with this argument: Pulumi is also a DSL.
It’s an internal DSL, like hashicorp’s own Vagrant, but it’s still a DSL. One could argue it’s closer to a library in the library - internal DSL spectrum, but when you’re using Pulumi, you’re mostly programming against its own model, not writing general purpose code, so I think it still is a DSL.
DevOps is a declarative game, in the end. Any tool that wants to play will have to at least wet its feet in DSLness, because it’s just a superior approach to the task at hand.
The main difference is that with Pulumi and similar, you at least have the whole rest of a proper programming language at your hands to use as needed.
The convenience of it mapping pretty well to existing concepts in the language is very useful as well. I’ve helped quite a few people get on with it without much prior DevOps experience but with experience of the language used, and I can confidently say that it would be a much harder job to bring them up to speed to using Terraform with it’s DSL.
Yeah, familiarity is a major advantage of internal DSLs in general, and so is flexibility of having the whole host language to draw from.
But having the whole complexity of the host language available is also one of the major downsides of internal DSLs, as well. I haven’t used Pulumi, but from the docs, I can see how easy it could be to end up with spaghetti code in what should be your mainly declarative infrastructure configuration.
I haven’t encountered any spaghetti code when working with CDK (similar, but slightly different to Pulumi), but admittedly I was mostly working with experienced developers (that had little DevOps experience). Maybe with more junior developers it’s more likely, but I think the DSL spaghetti in Terraform from them would be just as bad if not worse.
Though, as an anecdote, I chatted with a full DevOps guy I worked with for migrating a project from Terraform to Terraform CDK, and the only reason he didn’t go with CDK for the next project he worked on was that other DevOps wouldn’t quickly understand it, rather than any technical reasons.
the author advocates Pulumi vs Terraform (and I assume vs Ansible, Puppet, etc). that is they advocate a general-purpose programming language SDK to aid Infrastructure as Code (IaC) configuraton development.
I was, at one time, fluent in Ansible, and somewhat familiar with Salt.
I would prefer a configuration language where evaluation of configuration decisions and dependencies – is built into the language itself (eg like in Dhall), rather into IDE + general programming language SDK – like in Pulumi.
To me, dependency management, constraint evaluation, type-checking is a function of a language (and those feature are necessary for good developer experience in IaC tech). And those features, then, enable advanced/but additive IDE features like refactoring, pattern analysis, recommendation engines.
Perhaps there is a ‘middle ground’ somewhere – where something like Pulumi would use annotations to instruct a general programming language compiler as to specific idioms. But then, it would be like a DSL.
FWIW I have struggled to find a way to like Dhall. It seems too powerful to be a configuration language and too weak to be anything else. I’m curious what you mean by evaluation of dependencies being built in.
I think Puppet is the best designed thing in the configuration management space by far, to the extent that it hurts a little bit to see it in an “etc” with Ansible. It’s a dynamic DSL which is constrained to output a (mostly-)well-typed static description of the desired state of a system. The language is a little weird, but it makes simple things easy, and is generally aware of the right things. Compared to Ansible or Salt it’s very hygienic—there’s no abuse of text templating anywhere!—and data generally flows in the right direction. It’s easy to make code reusable and codebases scale without becoming unmaintainable messes. I find it hard to imagine the same being true of, say, Python programs of similar size.
Do there exist any examples of rich IDE support for configuration or IaC languages like you describe, please?
Nix (the language) comes to mind, especially viewed against NixOS competitor Guix’s use of Scheme. But I don’t know if I’ve ever encountered a tool written in Scheme, so it’d probably feel as much like a DSL to me as Nix does.
There’s some proposals to refactor Nix to make the layers more separable, which would eventually allow languages other than Nix to be compiled down into derivations and realized in the Nix store. I wonder if there’s a general-purpose language that would be good for that, other than Scheme.
I’m also following that Nix proposal. I think it’s a great idea and am glad the RFC was accepted.
Here’s one reason this is no panacea though: Anything that people will actually want to use will have to be able to call into Nix. Because otherwise, you get no access to nixpkgs, losing you one of the biggest benefits of adopting the Nix ecosystem.
That still leaves you with a few options: You can shell out to nix-instantiate, you can compile to nix code or you can use the little-knowm plugin system of nix that allows you to extend the interpreter. However, tooling for existing general-purpose languages is not really there yet.The only thing in this area I’ve seen is https://github.com/purenix-org/purenix
Typo in your URL, fixed: https://github.com/NixOS/rfcs/pull/134
I like Terraform language (HCL). Unlike Ansible, which depended a lot on how each module was done, HCL it’s really declarative. Simple things are easy to understand. And I think that’s okay. Something more complex is vastly more difficult to write in HCL? Well, yes, but maybe then you should reconsider your architecture.
At $dayjob, due to the history of our DevOps stack, we don’t actually use plain Terraform. We use Jinja2 templates instead, this makes it easier to introduce some stuff that is more complex but every time I need to use that is because some historical stuff or something like that. If I wanted to do something from scratch, I would probably keep it very close to the plain Terraform style.
Not to be too judgy, but that sounds horrible.
Especially with existing hcl-json converters. If you’re already generating those, why not generate json instead of doing text templates?
There’s probably a long and tortuous history of decisions that all individually made sense, that lead to this.
Stills sounds horrible, though.
Author misses the point. Guitar hero is a 5 button + rocker switch abstraction that anyone can pickup. HCL, or any of these other infra DSLs are built as that same type of abstraction so that you don’t have to know how to do real chord progressions and complex fret dancing for infrastructure.
I think the author is actually arguing in favor of DSLs. They clearly never wanted to learn guitar.
I think you’re completely missing the effect of gamification and plain fun as a motivator here. Guitar Hero is a thing you pick up, can have fun day one, and progress. Learning to play the guitar is painful (I’m doing it right now) and I didn’t see real progress until I practiced for an hour a day for a week.
I suppose it’s different if you’ve never learned to program, but as someone who was programming in several languages, picking up Puppet and Terraform was… not exactly fun, but kinda easy?
What are you arguing exactly? That Puppet and Terraform fail the “guitar hero” test?
For both Terraform and Puppet, it’s not enough to just “know the language,” you need to have some familiarity with the “songs,” too.
I mostly think the comparison falls flat because GH doesn’t produce the real outcome, but DSLs are just a mix of “don’t care” and “shortcut to reach my goal”.
By not using DSLs you don’t automatically grasp the internal concepts, just as you can write a web app with a framework without understanding HTTP.
But on the other hand, I don’t see how knowing the internals helps you in any way in using the DSL.
I would synthesize the analogy by saying: GH is fun and easy, but it has a low ceiling. If you just want to sink 100 hours into a game, have fun with GH. If you want to put 10,000 hours into something, don’t make it GH, make it a real guitar. In the same way, a DSL can be good for a small devops team doing simple stuff, but once you have large teams creating their own modules, the benefits of using a real language will outweigh the costs.
Yes they do, speaking from experience. If a person knows how to program in a language, it’s way easier to bring them up to speed for Pulumi or some flavor of CDK, rather than Terraform or Puppet. “Create this object hierarchy” is a pretty simple job for people at least vaguely familiar with object oriented programming, and they only need to understand what the objects map to, while for Terraform and Puppet, you have to learn both what the objects map to, and the language and it’s idiosyncrasies, all mostly related to reducing repeating code (and very rarely, configuration).
Back when Puppet was popular, I kinda preferred it over Chef after a quick look at both. When Terraform came it was usable and nothing comparable existed (imho), it was fine.
Now, 10 years later I’m using the AWS TypeScript CDK and while I don’t like the implementation (and especially the dreadful documentation), but it’s really nice to be able write code against a library and most of the stuff we write is a) short, maybe 20 lines per module and b) understandable to people who are more on the ops side than the software development side
I agree and it doesn’t even stop there. Most people praise terraform and the like while comparing it to not having anything at all to re-provision their resources in case of accident or disaster. It’s not too tough of a competition when you’re competing against nothing, is it?
I have used puppet, ansible, terraform, cloudformation and perhaps a couple other infrastructure as code thingies whose name I can’t recall. In two occasions though, we called the providers directly (aws in both cases) using python and shell scripts. Both these systems were simple and fast and had everything we wanted and even things you won’t find on terraform, puppet, etc.
It is not that difficult to put together a good script that creates things from a declarative definition such a json file. Even state changes detection is not too difficult to implement if you really need it.
If I need to create a reproducible set of vpcs, network policies, ec2 instances, route53 zones, and so on… No problem, it’s perfectly doable with aws-cli and I would reach to it every day instead of terraform. “Oh, terraform is how everyone expects it to be done”… That didn’t work out too well, did it,
Strongly disagree, at scale.
At $previous_job, we had 5 regions * 3 environments * over a 100 applications, between managed and user services * 10s of resources per application.
Just on kubernetes resources alone, managing that with custom code would be a very big effort. Adding all the cloud resources, monitoring? Writing scripts to deploy, update, and manage state of all of that would be a massive undertaking, that the 5 of us would probably not be able to tackle by ourselves, never mind also helping other teams use the platform.
Leveraging existing tools that encapsulated complexity was essential. You might argue one tool is better than the other, that they have leaky abstractions, but you can’t operate platforms at scale with cobbled together scripts.
And weren’t even that big of a fish. Imagine 10s of clusters, thousands of services. That’s easily found in multinational corporations. Good luck managing that with ad-hoc scripts.
What does “at scale” mean? Much traffic/end users or an extensive complicated setup? Those are at best mutually independent. I even believe them to correlate negatively based on personal work experience.
My point being: start by not writing all of that.
Most complexity is accidental.
I meant scale of complexity, and you’re kinda right, it doesn’t necessarily correlate with traffic, as much as with business complexity.
That doesn’t make sense. Multiple departments have many, complex applications, to solve many, complex business needs. They need to deploy those applications, and need the corresponding resources for it. What should I do? Tell tem to fuck off?
I don’t disagree entirely, but on the other hand, software developers tend to grossly underestimate the complexity of things outside their scope.
This “you don’t need all of that, let’s rewrite from scratch to make it simpler” attitude seldom survives contact with actual business requirements.
and end up with a poorly partially implemented version of Terraform you have to migrate to Terraform anyway?
In both cases we went that path, it worked better, faster and was simpler to grasp than terraform.
There is nothing mystical about terraform. I don’t understand why another implementation of parts of what it does need to be “poor”. The fact that terraform is a popular project doesn’t mean it is the end all be all. In fact many people already had their infrastructure as code years before terraform existed.
I think it’s very bold to claim Terraform is a DSL… HCL is a data format that is more usable than JSON, but there are almost no devices for expressing domain-specific concerns; even worse, things like loops, conditions and multiple instantiation are obviously bolted on.