16 ms·

Pulumi – Modern Infrastructure as Code

380 points by evo_9 7y ago

dcardoza 7y ago
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?
- beaker52 7y ago
  Less community support, due to popularity. Yes, it's nice to write it in code, but you can achieve similar with raw Terraform and there are more documented examples for that, plus if it goes wrong, you can find others facing the same issues, usually with resolutions/workarounds etc. I wanted to find Pulumi more useful than I really did.
  - cactus2093 7y ago
    I've used Terraform quite a bit (though less in the past year), and the things that ended up being the biggest headaches for me were: 1. State quickly gets unwieldy and terraform plans get very slow. I think the official recommendation is to split it up to separate instances using separate state files, but that adds complexity of finding the right seams and sharing any needed data between them. 2. Desperately needs a good way to do singletons. Many modules end up fitting the pattern that you need 1 each of some underlying resources (iam role, iam policy, s3 bucket, kms key, whatever) that could be shared by every instance of the thing you're creating. But you have to decide between keeping the code clear and organized and putting those things in the module next to the resources that rely on them, but then duplicating these things N times unnecessarily (which adds to the problem of bloated, slow state). Or you keep the shared resource outside of the module, which makes the code less clear, bloats the global namespace/tf files and requires passing around even more state variables to the module. 3. Tools for abstractions and structuring the app are lacking in general in other ways. Modules are the only thing you have and they were intended to be standalone for sharing code externally and are clunky when using them only within your own app to organize code. There's no way to import shared constants or even group related variables together into something like structs, so you end up needing to pass around the same handful of individual variables into almost every module and resource you create. 4. Your whole terraform config is only as stable as the worst implemented resources. I think this problem is even worse for smaller, community support-only providers but even within AWS, it's not uncommon to come across bugs in how different services are integrated into terraform. Sometimes useful parameters are missing, or terraform doesn't validate them the same way as AWS itself causing something in your apply to fail halfway through, or things are implemented such that the subsequent tf plan still doesn't show up clean after a successful apply. TF has gotten more stable over time, but there still seems to be an endless long-tail of leaky abstraction type issues like these. This turned into kind of a long list of gripes, but I'd be very curious to hear from anyone who has used both Pulumi and Terraform in production how Pulumi compares on these painpoints in particular.
    - mixedCase 7y ago
      > 1. Start with one per environment. As it grows, you can identify the reusable patterns and move those to their own state files and import them wholesale with terraform_remote_state. It's code, treat it like code. > 2. A module for shared resources, a module for resources that use them. You don't bloat anything if you just namespace it and then pass the shared resources' output as an entire object to a parameter in the resources that share them. > 3. Same answer. You can create objects for your outputs where you can easily namespace things. > 4. This is true. But there's no better way for obvious reasons. It's a high level abstraction, the only alternative is to use low level abstractions, at which point you're just doing shell scripts. Which, by the way, Terraform has pretty clever ways to integrate. It's not pretty, but it's isolated ugliness much like unsafe Rust/C# where you really need to instead of having to go full ugly. Also, you can always submit pull requests to Terraform providers. Doesn't guarantee the maintainers will be active enough to respond and upstream it, but it will solve the issue cleanly for you and other people at least in the meantime.
- tlarkworthy 7y ago
  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...
  - hinkley 7y ago
    You can’t step through declarative code in a debugger. That’s a problem for discoverability, which also means more friction for new learners.
    - hombre_fatal 7y ago
      You've already lost big if you ever need a debugger to understand code. Especially if your beginners have to use it just to wrap their head around wtf is happening. And having to run your "config files" just to see what they're doing is the huge downside of using programming languages as config. In other words, it's kind of circular to point out that using code for config puts you in a situation where you might have to use a debugger to know what your config does.
      - hinkley 7y ago
        You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? There’s a middle ground that you see with a number of test frameworks, Gulp, SCons and I suspect with Pulumi, where the outer shell of imperative code is in practice declarative, and the inner bits are properly imperative. Part of the code says why to do something, and the rest says how to do it. For instance I don’t see a huge conceptual difference between disabling or filtering a test, versus not deploying a service because it is running, current, and healthy.
        tedivm 7y ago
        > You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? To me that sounds like a failure state.
