4 ms·
think about huge CloudFormation yaml files with repetitive logic copy pasted, instead, you can build private subnet with couple of code and assign instances usi
by tuyguntn 6y ago
think about huge CloudFormation yaml files with repetitive logic copy pasted, instead, you can build private subnet with couple of code and assign instances using OOP methods.
subnet = aws.vpc.Create()
subnet.Add(webServerInstance)
subnet.Add(appInstance)
appToDB = iam.create('name')
appToDB.add(appInstance)
appToDB.add(rds1)
and so on
- notwedtm 6y agoDoes that make this more akin to Helm for K8S then?
- reilly3000 6y agoIt covers many types of infrastructure outside of K8s. In the sense that you can use it to templatize infrastructure and inject many configs, it can work like helm. You can also use it in many other ways as well- creating your own classes, helper libraries, ternary operators, and all of the comforts of a general purpose language (often with a debugger). Pulumi can deploy existing helm charts- just create a Helm resource, tell it where to look for the helm file, and it will deploy it and own its state moving forward.
- theptip 6y agoI think the apples-to-apples question would be "what's better about this vs. Terraform modules", which is IME the most common approach to composition of infrastructure-as-code right now. Terraform modules are definitely a bit rough in places, for example having to define `variables` and `outputs` at each layer of composition. But on the flip-side, spelunking into TF modules is really easy when you want to figure out what's going on (I can usually make sense of the module from reading the Git repo), and I've found the Pulumi intermediate representation to be significantly harder to grok (especially if you're pointing Pulumi at a Terraform module that they have translated to TypeScript...)