5 ms·

I'm surprised Hashicorp hasn't repositioned this product. Terraform was a huge breath of fresh air after Cloudformation. If you ask me, deploying apps via k8s

I'm surprised Hashicorp hasn't repositioned this product. Terraform was a huge breath of fresh air after Cloudformation. If you ask me, deploying apps via k8s is even better. Everyone wants a free lunch and for me, momentum + cloud vendor support + ultimately the Nomad Enterprise features that come free with K8s made the choice easy.

rossmohax 6y ago
TF can be often suffocating still. Pulumi runs circles around it, when it comes to user experience in writing complex, modular, composable and reusable configurations.
- tetha 6y ago
  Except now you have to deal with javascript. It's hard enough to turn some operators towards an IaC approach, but throwing Javascript at them isn't going to help.
  - memexy 6y ago
    What language would be good for operators if not JavaScript?
    - macintux 6y ago
      Speaking as a 25-year sys/netadmin who writes a fair bit of code too: nearly anything. I'd rather learn Go than deal with JavaScript. Python would be fine. Elixir would be great (I'd much prefer Erlang but there are only so many miracles I'm allotted in this lifetime). Perl, please.
      - memexy 6y ago
        Pulumi has support both for Python and Go along with TypeScript and JavaScript. I never understand when people say operators don't like programming languages. Always seems weird to me that a person that constantly works with computers would prefer a static markup language instead of full programming language for managing the complexity of operating software in production environments. My original comment was about this attitude. I personally think programming languages are much better than markup languages for almost everything. If you are presenting static content then markup languages are fine but if you're doing anything more than presenting static content then YAML just makes no sense.
        nine_k 6y ago
        A full programming language gives too much flexibility. In particular, this includes the flexibility allowing to shoot oneself in the foot. A person who constantly works with computers is painfully aware of the people's ability to screw things up by an honest mistake when programming them. The more complex the thing, the easier it is to make a mistake, because human attention is finite. Whenever you can limit the language to the task at hand, and build in guard rails that would prevent you from doing things you should not be doing, it's usually a productivity win, even if it precludes implementation of 3% of some most advanced and complex solutions. Reliability and simplicity go hand in hand, and reliability is often the thing devops people value very highly.
        memexy 6y ago
        I can build DSLs (domain specific languages) with programming languages. I can't build DSLs with YAML. And when someone says "You will use YAML because you can't be trusted with a programming languages" then I find that very disrespectful and condescending. The solution to finite attention isn't less powerful tools. The solution is more powerful tools that augment operators and let them extend their finite attention spans into longer time horizons. How is your description and viewpoint different from what I just described?
        nine_k 6y ago
        A good DSL (as opposed to a raw general-purpose language) would be ideal. It's the guard rails I'm after, when implemented well. What I won't like is the "here are some classes and functions for accessing our API, go build the stuff somehow" approach.
        memexy 6y ago
        Then we're in agreement.
        dmwilcox 6y ago
        Having worked in several declarative config systems at a big tech company that tried to provide these guard rails. They errode!! And it makes sense. As we demand more flexibility to not repeat ourselves (DRY) we get clever and add little features. Suddenly you can stick an entire cluster config (or several!!) inside a lambda that returns the declared resources... And you've gone straight to hell. You're more than Turing complete by then and engineers are reinventing conditionals and loops with lambdas all over your config codebase. Might as well have just started and left it at Python/etc.
  - jen20 6y ago
    Pulumi does not require JavaScript at all - it is one of a range of options, including JavaScript, TypeScript, Python, Go, C# and F# (currently). Disclaimer: I worked on Terraform at HashiCorp and am a contributor to Pulumi also.
    - gavinray 6y ago
      Pulumi is so good (even if it is just typed-SDK's over Terraform). Only sane approach to IaC IMO, using an actual programming language with types and IDE integration. Really dig using with it Cloud Run.
      - jen20 6y ago
        It’s also not typed SDKs over Terraform. The best Pulumi providers are native and offer a much richer experience than the wrapped Terraform providers (see the Kubernetes support for example). I for one look forward to those rolling out across the board!
        gavinray 6y ago
        I actually have one burning question if you don't mind answering: Pulumi has two different k8s modules, the standard one (pulumi-kubernetes) and "kubernetes-x" which has a much nicer API that reduces boilerplate: https://github.com/pulumi/pulumi-kubernetesx https://github.com/pulumi/pulumi-kubernetesx The second one doesn't seem to be used in the Pulumi tutorial content and has less stars/recognition. Are these interchangeable? If so, why not use @pulumi/kubernetesx instead of the standard k8s module everywhere?
        jen20 6y ago
        They’re not interchangeable - kubernetes-x builds higher level abstractions on top of the pulumi-kubernetes API which is faithful to the openAPI supplier by Kubernetes. To my mind, the real power of having general purpose languages building the declarative model instead of a DSL is that libraries like k-x (or indeed AWS-x) can actually be built!
- mdaniel 6y ago
  By going with a "fork and patch" model, rather than shelling out to the existing terraform providers, they are putting themselves in a constant race to overtake TF's popularity. Their okta provider, for example, is based on some absolutely ancient, non-standard provider (https://github.com/pulumi/pulumi-okta/blob/v2.1.2/provider/go.mod#L6 https://github.com/pulumi/pulumi-okta/blob/v2.1.2/provider/g... ) instead of using the official one which receives regular updates: https://github.com/terraform-providers/terraform-provider-okta/releases https://github.com/terraform-providers/terraform-provider-ok... ; and now I guess it's on me to do some git diff to find out if there are meaningful changes between the imported provider and the upstream one? To say nothing of the more esoteric providers that one can cheaply build and place in the `.terraform.d/plugins` directory and off you go, in contrast to trying to find the dark magick required to use some combination of https://github.com/pulumi/pulumi-terraform-bridge https://github.com/pulumi/pulumi-terraform-bridge and https://github.com/pulumi/pulumi-tf-provider-boilerplate https://github.com/pulumi/pulumi-tf-provider-boilerplate but ... err, ... then one has to own that new generated pulumi provider code? So like a fork but worse? Maybe they should make a bot that tracks the terraform-provider topic on GH and uses their insider knowledge to generate pulumi providers for them. Don't get me wrong: I anxiously await the death of TF, but until there is a good story to tell my colleagues about an alternative to it, they'll continue to use it.
topspin 6y ago
> Terraform was a huge breath of fresh air after Cloudformation. Humans shouldn't write CloudFormation templates. If you're doing that here is a important free clue: use CDK. One advantage of CDK over Terraform is that the 'state' is the CloudFormation stacks themselves as opposed to Terraform's state system. Another is that you get a real programming language (your choice of several) using CDK. The disadvantage of CDK is that it's AWS only.

rossmohax 6y ago

TF can be often suffocating still. Pulumi runs circles around it, when it comes to user experience in writing complex, modular, composable and reusable configurations.

tetha 6y ago
Except now you have to deal with javascript. It's hard enough to turn some operators towards an IaC approach, but throwing Javascript at them isn't going to help.
- memexy 6y ago
  What language would be good for operators if not JavaScript?
  - macintux 6y ago
    Speaking as a 25-year sys/netadmin who writes a fair bit of code too: nearly anything. I'd rather learn Go than deal with JavaScript. Python would be fine. Elixir would be great (I'd much prefer Erlang but there are only so many miracles I'm allotted in this lifetime). Perl, please.
    - memexy 6y ago
      Pulumi has support both for Python and Go along with TypeScript and JavaScript. I never understand when people say operators don't like programming languages. Always seems weird to me that a person that constantly works with computers would prefer a static markup language instead of full programming language for managing the complexity of operating software in production environments. My original comment was about this attitude. I personally think programming languages are much better than markup languages for almost everything. If you are presenting static content then markup languages are fine but if you're doing anything more than presenting static content then YAML just makes no sense.
      - nine_k 6y ago
        A full programming language gives too much flexibility. In particular, this includes the flexibility allowing to shoot oneself in the foot. A person who constantly works with computers is painfully aware of the people's ability to screw things up by an honest mistake when programming them. The more complex the thing, the easier it is to make a mistake, because human attention is finite. Whenever you can limit the language to the task at hand, and build in guard rails that would prevent you from doing things you should not be doing, it's usually a productivity win, even if it precludes implementation of 3% of some most advanced and complex solutions. Reliability and simplicity go hand in hand, and reliability is often the thing devops people value very highly.
        memexy 6y ago
        I can build DSLs (domain specific languages) with programming languages. I can't build DSLs with YAML. And when someone says "You will use YAML because you can't be trusted with a programming languages" then I find that very disrespectful and condescending. The solution to finite attention isn't less powerful tools. The solution is more powerful tools that augment operators and let them extend their finite attention spans into longer time horizons. How is your description and viewpoint different from what I just described?
        nine_k 6y ago
        A good DSL (as opposed to a raw general-purpose language) would be ideal. It's the guard rails I'm after, when implemented well. What I won't like is the "here are some classes and functions for accessing our API, go build the stuff somehow" approach.
        memexy 6y ago
        Then we're in agreement.
        dmwilcox 6y ago
        Having worked in several declarative config systems at a big tech company that tried to provide these guard rails. They errode!! And it makes sense. As we demand more flexibility to not repeat ourselves (DRY) we get clever and add little features. Suddenly you can stick an entire cluster config (or several!!) inside a lambda that returns the declared resources... And you've gone straight to hell. You're more than Turing complete by then and engineers are reinventing conditionals and loops with lambdas all over your config codebase. Might as well have just started and left it at Python/etc.
- jen20 6y ago
  Pulumi does not require JavaScript at all - it is one of a range of options, including JavaScript, TypeScript, Python, Go, C# and F# (currently). Disclaimer: I worked on Terraform at HashiCorp and am a contributor to Pulumi also.
  - gavinray 6y ago
    Pulumi is so good (even if it is just typed-SDK's over Terraform). Only sane approach to IaC IMO, using an actual programming language with types and IDE integration. Really dig using with it Cloud Run.
    - jen20 6y ago
      It’s also not typed SDKs over Terraform. The best Pulumi providers are native and offer a much richer experience than the wrapped Terraform providers (see the Kubernetes support for example). I for one look forward to those rolling out across the board!
      - gavinray 6y ago
        I actually have one burning question if you don't mind answering: Pulumi has two different k8s modules, the standard one (pulumi-kubernetes) and "kubernetes-x" which has a much nicer API that reduces boilerplate: https://github.com/pulumi/pulumi-kubernetesx https://github.com/pulumi/pulumi-kubernetesx The second one doesn't seem to be used in the Pulumi tutorial content and has less stars/recognition. Are these interchangeable? If so, why not use @pulumi/kubernetesx instead of the standard k8s module everywhere?
        jen20 6y ago
        They’re not interchangeable - kubernetes-x builds higher level abstractions on top of the pulumi-kubernetes API which is faithful to the openAPI supplier by Kubernetes. To my mind, the real power of having general purpose languages building the declarative model instead of a DSL is that libraries like k-x (or indeed AWS-x) can actually be built!
mdaniel 6y ago
By going with a "fork and patch" model, rather than shelling out to the existing terraform providers, they are putting themselves in a constant race to overtake TF's popularity. Their okta provider, for example, is based on some absolutely ancient, non-standard provider (https://github.com/pulumi/pulumi-okta/blob/v2.1.2/provider/go.mod#L6 https://github.com/pulumi/pulumi-okta/blob/v2.1.2/provider/g... ) instead of using the official one which receives regular updates: https://github.com/terraform-providers/terraform-provider-okta/releases https://github.com/terraform-providers/terraform-provider-ok... ; and now I guess it's on me to do some git diff to find out if there are meaningful changes between the imported provider and the upstream one? To say nothing of the more esoteric providers that one can cheaply build and place in the `.terraform.d/plugins` directory and off you go, in contrast to trying to find the dark magick required to use some combination of https://github.com/pulumi/pulumi-terraform-bridge https://github.com/pulumi/pulumi-terraform-bridge and https://github.com/pulumi/pulumi-tf-provider-boilerplate https://github.com/pulumi/pulumi-tf-provider-boilerplate but ... err, ... then one has to own that new generated pulumi provider code? So like a fork but worse? Maybe they should make a bot that tracks the terraform-provider topic on GH and uses their insider knowledge to generate pulumi providers for them. Don't get me wrong: I anxiously await the death of TF, but until there is a good story to tell my colleagues about an alternative to it, they'll continue to use it.

topspin 6y ago

> Terraform was a huge breath of fresh air after Cloudformation. Humans shouldn't write CloudFormation templates. If you're doing that here is a important free clue: use CDK. One advantage of CDK over Terraform is that the 'state' is the CloudFormation stacks themselves as opposed to Terraform's state system. Another is that you get a real programming language (your choice of several) using CDK. The disadvantage of CDK is that it's AWS only.