- zinclozenge 7y ago
  No built-in remote state backend storage (s3, gcs, etc) locking except their proprietary hosting. Obviously they need to make money, but this makes driving migration from terraform to pulumi a lot more difficult.
  - flurie 7y ago
    This was true when it was first released, but they now allow you to bring your own backend store. https://www.pulumi.com/docs/intro/concepts/state/ https://www.pulumi.com/docs/intro/concepts/state/
    - terrorbilly 7y ago
      It's specifically the state-locking feature that's missing from 3rd party backends.
    - edaemon 7y ago
      That page lists this as a feature of their service, implying it isn't available in other backend stores: Concurrent state locking to prevent corrupting your infrastructure state in a team environment
  - kraig 7y ago
    I've got a PR opened to implement this but due to S3 CAP limitations, it hasn't been merged. The current state is that it could be merged for non-S3 backends and a DynamoDB type lock could be added for S3 backends. I don't have much interest to keep pushing it forward (its been nearly a year of "ill get back to you next week") although their new VP has been more responsive. Alternately I was considering just implementing the server API to do state storage & locking, but we have implemented some workarounds that are good enough for now.
    - terrorbilly 7y ago
      I just want to say thanks for your initiative on opening https://github.com/pulumi/pulumi/pull/2697 https://github.com/pulumi/pulumi/pull/2697. (I've seen you active on a few other issues and in the Slack channel too) I think it's really unfortunate (whatever the reason) that the team was this slow to provide meaningful feedback on the PR.
ruffrey 7y ago
How does it handle idempotence?
- croddin 7y ago
  Basically by having promises which can resolve to existing resources or new resources.
patrickaljord 7y ago
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
lycidas 7y ago
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?
- AzzieElbab 7y ago
  Hashicorp is a bit more than just Terraform. 20m sounds plentiful for what pulumi does
- macca321 7y ago
  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
  - sergiovmdo 7y ago
    llelele
- jordanbeiber 7y ago
  I have found that the best way to use terraform is to let it be declarative and generate what you need as json (from some api or tooling). Much less issues this way, and the json is actually what will happen with resources at a given provider. Once you start to use imperative stuff you lose a bit of predictability - your entire configuration is no longer declared, it just kinda looks that way.
- 7y ago
Legogris 7y ago
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 7y ago
  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.
1f60c 7y ago
It’s all still a little abstract to me but it looks promising.
primitivesuave 7y ago
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.
tutfbhuf 7y ago
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.
mister_hn 7y ago
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 7y ago
  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 7y ago
    but there's Proxmox, which is free
    - kiney 7y ago
      but the proxmox devs seem to have no interest in terraform (or pulumi) support
      - mister_hn 7y ago
        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.
nikolay 7y ago
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 7y ago
  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.
terrorbilly 7y ago
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 7y ago
  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@.
AaronFriel 7y ago
I've been using Pulumi for about a year for deploying stateful and stateless services on Google Cloud Platform, AMA.
- broth 7y ago
  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 7y ago
    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.
nunez 7y ago
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.
gregwebs 7y ago
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.
- MuffinFlavored 7y ago
  How does it stack up to Terraform?
  - gregwebs 7y ago
    As a first impression it is more user friendly. The support for working with secrets is nice, but on the other hand it doesn't come free with locking support. We need more time to evaluate the stability.
- mwcampbell 7y ago
  Do you also build container images through Pulumi, or do you do that separately through your CI system? Also, do you use Pulumi in your developer inner loop, or something else?
  - gregwebs 7y ago
    We build images in CI and reference that in Pulumi. Not sure what your question is, we use this to deploy an infrastructure environment that includes k8s.
- darkwater 7y ago
  > 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?
CSDude 7y ago
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.
sandGorgon 7y ago
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 7y ago
  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-pulumi/ https://www.pulumi.com/blog/if-you-liked-ksonnet-youll-love-...
