19 ms·

I witness the same mentality in sbt users, Turing computable > declarative. I don't get it though. In both the build system and the deploy system, I want to kn

I witness the same mentality in sbt users, Turing computable > declarative. I don't get it though. In both the build system and the deploy system, I want to know the config terminates, and I want it to be easy to understand. The application's specialization is Turing computability. I prefer that footgun to stay isolated there. But maybe there is a use case I don't get. Imagine accidentally provisioning infinite VMs...

hinkley 7y ago
You can’t step through declarative code in a debugger. That’s a problem for discoverability, which also means more friction for new learners.
- hombre_fatal 7y ago
  You've already lost big if you ever need a debugger to understand code. Especially if your beginners have to use it just to wrap their head around wtf is happening. And having to run your "config files" just to see what they're doing is the huge downside of using programming languages as config. In other words, it's kind of circular to point out that using code for config puts you in a situation where you might have to use a debugger to know what your config does.
  - hinkley 7y ago
    You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? There’s a middle ground that you see with a number of test frameworks, Gulp, SCons and I suspect with Pulumi, where the outer shell of imperative code is in practice declarative, and the inner bits are properly imperative. Part of the code says why to do something, and the rest says how to do it. For instance I don’t see a huge conceptual difference between disabling or filtering a test, versus not deploying a service because it is running, current, and healthy.
    - tedivm 7y ago
      > You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? To me that sounds like a failure state.
- SamBam 7y ago
  But isn't the output of this declarative config files?
  - hinkley 7y ago
    Now? You're probably right. If you proxy to replace it might not have to stay that way. But the Lava Flow Antipattern is what happens when momentum fails before the work is complete.
cpach 7y ago
What is sbt?
- AzzieElbab 7y ago
  Scala build tool. Build files are a mix of scala code and dsl
rainforest 7y ago
One use case that TF really frustrates me with is anything conditional: if I want to do blue/green the best I can do is duplicate the entire infrastructure and wrap my terraform invocations with some brittle script that repeatedly runs TF with various targets. The script only allows me to define the target state, but it is quite common that I care how that final state is reached. Create-if-not-exists is also really poor in TF (probably by design), if you want to reuse your TF configs for different environments in the same account, you either have to ensure everything won't collide name-wise, or split your TF into immutable infrastructure and really-immutable infrastructure.
- rjzzleep 7y ago
  Doesn't terragrunt allow you to do that? The looping code while better with terraform 0.12 is still quite nasty though. https://terragrunt.gruntwork.io/docs/getting-started/quick-start/ https://terragrunt.gruntwork.io/docs/getting-started/quick-s...
  - rainforest 7y ago
    I wasn't aware of this, looks like it would solve some of our pain points, thanks! I think the existence of tools like this is a succinct way to say that static/declarative languages are really hard to execute.
  - core-questions 7y ago
    The idea of having to use a 3rd party tool to generate config for my 3rd party tool that generates config just seems Wrong. At this point I'd rather write idiomatic but repetitive Terraform and know that I will be safer on upgrades, as long as I continue to refactor and clean up my modules for the new functionality Hashi is releasing.
