
Pulumi – Modern Infrastructure as Code - evo_9
https://www.pulumi.com/
======
dcardoza
I have been wanting to try Pulumi out for a while. As an avid terraform user,
I welcome the ability to use a proper language instead of the declarative HCL.
For those who have migrated from terraform -> Pulumi, what are the biggest
cons you've experienced?

~~~
tlarkworthy
I witness the same mentality in sbt users, Turing computable > declarative. I
don't get it though.

In both the build system and the deploy system, I want to know the config
terminates, and I want it to be easy to understand. The application's
specialization is Turing computability. I prefer that footgun to stay isolated
there. But maybe there is a use case I don't get.

Imagine accidentally provisioning infinite VMs...

~~~
lukehoban
[disclaimer: CTO at Pulumi so clearly biased :-)]

One of the things I really believe is that you can have the best of both
worlds here. Pulumi uses imperative programming languages, but is still
"declarative". The imperative programs are executed to build up the desired
state, which can then be reliably diff'd and previewed, and can be used to
enforce manual or automatic checks for correctness. So you get the
expressiveness of imperative programs (loops, conditionals, components,
packages, versioning, IDE tooling, testing, error checking, etc.), but still
the safeguards and reliability of declarative infrastructure-as-code (preview,
gated deployments, policy enforcement, etc.).

I also tend to view the perceived benefits of JSON/YAML/HCL "simplicity" as
somewhat comparing apples to oranges on a complexity specturm. If you are only
managing a dozen resources, it may be that JSON/YAML/HCL are fundamentally
simpler. But when you've copy/pasted tens of thousands of lines of YAML around
all over your codebase to manage hundreds or thousands of resources, the value
of abstraction, reuse, well defined interfaces, and tooling to manage that
complexity feels to me essential to the scale of the problem. And that degree
of complexity is no longer just something large organizations are dealing
with. Modern cloud technologies (serverless, containers, Kubernetes, etc.) are
leading to significant increases in the number of cloud resources being
managed, and the pace at which those resource are deployed and updated.

Assembly is a "simpler" way to think about programming, but didn't scale as
complexity of application software increases. I believe the same is true about
JSON/YAML/HCL and cloud infrastructure.

~~~
mixedCase
> But when you've copy/pasted tens of thousands of lines of YAML around all
> over your codebase to manage hundreds or thousands of resources, the value
> of abstraction, reuse, well defined interfaces, and tooling to manage that
> complexity feels to me essential to the scale of the problem.

You're lumping in HCL (and languages like Dhall by extension) with static
serialization formats and criticizing them for a characteristic only found in
the latter.

HCL is programmable and has a fair model for code reusability through modules,
state outputs, for-expressions and other kinds of expressions.

Add in a proper language with types like Dhall and you have a configuration
language where you can apply all the transformations you could want with a
much higher safety and robustness floor than a turing-complete language that
allows you to make all sorts of messes.

It's specially dangerous to have a turing-complete language for configuration
once you factor in that the reflex of an inexperienced developer who is more
likely to make these messes is to use a tool they're already familiar with
even when the tool is actively harmful to their goals, as Pulumi facilitates.

~~~
joeduffy
[Disclaimer: also member of the Pulumi team.]

We've worked with a lot of end users to migrate from Terraform, and we
honestly do see a lot of copy-and-paste. I agree that it's not as rampant as
with YAML/JSON, however, in practice we find a lot of folks struggle to share
and reuse their Terraform configs for a variety of reasons.

Even though HCL2 introduced some basic "programming" constructs, it's a far
cry from the expressiveness of a language like Python. We frequently see not
only better reuse but significant reduction in lines of code when migrating.
Being able to create a function or class to capture a frequent pattern, easily
loop over some data structure (e.g., for every AZ in this region, create a
subnet), or even conditionals for specialization (e.g., maybe your production
environment is slightly different than development, us-east-1 is different,
etc). And linters, test tools, IDEs, etc just work.

For comparison, this Amazon VPC example may be worth checking out:

\- Terraform: [https://github.com/terraform-aws-modules/terraform-aws-
vpc/b...](https://github.com/terraform-aws-modules/terraform-aws-
vpc/blob/master/main.tf)