yingw787 7y ago
This sounds like a compiler! Front-end which is some programming language, and backend targets being Terraform / CloudFormation / etc.
- jen20 7y ago
  It's no accident that many of the original team were compiler or CLR engineers ;-)
debaserab2 7y ago
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 7y ago
  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.
- pldr2244 7y ago
  Ironically, having used both, Pulumi’s APIs are much cleaner/simpler than AWS CDK’s. I feel CDK was overengineered when I last used it. Pulumi has been a breath of fresh air.
- cheese4242 7y ago
  Does AWS CDK handle state drift and state transitions in the same way Terraform/Pulumi does? I believe AWS CDK uses CloudFormation under the hood which can not "intelligently" fix state drift in the same way Terraform can. CF can only tell you that tthee state has drifted, but cannot actually figure out how to fix that drift which IMO is one of the biggest strikes against CF. The "State" section of this article has a better description of what I'm talking about: https://medium.com/@endofcake/terraform-vs-cloudformation-1d9716122623 https://medium.com/@endofcake/terraform-vs-cloudformation-1d...
Nihilartikel 7y ago
I'd really like to try using this from ClojureScript.
renewiltord 7y ago
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.
mayank 7y ago
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 7y ago
  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#usage https://github.com/pulumi/tf2pulumi/blob/master/README.md#us.... 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/#transformations https://www.pulumi.com/docs/intro/concepts/programming-model... [2] https://www.pulumi.com/docs/intro/concepts/programming-model/#import https://www.pulumi.com/docs/intro/concepts/programming-model...
sashavingardt2 7y ago
I'm absolutely in love with pulumi. Recommended it to a CTO I was interviewing with literally an hour ago!
sashavingardt2 7y ago
My current fave - Pulumi + JS + Ramda
ludwigvan 7y ago
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.
kalium_xyz 7y ago
Switched from nixops to pulumi, found it much easier to use.
Sytten 7y ago
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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
beders 7y ago
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?
- throwaway894345 7y ago
  > You want to make the same change to 20 scripts? Trivial with a declarative language you can parse easily. You have this exactly backwards. You don't need to make the same change to 20 scripts because you have a real programming language; reuse is built-in. > 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? What options do you have for simplifying YAML except to generate it programmatically?
- crispyporkbites 7y ago
  If your DevOps team can’t code you don’t have a DevOps team, you have an Ops team
  - m1keil 7y ago
    this is just wrong. a) it was never about ops writing code b) ops always wrote code.
- cheese4242 7y ago
  The "Rule of Least Power" comes to mind: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
  - throwaway894345 7y ago
    People forget that the "rule of least power" is "the language with the least power suitable for the task". The question is whether YAML/HCL are suitable for the task to begin with. The following facts all testify that it is not, and that the principle of least power favors "real programming languages": * CloudFormation hacks things like references, nested-stacks, macros, imports, etc onto YAML * HCL becomes more powerful with each version * Helm generates YAML with templates and recently added support for Lua * AWS is building its CDK, which generates CloudFormation with programming languages * Things like Terraform and Pulumi exist
moondev 7y ago
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.
- peterwwillis 7y ago
  There is no real world site reliability benefit to declarative over imperative. They are just software design paradigms. You still have to design the software to not suck. People spend loads of engineering effort (years, really) to get that controller to function properly under every weird state case, while the neckbeard with a shell script, hot failover master-master write nodes and an ELB gets five nines without needing a CS degree.
  - moondev 7y ago
    I think the benefit is not needing to grok, debug or re-invent every neckbeard's special shell script. Just declare your desired state and move on to other things.
    - cheese4242 7y ago
      Agreed. What concerns me somewhat about Pulumi is we will lose some of "standardization" that comes with the widespread use of Terraform. Like anything else, it is possible to write Terraform in an incomprehensible way. However, overall I have found that Terraform "constricts" things into being done a certain way. This allows engineers to jump into a new TF codebase and grok what is happening fairly easily. Now with Pulumi, we lose that constraint, and now have to grok not only the different languages that infra is defined in, but also the wide variety of different "styles" that a language can be written in. An engineer joining from another company or team now has to deal with a new language and a new code style/organization in order to wrap their head around the infra. Not a desirable property when it comes to managing the infrastructure for a company. While it is appealing that a developer can use a language they are already familiar with to manage infra, that only holds true if the language being used for Pulumi is one they are already familiar with. I could of course be totally wrong. Regardless, I am excited to see a new contender in the space.