lukehoban 7y ago
[disclaimer: CTO at Pulumi so clearly biased :-)] One of the things I really believe is that you can have the best of both worlds here. Pulumi uses imperative programming languages, but is still "declarative". The imperative programs are executed to build up the desired state, which can then be reliably diff'd and previewed, and can be used to enforce manual or automatic checks for correctness. So you get the expressiveness of imperative programs (loops, conditionals, components, packages, versioning, IDE tooling, testing, error checking, etc.), but still the safeguards and reliability of declarative infrastructure-as-code (preview, gated deployments, policy enforcement, etc.). I also tend to view the perceived benefits of JSON/YAML/HCL "simplicity" as somewhat comparing apples to oranges on a complexity specturm. If you are only managing a dozen resources, it may be that JSON/YAML/HCL are fundamentally simpler. But when you've copy/pasted tens of thousands of lines of YAML around all over your codebase to manage hundreds or thousands of resources, the value of abstraction, reuse, well defined interfaces, and tooling to manage that complexity feels to me essential to the scale of the problem. And that degree of complexity is no longer just something large organizations are dealing with. Modern cloud technologies (serverless, containers, Kubernetes, etc.) are leading to significant increases in the number of cloud resources being managed, and the pace at which those resource are deployed and updated. Assembly is a "simpler" way to think about programming, but didn't scale as complexity of application software increases. I believe the same is true about JSON/YAML/HCL and cloud infrastructure.
- Boulth 7y ago
  Thanks for the elaborate answer! I wonder if you considered Dhall (https://dhall-lang.org/ https://dhall-lang.org/) that's declarative but at the same time has functions and other convenience factors.
- mixedCase 7y ago
  > But when you've copy/pasted tens of thousands of lines of YAML around all over your codebase to manage hundreds or thousands of resources, the value of abstraction, reuse, well defined interfaces, and tooling to manage that complexity feels to me essential to the scale of the problem. You're lumping in HCL (and languages like Dhall by extension) with static serialization formats and criticizing them for a characteristic only found in the latter. HCL is programmable and has a fair model for code reusability through modules, state outputs, for-expressions and other kinds of expressions. Add in a proper language with types like Dhall and you have a configuration language where you can apply all the transformations you could want with a much higher safety and robustness floor than a turing-complete language that allows you to make all sorts of messes. It's specially dangerous to have a turing-complete language for configuration once you factor in that the reflex of an inexperienced developer who is more likely to make these messes is to use a tool they're already familiar with even when the tool is actively harmful to their goals, as Pulumi facilitates.
manojlds 7y ago
Most sbt users hate it btw.
mtalantikite 7y ago
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.
- throwaway894345 7y ago
  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: https://github.com/weberc2/nimbus/blob/master/examples/src/nimbus_examples/s3bucket.py https://github.com/weberc2/nimbus/blob/master/examples/src/n... 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.
throwaway894345 7y ago
The model is "use a programming language to generate static configs", so you can't provision infinite VMs--your program would OOM or run out of disk because you're trying to generate an infinitely-large config file. If you're seriously concerned about this (and you shouldn't be), you can use something like Starlark (https://go.starlark.net https://go.starlark.net), which is a Python dialect that prohibits unbounded loops, I/O, etc. Note that if you use Python with type hints, you can actually get more safety than YAML.

hinkley 7y ago

You can’t step through declarative code in a debugger. That’s a problem for discoverability, which also means more friction for new learners.

hombre_fatal 7y ago
You've already lost big if you ever need a debugger to understand code. Especially if your beginners have to use it just to wrap their head around wtf is happening. And having to run your "config files" just to see what they're doing is the huge downside of using programming languages as config. In other words, it's kind of circular to point out that using code for config puts you in a situation where you might have to use a debugger to know what your config does.
- hinkley 7y ago
  You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? There’s a middle ground that you see with a number of test frameworks, Gulp, SCons and I suspect with Pulumi, where the outer shell of imperative code is in practice declarative, and the inner bits are properly imperative. Part of the code says why to do something, and the rest says how to do it. For instance I don’t see a huge conceptual difference between disabling or filtering a test, versus not deploying a service because it is running, current, and healthy.
  - tedivm 7y ago
    > You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? To me that sounds like a failure state.
SamBam 7y ago
But isn't the output of this declarative config files?
- hinkley 7y ago
  Now? You're probably right. If you proxy to replace it might not have to stay that way. But the Lava Flow Antipattern is what happens when momentum fails before the work is complete.

cpach 7y ago

What is sbt?

AzzieElbab 7y ago
Scala build tool. Build files are a mix of scala code and dsl

rainforest 7y ago

One use case that TF really frustrates me with is anything conditional: if I want to do blue/green the best I can do is duplicate the entire infrastructure and wrap my terraform invocations with some brittle script that repeatedly runs TF with various targets. The script only allows me to define the target state, but it is quite common that I care how that final state is reached. Create-if-not-exists is also really poor in TF (probably by design), if you want to reuse your TF configs for different environments in the same account, you either have to ensure everything won't collide name-wise, or split your TF into immutable infrastructure and really-immutable infrastructure.

rjzzleep 7y ago
Doesn't terragrunt allow you to do that? The looping code while better with terraform 0.12 is still quite nasty though. https://terragrunt.gruntwork.io/docs/getting-started/quick-start/ https://terragrunt.gruntwork.io/docs/getting-started/quick-s...
- rainforest 7y ago
  I wasn't aware of this, looks like it would solve some of our pain points, thanks! I think the existence of tools like this is a succinct way to say that static/declarative languages are really hard to execute.
- core-questions 7y ago
  The idea of having to use a 3rd party tool to generate config for my 3rd party tool that generates config just seems Wrong. At this point I'd rather write idiomatic but repetitive Terraform and know that I will be safer on upgrades, as long as I continue to refactor and clean up my modules for the new functionality Hashi is releasing.

lukehoban 7y ago

[disclaimer: CTO at Pulumi so clearly biased :-)] One of the things I really believe is that you can have the best of both worlds here. Pulumi uses imperative programming languages, but is still "declarative". The imperative programs are executed to build up the desired state, which can then be reliably diff'd and previewed, and can be used to enforce manual or automatic checks for correctness. So you get the expressiveness of imperative programs (loops, conditionals, components, packages, versioning, IDE tooling, testing, error checking, etc.), but still the safeguards and reliability of declarative infrastructure-as-code (preview, gated deployments, policy enforcement, etc.). I also tend to view the perceived benefits of JSON/YAML/HCL "simplicity" as somewhat comparing apples to oranges on a complexity specturm. If you are only managing a dozen resources, it may be that JSON/YAML/HCL are fundamentally simpler. But when you've copy/pasted tens of thousands of lines of YAML around all over your codebase to manage hundreds or thousands of resources, the value of abstraction, reuse, well defined interfaces, and tooling to manage that complexity feels to me essential to the scale of the problem. And that degree of complexity is no longer just something large organizations are dealing with. Modern cloud technologies (serverless, containers, Kubernetes, etc.) are leading to significant increases in the number of cloud resources being managed, and the pace at which those resource are deployed and updated. Assembly is a "simpler" way to think about programming, but didn't scale as complexity of application software increases. I believe the same is true about JSON/YAML/HCL and cloud infrastructure.

