top | item 27438568

(no title)

saurabhnanda | 4 years ago

I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML.

For example, could the following be library functions that you could glue together in the programming language of your choice: (a) get current state of infra, (b) calculate diff between desired state and current state, (c) perform a single step (safely) that represents a granular change in infra, (d) perform a series of steps representing infra changes with safe rollback?

Does something like this already exist?

discuss

order

endymi0n|4 years ago

You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately.

Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential.

I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting.

Experiences appreciated!

saurabhnanda|4 years ago

Pulumi sounds interesting. Spent 10 mins with their marketing website and I'm not very clear whether it is a standalone set of libraries, or do they only work in conjunction with their cloud services. Do you know?

zymhan|4 years ago

My experience is that it was definitely a foot gun.

There are too many ways to write fancy abstractions that are unreadable or not extensible, for example.

pnathan|4 years ago

If I was doing things from the ground up, I'd pulumi it, I believe.

Terraform is, however, optimized for everyone under the bell curve.

ranguna|4 years ago

You also have terraform cdk, which is currently in beta.

bjelly|4 years ago

I'm closely tracking an effort by Microsoft that aims to do a lot of what you're describing since I find myself bridging between these tools and deploying stacks that span tools and roles. [CNAB](https://cnab.io/) and the front-running implementation, [Porter](https://porter.sh/), enable one-step infra deployments, packaged as a single OCI-compatible container, with any number of steps, using the best tools for each of those steps. Think of using aws-cli for some initialization step (create or verify presence of a state bucket), applying some terraform to create infra, and finishing with a helm chart to complete deployment of app components. Each stage in a bundle packages not only the code to run it but also the execution binary of the tool that runs it. The spec and porter are still a moving target but it's a promising space and a nice adjacent evolution of the current state of tooling.