AzzieElbab 7y ago
Really wish they would take reasonml seriously
zoltrain 7y ago
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.

380 points by evo_9 7y ago

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?

beaker52 7y ago
Less community support, due to popularity. Yes, it's nice to write it in code, but you can achieve similar with raw Terraform and there are more documented examples for that, plus if it goes wrong, you can find others facing the same issues, usually with resolutions/workarounds etc. I wanted to find Pulumi more useful than I really did.
- cactus2093 7y ago
  I've used Terraform quite a bit (though less in the past year), and the things that ended up being the biggest headaches for me were: 1. State quickly gets unwieldy and terraform plans get very slow. I think the official recommendation is to split it up to separate instances using separate state files, but that adds complexity of finding the right seams and sharing any needed data between them. 2. Desperately needs a good way to do singletons. Many modules end up fitting the pattern that you need 1 each of some underlying resources (iam role, iam policy, s3 bucket, kms key, whatever) that could be shared by every instance of the thing you're creating. But you have to decide between keeping the code clear and organized and putting those things in the module next to the resources that rely on them, but then duplicating these things N times unnecessarily (which adds to the problem of bloated, slow state). Or you keep the shared resource outside of the module, which makes the code less clear, bloats the global namespace/tf files and requires passing around even more state variables to the module. 3. Tools for abstractions and structuring the app are lacking in general in other ways. Modules are the only thing you have and they were intended to be standalone for sharing code externally and are clunky when using them only within your own app to organize code. There's no way to import shared constants or even group related variables together into something like structs, so you end up needing to pass around the same handful of individual variables into almost every module and resource you create. 4. Your whole terraform config is only as stable as the worst implemented resources. I think this problem is even worse for smaller, community support-only providers but even within AWS, it's not uncommon to come across bugs in how different services are integrated into terraform. Sometimes useful parameters are missing, or terraform doesn't validate them the same way as AWS itself causing something in your apply to fail halfway through, or things are implemented such that the subsequent tf plan still doesn't show up clean after a successful apply. TF has gotten more stable over time, but there still seems to be an endless long-tail of leaky abstraction type issues like these. This turned into kind of a long list of gripes, but I'd be very curious to hear from anyone who has used both Pulumi and Terraform in production how Pulumi compares on these painpoints in particular.
  - mixedCase 7y ago
    > 1. Start with one per environment. As it grows, you can identify the reusable patterns and move those to their own state files and import them wholesale with terraform_remote_state. It's code, treat it like code. > 2. A module for shared resources, a module for resources that use them. You don't bloat anything if you just namespace it and then pass the shared resources' output as an entire object to a parameter in the resources that share them. > 3. Same answer. You can create objects for your outputs where you can easily namespace things. > 4. This is true. But there's no better way for obvious reasons. It's a high level abstraction, the only alternative is to use low level abstractions, at which point you're just doing shell scripts. Which, by the way, Terraform has pretty clever ways to integrate. It's not pretty, but it's isolated ugliness much like unsafe Rust/C# where you really need to instead of having to go full ugly. Also, you can always submit pull requests to Terraform providers. Doesn't guarantee the maintainers will be active enough to respond and upstream it, but it will solve the issue cleanly for you and other people at least in the meantime.
tlarkworthy 7y ago
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...
- hinkley 7y ago
  You can’t step through declarative code in a debugger. That’s a problem for discoverability, which also means more friction for new learners.
  - hombre_fatal 7y ago
    You've already lost big if you ever need a debugger to understand code. Especially if your beginners have to use it just to wrap their head around wtf is happening. And having to run your "config files" just to see what they're doing is the huge downside of using programming languages as config. In other words, it's kind of circular to point out that using code for config puts you in a situation where you might have to use a debugger to know what your config does.
    - hinkley 7y ago
      You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? There’s a middle ground that you see with a number of test frameworks, Gulp, SCons and I suspect with Pulumi, where the outer shell of imperative code is in practice declarative, and the inner bits are properly imperative. Part of the code says why to do something, and the rest says how to do it. For instance I don’t see a huge conceptual difference between disabling or filtering a test, versus not deploying a service because it is running, current, and healthy.
      - tedivm 7y ago
        > You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs? To me that sounds like a failure state.
