Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Follow the wormhole through a path of communities !webdev@programming.dev
I understand their reasoning, but am still left disappointed.
I honestly don’t.
AWS and other cloud providers have already proven, eg. with Mongo and Elastic, that they are perfectly happy to either provide an API compatible offering or just fork the product and then offer the service at a lower price point, which proves again that if the only thing you have to compete is price, you don’t have a competitive product.
That’s where I’m at too. Philosophically its a bummer. For the majority of users of their codebase however, this presents zero changes and the only entity I known of who would be impacted by this change going forward is AWS
So I was trying to figure out what are they getting defensive against. It was clear in redhat’s case, but I only really found pulumi as some sort of alternative to terraform and I’m not even sure it relies on it. What is the AWS product that’s competing here?
Service Catalog has terraform constructs built in now
Pulumi relies on Terraform providers, it can actually “plug in” any Terraform provider. This won’t be much of a problem though, as Hashicorp has pushed the work of developing and maintaining providers to its “partners”. Even providers under the Hashicorp umbrella like AWS is not actively developed by hashicorp personell so there is really no play here, as is reflected by them not touching the license in those repositories.
Curious, how will AWS be affected? I’m not familiar with all of Hashicorp’s tools. Mostly just Terraform (and obvs AWS had Cloud Formation, then CDK - they even worked with HashiCorp I believe to build CDKTF).