Live data from Hacker News

Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

github.com

91–100 of 172 posts

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#91
post #83

Earlier quoted context omitted.

Because it works fine, and is also used in for other things like Helm Charts? https://helm.sh/docs/chart_template_guide/control_structures...

Helm charts are a horrible example of text based templating. You have YAML/JSON that k8s API wants, that is fed through helm which is fed through helmsman or whatever newer thing. There might be a layer or two of other templating around. Sometimes companies have built systems so developers/devops don't even have the ability to see what the final compiled version of the template is which is like the mother of all: "wo…

> Helm charts are a horrible example of text based templating.

Every time I see " | nindent whatever" I'm asking why the fuck the tool cannot manage indentation.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#92

Pulumi is really a royal piece of shit. Why the f*ck am I writing code to do "deployment". In C# --> new Dictionary when dealing with a values.yaml for instance. The whole need to figure out when and when not to use Apply. Give me Terraform (as much as I hate it) any day.

I would agree with you, if HCL wasn't a bad language in itself:

* You can't make have variables in an import block (for example, to specify a different "id" value for each workspace)

* There is no explicit way to make a resource conditional based on variables. Only a hacky way to do that using "count = foo ? 1 : 0"

* You can't have variables in the backend configuration, making it impossible to store states in different places depending on the environment.

* You can't have variables in the "ignore_changes" field of a resource, making it impossible to dynamically ignore changes for a field (for example, based on module variables).

* The VSCode extension for HCL is slow and buggy. Using TS with pulumi or TFCDK makes it possible to use all the existing tooling of the language.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#93
post #36

Digital Ocean isn't really a "real" cloud. Maybe use Digital Ocean if you're hosting video game servers, but no serious business should be on it.

I wouldn't even use DO for that, unless it's like a private server for just your friends. I won't touch DO after they took my droplet offline for 3 hours because I got DDoS'd by someone that was upset that I banned them from an IRC channel for spamming N-bombs and other racial slurs.

When was this? Now DO and Linode promise full DDOS protection.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#94
post #6

Kubernetes no thanks. Terraform + Kamal [1] on Digital Ocean is the way I deploy/run apps now. [1] https://kamal-deploy.org/

I've looked into Kamal but it feels so "It's as complex as Kubernetes but isn't so support is going to be nightmarish." Why is this better then Ansible + Docker Compose?

Technically, it’s not much different from using Ansible to run Docker on remote hosts.

What it provides is a set of conventions based on what most web apps look like.

Eg. built-in proxy with automatic TLS and zero downtime deployments, first-class support for a DB and cache, encrypted secrets, etc.

It’s definitely not for every use case, but for your typical 3-tier monolith on a handful of servers I found it does the job well.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#95

For anyone deliberating between Pulumi and CDK let me recommend what I consider the best of both worlds: CDKTF, Hashicorp’s answer to Pulimi (my quote not theirs). It’s got everything you want: - strong type system (TS), - full expressive power of a real programming language (TS), - can use every existing terraform provider directly, - compiles to actual Terraform so you can always use that as an escape hatch to debu…

Cdktf is good, but it's not amazing. You are still constrained by terraform syntax like `count = condition? 1 : 0` , instead of doing a normal` if` statement. And there's a fairly good amount of times where you need to use terraform iterators instead of doing a normal for/forEach/map/reduce.

But all in all, it works. It's just a bit limited on what you can do with the actual language.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#97
post #45
post #28

Earlier quoted context omitted.

The biggest hurdle I've encountered is cross-stack resource sharing, especially in case of bidirectional dependencies like KMS keys and IAM roles.

The biggest hurdle is when you want to refactor your stacks, and you pretty well just can't, without risk of deleting everything

There are deletion protection flags that can be enabled.

But circular dependencies can also lead to issues here where CDK will prevent you from deleting a resource used or referenced by a different stack.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#98
Hetzner has been our "expensive AWS cloud costs" saviour

We've also started switching our custom Docker compose + SSL GitHub Action deployments to use Kamal [1] to take advantage of its nicer remote monitoring features

[1] https://kamal-deploy.org

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#99
post #78

Why's everyone going away from declarative? Terraform, CloudFormation, AWS Copilot etc have a lot of virtues and are programming language agnostic. Using a complex programming language (C++ of the browser world) just for this has a big switching cost. Unless you're all in on TS. And/or have already built a huge complex IaC tower of babel where programming-in-the-large virtues justify it.

Complex programming languages for infrastructure code get used when people who are more comfortable using complex programming languages to solve their problems are given the problem of infrastructure and ops.

It is classic "every problem is a nail to the person with a hammer". Complex languages - by definition - can solve a wider variety of problems than a simple declarative language but - by definition - are less simple.

Complex languages for infra - IMO - are the wrong tool for the wrong job because of the wrong skills and the wrong person. The only reason why inefficiencies like this are ever allowed to happen is money.

"Why hire a dev and an ops when we can hire a single devops for fractionally less?" - some excited business person or some broken dev manager, probably.

Re: Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

#100

For anyone deliberating between Pulumi and CDK let me recommend what I consider the best of both worlds: CDKTF, Hashicorp’s answer to Pulimi (my quote not theirs). It’s got everything you want: - strong type system (TS), - full expressive power of a real programming language (TS), - can use every existing terraform provider directly, - compiles to actual Terraform so you can always use that as an escape hatch to debu…

Does Typescript offer a strong type system?
Post reply on HN