\- Pulumi (Python): [https://github.com/joeduffy/pulumi-
architectures/blob/master...](https://github.com/joeduffy/pulumi-
architectures/blob/master/aws-py-base-infra/__main__.py)

\- CloudFormation: [https://github.com/aws-quickstart/quickstart-aws-
vpc/blob/ma...](https://github.com/aws-quickstart/quickstart-aws-
vpc/blob/master/templates/aws-vpc.template)

It's common to see a 10x reduction in LOCs going from CloudFormation to
Terraform and a 10x reduction further going from Terraform to Pulumi.

A key importance in how Pulumi works is that everything centers around the
declarative goal state. You are shown previews of this (graphically in the
CLI, you can serialize that as a plan, you always have full diffs of what the
tool is doing and has done. This helps to avoid some of the "danger" of having
a turing-complete language. Plus, I prefer having a familiar language with
familiar control constructs, rather than learning a proprietary language that
the industry generally isn't supporting or aware of (schools teach Python --
they don't teach HCL).

In any case, we appreciate the feedback and discussion -- all great and valid
points to be thinking about -- HTH.

~~~
pm90
> It's common to see a 10x reduction in LOCs going from CloudFormation to
> Terraform and a 10x reduction further going from Terraform to Pulumi.

I don't see this as such a terrible problem. The configurations may have more
LOC's but there are not as many surprises. The dependency of declarable
configuration makes it rock solid and favorable among operations teams who
need to make these kinds of changes all the time.

> A key importance in how Pulumi works is that everything centers around the
> declarative goal state. You are shown previews of this (graphically in the
> CLI, you can serialize that as a plan, you always have full diffs of what
> the tool is doing and has done. This helps to avoid some of the "danger" of
> having a turing-complete language. Plus, I prefer having a familiar language
> with familiar control constructs, rather than learning a proprietary
> language that the industry generally isn't supporting or aware of (schools
> teach Python -- they don't teach HCL).

I understand the reason to want this. Having worked closely with developers,
lack of familiarity with HCL makes it much less accessible. However, from an
operations perspective, I am GLAD that HCL is a very limited language. No
imports of libraries all over the place (in your infrastructure
configurations, no less!).

~~~
throwaway894345
> I don't see this as such a terrible problem. The configurations may have
> more LOC's but there are not as many surprises. The dependency of declarable
> configuration makes it rock solid and favorable among operations teams who
> need to make these kinds of changes all the time.

The issue is that your static configs often have lots of boilerplate sections
that have to be kept in sync. Further, you can use an imperative language like
Python, JS, etc and still write in a completely declarative fashion (or you
can use a functional language which tend to be declarative out of the box).
Conversely, you can model an AST in YAML (which is what CloudFormation is
trending toward) and get the worst of all worlds. Bottom line: don't conflate
"reusability" with "imperative" or "static" with "declarative".

~~~
pm90
> The issue is that your static configs often have lots of boilerplate
> sections that have to be kept in sync.

Yes, I agree with this. However, its predictable. As an operations person, I
value predictability and am willing to pay the price of keeping static configs
in sync.

> Further, you can use an imperative language like Python, JS, etc and still
> write in a completely declarative fashion (or you can use a functional
> language which tend to be declarative out of the box). Conversely, you can
> model an AST in YAML (which is what CloudFormation is trending toward) and
> get the worst of all worlds. Bottom line: don't conflate "reusability" with
> "imperative" or "static" with "declarative".

Hold on, I'm not conflating anything. Saying that "you can write terrible
things in any language" isn't anything new. We choose to use languages that
provide certain guarantees that we need for the domain that we're working in.
For infrastructure, declarative languages are a lot more suitable for the
properties they provide (i.e. no surprises, limited functionality etc.). Its
"possible" to use static types in Python, how many do that?

~~~
throwaway894345
> Yes, I agree with this. However, its predictable. As an operations person, I
> value predictability and am willing to pay the price of keeping static
> configs in sync.

I think there's wisdom in this at small scales, but as the volume and
complexity of your boilerplate grows, I think you lose any advantages. I also
think this threshold is quite low (as an ops person and a dev person) since
it's not much harder to look at/read the YAML generated by a script vs that
which is hand-rolled and committed to git.

> Hold on, I'm not conflating anything.

Are you sure? Because you just said "I am willing to pay the price of keeping
__static __configs sync " and then "For infrastructure, __declarative
__languages are a lot more suitable for the properties they provide " and then
you started to talk about "static types" in Python, which is different than
"static" in the YAML sense (YAML isn't statically typed, but it is static in
that it isn't evaluated or executed).

I'm not trying to be a jerk, it just sounds like a lot of concepts are being
confused. I also wasn't making the argument "you can write terrible things in
any language" (not sure if you were attributing that argument to me or if that
was a point you were trying to make).

Consider this Python:
[https://github.com/weberc2/nimbus/blob/master/examples/src/n...](https://github.com/weberc2/nimbus/blob/master/examples/src/nimbus_examples/s3bucket.py)

It's fully _declarative_ , but it does _evaluate_ , so it's not static in the
YAML sense. It outputs a JSON CloudFormation template (but it could easily
output in YAML) which you could inspect visually before passing onto
CloudFormation.

It's also _statically typed_ although that's not evident from this file since
all types are inferred in this file (however there are annotations in the
imported libraries), and while the static typing is a very useful property,
it's not what I've been talking about in this thread.

In my opinion, this is no less readable than the equivalent YAML; however,
it's capable of doing much more (albeit if your infrastructure is just one S3
bucket, then this is overkill--to really understand the power of dynamic
configuration, you would want a more complex example).

------
ludwigvan
I love Pulumi. It's a joy to use a proper programming language to manage
infra.

I wish more tools would adapt this. I find it mind boggling that it is very
hard to use ansible modules in a Python program for example. That would make
things much easier to compose.

------
lycidas
I've been looking at this for awhile and it's super cool! As a person who's
used Terraform extensively and has ran into a lot of issues with it's
declarative, non-scriptability (at least before 0.12), pulumi seems great. And
it's also great its able to wrap any Terraform-compatible provider out of the
box.

One question I have for anyone who's used it or the team if they're here is
how they convinced their company to use it? Last time I checked pulumi was a
small company with only 20M in funding versus hashicorp which was more
established. What happens if the pulumi team runs out of money and we've moved
all our infra onto pulumi?

~~~
macca321
Pulumi is great, but I gave up on persuading a company with a lot of existing
terraform to move to yet another tool, and created a (pretty basic)
DSL/library for writing terraform in python/c#, which can output to terraform.
I could probably get permission to open source it if people are interested. *

As far as I can tell, you get more or less the same benefits as you would if
you use pulumi (in the same ballpark).

* There are one or two tools for python/ruby that do this already, but having it in something with stronger typing has advantatages

------
moondev
Perhaps i'm misunderstanding but this seems to convert a declarative workflow
into an imperative one. Doesn't this seem backwards?

Kubernetes manifests are declarative by design and for good reason, the
controllers reconcile the state not your script.

Interested to hear Pulumi examples where this is desired and where it fits in
with other tools.

~~~
levi_b
[disclaimer: I work at Pulumi]

The Pulumi engine uses a desired state model[1]. You can use imperative
language features like loops and conditionals, but all of that gets mapped to
a declarative resource graph prior to diffs/updates.

[1] [https://www.pulumi.com/docs/intro/concepts/how-pulumi-
works/](https://www.pulumi.com/docs/intro/concepts/how-pulumi-works/)

~~~
moondev
Thanks for sharing! Interested to try this out

------
gregwebs
We switched to Pulumi from terraform for a new project because we can use it
for both cloud infrastructure and for k8s configuration. It is easy enough to
just apply k8s configuration files you have, but it is harder to delete the
k8s resources in all places when you delete a k8s configuration file.

Operationally they can be thought of as working in exactly the same way: they
compare desired configuration, already applied configuration, and observed
configuration.

~~~
darkwater
> We switched to Pulumi from terraform for a new project because we can use it
> for both cloud infrastructure and for k8s configuration.

Did you think about using the kubernetes provider in Terraform to manage K8S
as well?

~~~
gregwebs
Yes. Pulumi supports using existing yaml and helm templates (we aren't really
using this yet), so I think it's support is better. But it may have been more
influenced by the thought of having to deal with k8s boilerplate configuration
in terraform's HCL. The team wanted something that was "easier to template',
but I didn't want to use any template languages.

------
mayank
I deal with a 40k line Terraform codebase. I love the idea of a more
expressive language for infrastructure (and unit tests, validations, etc.),
and even wrote a tiny JS library a long time ago for generating TF 0.11 from
JS [1]

However, the migration paths laid out in the Pulumi docs are completely
intractable for a codebase this size [2]. I'd love to give Pulumi a try, but
it would only work if you could auto-generate a corresponding JS project
structure from the various .tf modules and .tfstate files. Right now, it looks
like tf2pulumi just spits out a single stream to stdout, which won't work for
large projects like mine.

If anyone from Pulumi is here, are there any plans to make tf2pulumi a more
"first-class" migration method?

[1] [https://github.com/mayanklahiri/node-genesis-
device](https://github.com/mayanklahiri/node-genesis-device)

[2]
[https://www.pulumi.com/docs/guides/adopting/from_terraform/](https://www.pulumi.com/docs/guides/adopting/from_terraform/)

~~~
lukehoban
We’ve worked with several Pulumi users who have migrated thousands of
resources (including in production) from being managed by Terraform to being
managed by Pulumi - so this is definitely possible.

We’re actively working on an overhaul of the tf2pulumi tool to support more
Pulumi languages and more breath of Terraform project structures. But already
it should support the majority of adoption use cases.

At-scale adoption can be done in Pulumi by combining transformations [1] and
imports [2]. Together, these allow programmatically importing existing
resources without the need for manual steps.

See the section on adopting in the docs here for details:
[https://github.com/pulumi/tf2pulumi/blob/master/README.md#us...](https://github.com/pulumi/tf2pulumi/blob/master/README.md#usage).

If you have more detailed questions on this - feel free to reach out on the
Pulumi Community Slack (I’m @luke) for a deeper discussion:
[https://slack.pulumi.com/](https://slack.pulumi.com/)

[1] [https://www.pulumi.com/docs/intro/concepts/programming-
model...](https://www.pulumi.com/docs/intro/concepts/programming-
model/#transformations) [2]
[https://www.pulumi.com/docs/intro/concepts/programming-
model...](https://www.pulumi.com/docs/intro/concepts/programming-
model/#import)

------
patrickaljord
I'll be interviewing one of the core dev of Pulumi tonight if you're
interested, he'll be doing a demo too and taking questions
[https://youtu.be/Sy_4KueoTUA](https://youtu.be/Sy_4KueoTUA)

------
mister_hn
I welcome a new tool that competes with Terraform, but I have 2 negative
points:

\- where's the option to deploy to self hosted infrastructure? (E.g. Proxmox,
vCenter, ESX)

\- what's the "Pulumi service" and why can I self host it, but cannot deploy
services to self hosted Infrastructure?

~~~
jen20
ESXi is indeed available as a target (here: [https://github.com/pulumi/pulumi-
vsphere](https://github.com/pulumi/pulumi-vsphere)).

The reasons that self-hosted infrastructure is less prevalent in tools such as
Pulumi (and Terraform) are many - not least demand - but one reason is that
vendors make it INCREDIBLY difficult to test thanks to proprietary license
costs.

I brought up an ESXi provider for Terraform in 2015, and VMWare were not even
remotely interested in giving us the ability to test it via a license grant,
and I was obviously not about to pay VMWare to test integration for a product
I don't even use. In the end I never released or upstreamed it, preferring to
work on targets whose vendors were more co-operative.

~~~
mister_hn
but there's Proxmox, which is free

~~~
kiney
but the proxmox devs seem to have no interest in terraform (or pulumi) support

~~~
mister_hn
why not? There's a REST API and I don't think Amazon devs actively developed
modules for terraform or pulumi, but the way around...so the pulumi devs seem
to have no interest in Proxmox support.

------
debaserab2
I recently picked up AWS CDK and have been enjoying using it more than
something like terra form.

I wonder how this compares - aside from the obvious plus of being platform
agnostic (which in my case doesn’t matter)

~~~
Trisell
I’ve enjoyed the CDK. I looked at Pulumi, but settled on CDK because it’s AWS
developed. As where I work is an AWS shop, I didn’t see many advantages to
Pulumi, and I felt more confident in AWS continuing development and support,
vs another 3rd party company that could go out of business.

Also I really have enjoyed the built in unit test tooling of the CDK. Unit
testing my infrastructure code has been a game changer.

------
zoltrain
So I've been trying out Pulumi at the new company I've just started working at
and I can say the experience so far has been pretty awesome. This coming from
a pre-version 1 user of terraform (when pretty much the only support was the
AWS provider). For me HCL was never the killer feature of Terraform, I
personally think it was the resource abstraction and providers that made it
the best choice at the time. Chef/Ansible runs were always dangerous because
as most of us will know from hard learnt lessons, "what you see isn't
necessarily what you get". Having a DAG, tracking dependencies between
resources, and getting a "this is what you have, this is what you'll get" when
you apply a change is the core of what makes terraform great... but this isn't
the language, I'd actually argue HCL is where most of it's problems were. The
hacks one had to make before HCL 2.0 to get any type of reuse were to be
frank, awful. They were also non-obvious, so you had to either pass the
knowledge on in your team like a "sage" which isn't scalable for
smaller/midsize teams, or let people hit those walls and waste more collective
time. Writing languages is hard, and it took Hashicorp years to get it
"mostly" right. Though the ergonomics of HCL I would still say aren't very
nice or very developer friendly.

Now to Pulumi's merits, if you dive into it's architecture you'll find it's
actually users from terraform providers under the hood (very well tested code
bases). So it will do things like build a DAG, track dependencies, and give
you a diff before you apply anything. From what I can tell it's just changed
how you interact with the terraform internals (I'm sure it's more complicated
than this, but this is my simple understanding of it). Sure you can get code
ordering problems, like any imperative language but it doesn't make it any
more unsafe to run as you're protected by the same plan/apply type setup as
Terraform. You can also rely on the same language specific quality controls
you already rely on. Things like unit tests, integration tests, code coverage,
IDE integration etc. Personally I think a better use of time is teaching team
members about the infrastructure fundamentals who have an interest in learning
them, over getting them to also split focus on a language they will only use
in one situation.

------
beders
Can your DevOps read and manipulate code? If no, don't adopt a tool like this.
Your Ops guys will hate you.

Furthermore, the code can't be analyzed very well with tools. (aka gradle vs.
maven)

You want to make the same change to 20 scripts? Trivial with a declarative
language you can parse easily.

Non-trivial if you have code. You better have those re-factoring tools at
hand.

If you environment requires complex scripts to get up and running, that is a
strong hint that you are not done yet. Can it be simplified further?

~~~
crispyporkbites
If your DevOps team can’t code you don’t have a DevOps team, you have an Ops
team

~~~
m1keil
this is just wrong. a) it was never about ops writing code b) ops always wrote
code.

------
AaronFriel
I've been using Pulumi for about a year for deploying stateful and stateless
services on Google Cloud Platform, AMA.

~~~
broth
Questions:

1\. Have you ever used Terraform? If so, how does Pulumi compare?

2\. What language do you use with Pulumi?

3\. What is the learning curve like for Pulumi?

4\. What specific actions do you use Pulumi for with GCP?

4a. What have been some hurdles or roadblocks you have faced using Pulumi with
GCP?

5\. Which Pulumi plan (cloud hosted, self hosted, etc.) and how is that
working for you?

~~~
AaronFriel
1\. Yes, not as long professionally. More experience with CloudFormation and
pyplates. Pulumi has libraries that wrap around Terraform providers for some
of its integrations such as Google Cloud Platform.

Terraform pro:

* Simple deployments are fairly easy to grok, the base language is simple to understand

Terraform con:

* Advanced deployments, using templates, modules, functions is nontrivial to teach and error-prone.

For my use case, we have multiple environments - as most folks do - and we
also have several "micro-service" like services deployed each with its own
configuration. It's very easy to write a function that generates these
variations:

    
    
        function someResource(args, additionalOptions, etc.) { }
    

This is much easier to teach, and so I would argue that Terraform solves for a
case that doesn't really exist in many businesses.

2\. TypeScript

3\. The getting started information is fairly solid, I didn't have a lot of
difficulty getting started.

4\. Primarily Kubernetes resources on GKE, service accounts and tokens, Cloud
SQL, storage buckets, and so on. Creating a service account, a database or
storage bucket, and then linking that into a Kubernetes secret is pretty
simple.

4a. I did hit a bug where Pulumi handled poorly a resource which I manually
deleted in GCP. I had a Cloud SQL instance (Postgres), a User in that instance
and a Database in that instance. (Cloud SQL instances can contain multiple
databases). I manually deleted the three of these, and Pulumi had trouble
trying to unwind state if I recall. The bug is here:
[https://github.com/pulumi/pulumi-
gcp/issues/268](https://github.com/pulumi/pulumi-gcp/issues/268)

5\. We aren't a paying customer - our needs around compliance mean we need to
run it self hosted, and Pulumi's CLI is OSS so we are using the Pulumi CLI and
some really hacky shell scripts to emulate a "server" and prevent reentrancy,
effectively treating Pulumi deploys as critical sections. We have no plans to
release these scripts. I understand they've recently added a self hosted
option, but we haven't had time to evaluate.

------
sandGorgon
Since Pulumi extends to the k8s configuration world as well - i wonder what
the Pulumi devs think of jsonnet and cue (previous discussion here -
[https://news.ycombinator.com/item?id=20362951](https://news.ycombinator.com/item?id=20362951)
and
[https://news.ycombinator.com/item?id=20847943](https://news.ycombinator.com/item?id=20847943))

~~~
lukehoban
This post has some thoughts on ksonnet compared to Pulumi (and generally
applies to comparison with the variety of other similar tools in that space):
[https://www.pulumi.com/blog/if-you-liked-ksonnet-youll-
love-...](https://www.pulumi.com/blog/if-you-liked-ksonnet-youll-love-pulumi/)

------
Sytten
How is the support for AWS ECS? I really like terraform, but it is pretty bad
at handling changes made to the task definition outside of it. Most of it is
due to the declarative nature of the thing (You cant at the same time fetch
the latest resource and create one if it doesn't exist). So the hacks we have
to do to make it work with CD are just plain bad. I am considering moving our
stack to pulumi (3k lines of terraform).

------
dagss
I'm new to this so stupid question ahead.

The thing I don't like about Pulumi (or Terraform) is saving a copy of the
state (locally or on a server). This seems finicky. Isn't the current state
right there in the cloud, available through APIs? Why keep a "propriotary"
copy? It seems like a "what could possibly go wrong" kind of design choice.

~~~
zapita
The Pulumi/Terraform state contains more than a local copy of the last known
actual state of your resources. It also contains information about the desired
state is, which parts of the last known state were mutated by Pulumi/Terraform
itself as opposed to external/unknown changes, etc. They are complementary.

~~~
dagss
Relying on that extra information you talk about sound like a liability more
than anything else to me.

Why is there a need for anything else than a) the desired state (in the code)
and b) the current state in the cloud?

The need for any extra state beyond that makes me dubious about the approach,
fills me with fear and doubt about whether I really understand what the tool
is doing, and so on. (I'm sure I can be wrong about this -- I'm just
describing where I come from, and what I am seeking an answer to.)

Complexity always comes from state, why does one not try to have as little of
it as possible...

~~~
zapita
You are correct that state is hard to manage, and consequently, the less state
you have to manage, the better.

The developers of Terraform and Pulumi know this, but chose to make their
tools stateful anyway. That's because if they were stateless, while they would
certainly be less of a pain to manage, they would also not be as useful.

For example, without state, the tool wouldn't know what resources it has
provisioned in the past. Consequently, it also wouldn't know what resources it
can safely remove or modify.

Another example is that, without state, the tool cannot detect when a resource
needs to be re-created from scratch, and when it simply needs to be renamed
because the operator made a typo in the previous run.

In summary, yes state is hard, but sometimes you just need it to get the job
done.

------
renewiltord
I really like the idea of Pulumi but I haven't really used it. To be honest,
I'm not in an environment where I need to do this. A couple of scripts do the
trick just as fast when combined with some clicking through.

Some things that annoyed me about TF and made me look at Pulumi actually were:

\- Doing anything with loops in TF is a nightmare, and especially if you have
to do things like sharding. We had a sharded KV store that was sort of
optimized for our environment at my previous job and the monstrosity that you
have with `count.idx` and whatnot is just ugh.

\- There's a lot of repetition. Often, even with module-use you end up copy-
pasting a bunch of code.

------
nikolay
I like it, but anybody I pitched it to was like: "Ewww, TypeScript for Infra.
Thanks, but no thanks!" It's using declarative infrastructure as imperative. I
recently found AsCode [0], which is still Terraform, but maybe better. Pulumi
for months used deprecated Azure stuff, and they didn't fix it. So, you are
always late to the game, unlike when using plain Terraform. Oh, and you also
need an account with them.

[0]: [https://ascode.run/](https://ascode.run/)

~~~
kraig
May be too late for you, but you don't need an account and you can use
terraform providers for anything that isn't currently supported.

------
Legogris
I have not used Pulumi yet, but if anyone has, I'd be curious to hear a major
thing re declarative/procedural (and I'll preface this with that I'm biased
towards declarative for IaaC use-cases):

How does it differ from terraform when it comes to modifications and
teardowns?

In terraform, I can target a module or resource for destruction, which will
tear down the resources targeted and nothing else - esentially the inverse of
the application resulting in creation.

How does this work in pulumi?

~~~
jen20
You can `pulumi destroy --target <urn>` in the same way as you can target a
Terraform destroy.

An important thing that is not as well understood about Pulumi as it should be
is that it does in fact build a declarative model, but using an imperative
language instead of a DSL. Consequently there is not a huge range of
difference in what can achieved from the declarative model.

Disclaimer: I was a Terraform maintainer for a long time, and also contribute
to Pulumi.

------
tutfbhuf
I think we reached a full cycle (again), from turning complete configuration
languages also known as programming languages to plain text files and
everything in between.

------
nunez
Pulumi is awesome as a concept. It worked really well when I used it with
Python. I wish they supported Ruby and had better docs for their Python
client.

------
ruffrey
How does it handle idempotence?

~~~
croddin
Basically by having promises which can resolve to existing resources or new
resources.

------
primitivesuave
This is awesome, can't wait to try it out. We built a bunch of scripts on the
AWS SDK to effectively do this - create new resources while querying for and
editing existing ones. It would be nice to see more detailed docs for APIGWv2
and if there is a way to automate setup/management of both HTTP and WS
instances of API Gateway - this is the closest we get to configuration
nightmare.

------
terrorbilly
I used to love Pulumi - the experience of managing infra + k8s resources with
Typescript's type system is really nice.

However, I've found their support responsiveness via Slack / GH issues to be
poor enough to where I'm strongly considering removing it from our team's
internal tooling setup.

~~~
lukehoban
CTO at Pulumi here. Sorry you didn't get the support you needed! Please do
drop me a DM in the Pulumi slack or email me at luke@.

------
kalium_xyz
Switched from nixops to pulumi, found it much easier to use.

------
yingw787
This sounds like a compiler! Front-end which is some programming language, and
backend targets being Terraform / CloudFormation / etc.

~~~
jen20
It's no accident that many of the original team were compiler or CLR engineers
;-)

------
sashavingardt2
I'm absolutely in love with pulumi. Recommended it to a CTO I was interviewing
with literally an hour ago!

------
1f60c
It’s all still a little abstract to me but it looks promising.

------
Nihilartikel
I'd really like to try using this from ClojureScript.

------
sashavingardt2
My current fave - Pulumi + JS + Ramda

------
AzzieElbab
Really wish they would take reasonml seriously

------
CSDude
We avoid infrastructure deployment codes that needs to store the state. I know
it's easier and faster do that but it feels so unsafe that it has the ability
to delete things. We don't grant delete permissions to our automation and do
deletions by hand.