Boulth 7y ago
Thanks for the elaborate answer! I wonder if you considered Dhall (https://dhall-lang.org/ https://dhall-lang.org/) that's declarative but at the same time has functions and other convenience factors.
mixedCase 7y ago
> But when you've copy/pasted tens of thousands of lines of YAML around all over your codebase to manage hundreds or thousands of resources, the value of abstraction, reuse, well defined interfaces, and tooling to manage that complexity feels to me essential to the scale of the problem. You're lumping in HCL (and languages like Dhall by extension) with static serialization formats and criticizing them for a characteristic only found in the latter. HCL is programmable and has a fair model for code reusability through modules, state outputs, for-expressions and other kinds of expressions. Add in a proper language with types like Dhall and you have a configuration language where you can apply all the transformations you could want with a much higher safety and robustness floor than a turing-complete language that allows you to make all sorts of messes. It's specially dangerous to have a turing-complete language for configuration once you factor in that the reflex of an inexperienced developer who is more likely to make these messes is to use a tool they're already familiar with even when the tool is actively harmful to their goals, as Pulumi facilitates.

manojlds 7y ago

Most sbt users hate it btw.

mtalantikite 7y ago

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.

throwaway894345 7y ago
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: https://github.com/weberc2/nimbus/blob/master/examples/src/nimbus_examples/s3bucket.py https://github.com/weberc2/nimbus/blob/master/examples/src/n... 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.

throwaway894345 7y ago

The model is "use a programming language to generate static configs", so you can't provision infinite VMs--your program would OOM or run out of disk because you're trying to generate an infinitely-large config file. If you're seriously concerned about this (and you shouldn't be), you can use something like Starlark (https://go.starlark.net https://go.starlark.net), which is a Python dialect that prohibits unbounded loops, I/O, etc. Note that if you use Python with type hints, you can actually get more safety than YAML.