zinclozenge 7y ago
No built-in remote state backend storage (s3, gcs, etc) locking except their proprietary hosting. Obviously they need to make money, but this makes driving migration from terraform to pulumi a lot more difficult.
- flurie 7y ago
  This was true when it was first released, but they now allow you to bring your own backend store. https://www.pulumi.com/docs/intro/concepts/state/ https://www.pulumi.com/docs/intro/concepts/state/
  - terrorbilly 7y ago
    It's specifically the state-locking feature that's missing from 3rd party backends.
  - edaemon 7y ago
    That page lists this as a feature of their service, implying it isn't available in other backend stores: Concurrent state locking to prevent corrupting your infrastructure state in a team environment
- kraig 7y ago
  I've got a PR opened to implement this but due to S3 CAP limitations, it hasn't been merged. The current state is that it could be merged for non-S3 backends and a DynamoDB type lock could be added for S3 backends. I don't have much interest to keep pushing it forward (its been nearly a year of "ill get back to you next week") although their new VP has been more responsive. Alternately I was considering just implementing the server API to do state storage & locking, but we have implemented some workarounds that are good enough for now.
  - terrorbilly 7y ago
    I just want to say thanks for your initiative on opening https://github.com/pulumi/pulumi/pull/2697 https://github.com/pulumi/pulumi/pull/2697. (I've seen you active on a few other issues and in the Slack channel too) I think it's really unfortunate (whatever the reason) that the team was this slow to provide meaningful feedback on the PR.

ruffrey 7y ago

How does it handle idempotence?

croddin 7y ago
Basically by having promises which can resolve to existing resources or new resources.

patrickaljord 7y ago

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

lycidas 7y ago

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?

AzzieElbab 7y ago
Hashicorp is a bit more than just Terraform. 20m sounds plentiful for what pulumi does
macca321 7y ago
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
- sergiovmdo 7y ago
  llelele
jordanbeiber 7y ago
I have found that the best way to use terraform is to let it be declarative and generate what you need as json (from some api or tooling). Much less issues this way, and the json is actually what will happen with resources at a given provider. Once you start to use imperative stuff you lose a bit of predictability - your entire configuration is no longer declared, it just kinda looks that way.
7y ago

Legogris 7y ago

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 7y ago
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.

1f60c 7y ago

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

primitivesuave 7y ago

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.

tutfbhuf 7y ago

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.

mister_hn 7y ago

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 7y ago
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 7y ago
  but there's Proxmox, which is free
  - kiney 7y ago
    but the proxmox devs seem to have no interest in terraform (or pulumi) support
    - mister_hn 7y ago
      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.

nikolay 7y ago

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 7y ago
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.

terrorbilly 7y ago

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 7y ago
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@.

AaronFriel 7y ago

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

broth 7y ago
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 7y ago
  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.

nunez 7y ago

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.

gregwebs 7y ago

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.

MuffinFlavored 7y ago
How does it stack up to Terraform?
- gregwebs 7y ago
  As a first impression it is more user friendly. The support for working with secrets is nice, but on the other hand it doesn't come free with locking support. We need more time to evaluate the stability.
mwcampbell 7y ago
Do you also build container images through Pulumi, or do you do that separately through your CI system? Also, do you use Pulumi in your developer inner loop, or something else?
- gregwebs 7y ago
  We build images in CI and reference that in Pulumi. Not sure what your question is, we use this to deploy an infrastructure environment that includes k8s.
darkwater 7y ago
> 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?

CSDude 7y ago

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.

sandGorgon 7y ago

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 7y ago
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-pulumi/ https://www.pulumi.com/blog/if-you-liked-ksonnet-youll-love-...

yingw787 7y ago

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

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

