4 ms·

Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questio

Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questions, and a big battle happening in the community. What do they do? I truly believe that a CTO who sees Terraform as an option and who isn't scared off by the BSL, but then has all of these other concerns, exists only in fantasy.

verdverm 3y ago
Lots of people still using elastic, mongo, and redis. What's different about this one?
- vosper 3y ago
  Just went with Elastic cloud after evaluating both Elasticsearch and OpenSearch. It was an easy choice to stick with the incumbent/creator that I was familiar with. No complaints so far.
  - verdverm 3y ago
    We just went back to TF after giving Pulumi a try. Prefer declarative syntax for infra and more abuse of Yaml ("fn::..." here) is not what I'm after. We are working on wrapping TF in CUE since you can CUE->JSON->TF https://github.com/hofstadter-io/cuelm https://github.com/hofstadter-io/cuelm Many more CUE experiments are going on in the devops space
    - AaronFriel 3y ago
      Pulumi has a few languages other than YAML and Pulumi is declarative[1], and the programs you write are only as complex as you want them to be. This python program declares an S3 bucket and declares ten objects to exist in it. from pulumi_aws import s3 bucket = s3.Bucket('bucket') for i in range(10): s3.BucketObject( f'object-{i}', s3.BucketObjectArgs( bucket=bucket.id, key=str(i), ) ) Even so, Pulumi YAML has a "compiler" option, so if you want to write CUE or jsonnet[1], or other[2] languages, it definitely supports that. Disclaimer: I led the YAML project and added the compiler feature at the request of some folks internally looking for CUE support :) [1] https://www.pulumi.com/blog/pulumi-is-imperative-declarative-imperative/ https://www.pulumi.com/blog/pulumi-is-imperative-declarative... [2] https://www.pulumi.com/blog/extending-pulumi-languages-with-yaml-cue-jsonnet-rust/ https://www.pulumi.com/blog/extending-pulumi-languages-with-... [3] https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes-clusters-in-absurd-languages https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes...
      - verdverm 3y ago
        I'm aware of the SDKs, but we don't want them because they are an imperative interface, no matter how you want to spin it as "declarative". I have access to all the imperative constructs in the underlying language and can create conditional execution without restriction. Even if I use the Yaml compiler for CUE (which we did) I still have to write `fn::` strings as keys, which is ugly and not the direction our industry should go. Let's stop putting imperative constructs into string, let's use a better language for configuration, something purpose built, not an SDK in an imperative language. These "fn::" strings are just bringing imperative constructs back into what could have been an actual declarative interface. Note, Pulumi is not alone here, there are lots of people hacking Yaml because they don't know what else there is to do. CEL making it's way to k8s is another specific example. This cannot be the state-of-art in ops, we can do much better, but I get that Pulumi is trying to reach a different set of users than devops and will end up with different choices and tradeoffs (I maintain https://cuetorials.com https://cuetorials.com and am very active in the CUE community)
      - lmm 3y ago
        An imperative for loop is somehow declarative now? Lol.
        verdverm 3y ago
        you can have loops and still be declarative, CUE has loops, though they are considered comprehensions more technically, but there is no assignment or stack in CUE One of the interesting aspects of CUE is that it gives us many of the programming constructs we are used to, but remains Turing incomplete, so no general recursion or user defined functions. There is a scripting layer where you can get more real world stuff done too The CUE language is super interesting, has a very unique take on things and comes from the same heritage as Go, containers, and Kubernetes https://cuelang.org https://cuelang.org | https://cuetorials.com https://cuetorials.com
        jjnoakes 3y ago
        This seems extremely dismissive and shallow. The imperative part of that code appears to be analogous to templating. The actual work done under the covers is not imperative, but is based on the difference between the result of the template execution and the current state of the system. That's what makes it declarative.
- i_am_jl 3y ago
  You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products. Read benevolently it's a prohibition from spinning up a service based on HashiCorp's code and undercutting HashiCorp's pricing. On the other hand, if I build a product with HashiCorp-owned BSL'd code, then HashiCorp releases/acquires a product that competes with mine, then my license is void.
  - verdverm 3y ago
    My understanding is that the aforementioned companies' licenses are to the same effect, so what is the difference?
    - i_am_jl 3y ago
      Redis is 3-clause BSD, BSD does not have a "your license is void if you sell a product that competes with us" clause. Redis does have enterprise products that are licensed in a manner similar to BSL, but Redis itself is not. MongoDB and Elastic are SSPL. SSPL approaches the problem like the AGPL; it compels licensees who sell a service derived from the software to make available under the SSPL the source of all supporting tooling and software so that a user could spin up their own version of the service. There's an argument to be made that SSPL is de facto "you can't compete with us" since it would be more challenging to make a competitive SaaS offering if your whole stack is source available. I don't disagree. However, as distasteful as SSPL is, at least it doesn't grant licensing to a product conditionally on the unknowable future product offerings of HashiCorp.
      - verdverm 3y ago
        thanks for the explanation, my understanding is that they are all after limiting competition in various ways, while still trying to maintain the mantle of open source We are certainly in interesting times around the monetization / financial sustainability of open source
    - bit_flipper 3y ago

verdverm 3y ago

Lots of people still using elastic, mongo, and redis. What's different about this one?

vosper 3y ago
Just went with Elastic cloud after evaluating both Elasticsearch and OpenSearch. It was an easy choice to stick with the incumbent/creator that I was familiar with. No complaints so far.
- verdverm 3y ago
  We just went back to TF after giving Pulumi a try. Prefer declarative syntax for infra and more abuse of Yaml ("fn::..." here) is not what I'm after. We are working on wrapping TF in CUE since you can CUE->JSON->TF https://github.com/hofstadter-io/cuelm https://github.com/hofstadter-io/cuelm Many more CUE experiments are going on in the devops space
  - AaronFriel 3y ago
    Pulumi has a few languages other than YAML and Pulumi is declarative[1], and the programs you write are only as complex as you want them to be. This python program declares an S3 bucket and declares ten objects to exist in it. from pulumi_aws import s3 bucket = s3.Bucket('bucket') for i in range(10): s3.BucketObject( f'object-{i}', s3.BucketObjectArgs( bucket=bucket.id, key=str(i), ) ) Even so, Pulumi YAML has a "compiler" option, so if you want to write CUE or jsonnet[1], or other[2] languages, it definitely supports that. Disclaimer: I led the YAML project and added the compiler feature at the request of some folks internally looking for CUE support :) [1] https://www.pulumi.com/blog/pulumi-is-imperative-declarative-imperative/ https://www.pulumi.com/blog/pulumi-is-imperative-declarative... [2] https://www.pulumi.com/blog/extending-pulumi-languages-with-yaml-cue-jsonnet-rust/ https://www.pulumi.com/blog/extending-pulumi-languages-with-... [3] https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes-clusters-in-absurd-languages https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes...
    - verdverm 3y ago
      I'm aware of the SDKs, but we don't want them because they are an imperative interface, no matter how you want to spin it as "declarative". I have access to all the imperative constructs in the underlying language and can create conditional execution without restriction. Even if I use the Yaml compiler for CUE (which we did) I still have to write `fn::` strings as keys, which is ugly and not the direction our industry should go. Let's stop putting imperative constructs into string, let's use a better language for configuration, something purpose built, not an SDK in an imperative language. These "fn::" strings are just bringing imperative constructs back into what could have been an actual declarative interface. Note, Pulumi is not alone here, there are lots of people hacking Yaml because they don't know what else there is to do. CEL making it's way to k8s is another specific example. This cannot be the state-of-art in ops, we can do much better, but I get that Pulumi is trying to reach a different set of users than devops and will end up with different choices and tradeoffs (I maintain https://cuetorials.com https://cuetorials.com and am very active in the CUE community)
    - lmm 3y ago
      An imperative for loop is somehow declarative now? Lol.
      - verdverm 3y ago
        you can have loops and still be declarative, CUE has loops, though they are considered comprehensions more technically, but there is no assignment or stack in CUE One of the interesting aspects of CUE is that it gives us many of the programming constructs we are used to, but remains Turing incomplete, so no general recursion or user defined functions. There is a scripting layer where you can get more real world stuff done too The CUE language is super interesting, has a very unique take on things and comes from the same heritage as Go, containers, and Kubernetes https://cuelang.org https://cuelang.org | https://cuetorials.com https://cuetorials.com
      - jjnoakes 3y ago
        This seems extremely dismissive and shallow. The imperative part of that code appears to be analogous to templating. The actual work done under the covers is not imperative, but is based on the difference between the result of the template execution and the current state of the system. That's what makes it declarative.
i_am_jl 3y ago
You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products. Read benevolently it's a prohibition from spinning up a service based on HashiCorp's code and undercutting HashiCorp's pricing. On the other hand, if I build a product with HashiCorp-owned BSL'd code, then HashiCorp releases/acquires a product that competes with mine, then my license is void.
- verdverm 3y ago
  My understanding is that the aforementioned companies' licenses are to the same effect, so what is the difference?
  - i_am_jl 3y ago
    Redis is 3-clause BSD, BSD does not have a "your license is void if you sell a product that competes with us" clause. Redis does have enterprise products that are licensed in a manner similar to BSL, but Redis itself is not. MongoDB and Elastic are SSPL. SSPL approaches the problem like the AGPL; it compels licensees who sell a service derived from the software to make available under the SSPL the source of all supporting tooling and software so that a user could spin up their own version of the service. There's an argument to be made that SSPL is de facto "you can't compete with us" since it would be more challenging to make a competitive SaaS offering if your whole stack is source available. I don't disagree. However, as distasteful as SSPL is, at least it doesn't grant licensing to a product conditionally on the unknowable future product offerings of HashiCorp.
    - verdverm 3y ago
      thanks for the explanation, my understanding is that they are all after limiting competition in various ways, while still trying to maintain the mantle of open source We are certainly in interesting times around the monetization / financial sustainability of open source
  - bit_flipper 3y ago