4 ms·
The state of things as I see it: Terraform - (bad) HCL sucks, not a programming language. - (good) One tool for multiple service providers is nice. - (good)
by WatchDog 5y ago
The state of things as I see it:
Terraform
- (bad) HCL sucks, not a programming language.
- (good) One tool for multiple service providers is nice.
- (good) Fully open source.
- (good) directly calling service API's makes it more debuggable, and greater control over performance/time of deployments
- (bad) directly calling service API's makes the agent running the tool a SPOF
Cloudformation
- (bad) YAML sucks, not a programming language.
- (good) managed service, doesn't require an agent to run the deployment
- (bad) often slow, no visibility into what it's doing under the hood
- (bad) AWS specific(yes I know about public registry, but it still requires AWS)
Pulumi
- (good) can use an actual real programming language!!
- (bad) directly calling service API's makes the agent running the tool a SPOF
- (bad) need to be connected to, and have credentials for your environment to develop
- (bad) running your code requires bi-directional communication with the pulumi GRPC api
CDK
- (good) can use an actual real programming language!!
- (good) produces a declarative output
- (bad) dependent on cloudformation
- (unknown) CDK for terraform(I haven't tried this, but it sounds promising)
I don't think we yet have the tool we need, but CDK is pretty close, having a real programming language, that produces a declarative intermediate format, that is then ran by another system, I think is the right approach.
- jchanimal 5y agoThe TypeScript CDK is the best use of TypeScript I've experienced. Just having all the documentation inline is hugely helpful, but the type checking also makes development faster by catching errors before you deploy (or even validate.)
- jen20 5y agoYou're not seeing them strictly correctly, then: All the tools described are declarative. If "directly calling service API's makes the agent running the tool a SPOF" is a "bad" for Terraform, it also must be for Pulumi. The idea that one "need[s] to be connected to, and have credentials for your environment to develop" to use Pulumi is equally true of Terraform, assuming by "credentials" you mean "credentials for the target provisioning platform". The idea that "running your code requires bi-directional communication with the pulumi GRPC api" is also untrue. It's important to be accurate when making these kinds of comparisons, lest you fuel memes instead of providing insight.
- WatchDog 5y agoCDK nor Pulumi are declarative. I've added the "agent SPOF", and "credentials" concern to Pulumi as well, it was an oversight. Admittedly, my experience with Pulumi is pretty small, but I don't think I'm wrong about it needing a connection the pulumi parent process. In-fact I opened an issue with Pulumi about problems with this in 2019, and they still haven't closed it. https://github.com/pulumi/pulumi/issues/3590 https://github.com/pulumi/pulumi/issues/3590
- jen20 5y agoBoth CDK and Pulumi are declarative. The program declares resource desires to an engine, which evaluates a diff and effects change. You cannot instruct the engine what to do, only the desired outcome, which makes it declarative. You are correct there is an engine - I mistakenly mistook that as criticism of the default state back end, which is not required.
- WatchDog 5y agoWell yeah, I mentioned that at the end, CDK just produces a declarative cloudformation output. I think this is a good thing, but I wouldn't say that CDK is declarative, as you don't write declarative code.
- jen20 5y agoYou write code that specifies an outcome, and not steps to get there. That is declarative code, like it or not.
- WatchDog 5y agoYou can write literally anything you want in a CDK/Pulumi program. Depending on how you write it, the outcome could be different every time. The generated outcome, ie a cloudformation template, is absolutely declarative, but the CDK code is not.