debaserab2 7y ago

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 7y ago
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.
pldr2244 7y ago
Ironically, having used both, Pulumi’s APIs are much cleaner/simpler than AWS CDK’s. I feel CDK was overengineered when I last used it. Pulumi has been a breath of fresh air.
cheese4242 7y ago
Does AWS CDK handle state drift and state transitions in the same way Terraform/Pulumi does? I believe AWS CDK uses CloudFormation under the hood which can not "intelligently" fix state drift in the same way Terraform can. CF can only tell you that tthee state has drifted, but cannot actually figure out how to fix that drift which IMO is one of the biggest strikes against CF. The "State" section of this article has a better description of what I'm talking about: https://medium.com/@endofcake/terraform-vs-cloudformation-1d9716122623 https://medium.com/@endofcake/terraform-vs-cloudformation-1d...

Nihilartikel 7y ago

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

renewiltord 7y ago

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.

mayank 7y ago

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 7y ago
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#usage https://github.com/pulumi/tf2pulumi/blob/master/README.md#us.... 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/#transformations https://www.pulumi.com/docs/intro/concepts/programming-model... [2] https://www.pulumi.com/docs/intro/concepts/programming-model/#import https://www.pulumi.com/docs/intro/concepts/programming-model...

sashavingardt2 7y ago

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

sashavingardt2 7y ago

My current fave - Pulumi + JS + Ramda

ludwigvan 7y ago

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.

kalium_xyz 7y ago

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

Sytten 7y ago

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 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.

beders 7y ago

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?

throwaway894345 7y ago
> You want to make the same change to 20 scripts? Trivial with a declarative language you can parse easily. You have this exactly backwards. You don't need to make the same change to 20 scripts because you have a real programming language; reuse is built-in. > 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? What options do you have for simplifying YAML except to generate it programmatically?
crispyporkbites 7y ago
If your DevOps team can’t code you don’t have a DevOps team, you have an Ops team
- m1keil 7y ago
  this is just wrong. a) it was never about ops writing code b) ops always wrote code.
cheese4242 7y ago
The "Rule of Least Power" comes to mind: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power
- throwaway894345 7y ago
  People forget that the "rule of least power" is "the language with the least power suitable for the task". The question is whether YAML/HCL are suitable for the task to begin with. The following facts all testify that it is not, and that the principle of least power favors "real programming languages": * CloudFormation hacks things like references, nested-stacks, macros, imports, etc onto YAML * HCL becomes more powerful with each version * Helm generates YAML with templates and recently added support for Lua * AWS is building its CDK, which generates CloudFormation with programming languages * Things like Terraform and Pulumi exist

moondev 7y ago

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.

peterwwillis 7y ago
There is no real world site reliability benefit to declarative over imperative. They are just software design paradigms. You still have to design the software to not suck. People spend loads of engineering effort (years, really) to get that controller to function properly under every weird state case, while the neckbeard with a shell script, hot failover master-master write nodes and an ELB gets five nines without needing a CS degree.
- moondev 7y ago
  I think the benefit is not needing to grok, debug or re-invent every neckbeard's special shell script. Just declare your desired state and move on to other things.
  - cheese4242 7y ago
    Agreed. What concerns me somewhat about Pulumi is we will lose some of "standardization" that comes with the widespread use of Terraform. Like anything else, it is possible to write Terraform in an incomprehensible way. However, overall I have found that Terraform "constricts" things into being done a certain way. This allows engineers to jump into a new TF codebase and grok what is happening fairly easily. Now with Pulumi, we lose that constraint, and now have to grok not only the different languages that infra is defined in, but also the wide variety of different "styles" that a language can be written in. An engineer joining from another company or team now has to deal with a new language and a new code style/organization in order to wrap their head around the infra. Not a desirable property when it comes to managing the infrastructure for a company. While it is appealing that a developer can use a language they are already familiar with to manage infra, that only holds true if the language being used for Pulumi is one they are already familiar with. I could of course be totally wrong. Regardless, I am excited to see a new contender in the space.

AzzieElbab 7y ago

Really wish they would take reasonml seriously

zoltrain 7y ago

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.