Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

121–130 of 172 posts

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

#121

Post by katdork »

arkh wrote: post #90
jmspring wrote: post #34

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.

Tried Pulumi thinking "it's gonna abstract all the k8s specifics". Welp no, still need to know and understand K8s so I still don't see the value from those kind of tools. In which case why not use something like Pkl to generate my yaml from some sensible code-like structures?

kubernetes is very complex and therefore any abstraction which completely glosses over the way the underlying systems work would make it very hard to avoid leaking or a bad abstraction to begin with.

the complexity in one way or another must be preserved within the abstraction (in all likelihood) or you will have cases you cannot create in that layer or breakages which now have the total complexity of both the abstraction itself AND kubernetes itself required to fix.

i would not say IaC is going to provide you a magic solution to learning k8s, although the value in using IaC (e.g. Argo CD / Flux CD + Kustomize + ...) in K8s land is that you are no longer imperatively managing your cluster resources and therefore can keep them within a repository, managed like code. the point of the solution is not to make it easier for newcomers, but to make it easier to have teams manage and work together on an established cluster for deployments, ...

in the case of Pulumi, you leverage the single language with typechecking instead of relying upon K8s flavoured YAML, which is itself beneficial in many ways (since you can use your regular developer tooling)

wrt pkl, pretending K8s manifest structure underneath does not help because you will need to know how the keys within a manifest interact with the underlying system regardless, especially to understand functionality, e.g. node selectors, taints and tolerations, node affinity, ...

i prior managed a terraform-based deployment of several k8s clusters and it still required knowledge of those keys and values, alongside knowledge of the underlying resource types.

without those you can't implement things like GPU-based node selection for jobs which require a GPU, ...

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

#122

Post by breendreams »

Longwelwind wrote: post #92
jmspring wrote: post #34

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 differ…

For Terraform, most of the issues with conditionals can be resolved by creating dictionaries dynamically and looping through it to generate resources.

You get the bonus of controlling the resource id and being able to selectively delete resources without worrying about ordering.

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

#123

Post by stackskipton »

raffraffraff wrote: post #85
rwiggins wrote: post #60

Earlier quoted context omitted.

I haven't used Terraform in years (because I changed jobs, not because of the tech itself), but back in the day v0.12 solved most of my gripes. I have always wished they'd implement a better "if" syntax for blocks, because the language itself pseudo-supports it: https://github.com/hashicorp/terraform/issues/21512 But yeah, at $previous_job, Terraform enabled some really fantastic cross-SaaS integrations. Stuff like s…

I get around most of the if stuff using "for each" to iterate over a map. That map might be config (usually from the hiera data provider) or the output of another deployment. It's not generally a very flexible "if" that you need most of the time, it's more like "if this thing exists then create an X for it", or "while crafting X turn this doohickey on of that data set has this flap", which can be accomplished my mung…

Tip for naming, create a naming module where you pass in stuff like product, environment, region, service, have a bunch of locals for each thing like S3 bucket, RDS, EC2, EKS whatever you use then make them all outputs.

So at top of your IaC, you have module naming {variables as inputs} then all other resources are aws_s3 { name = module.naming.s3bucket }

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

#124

Post by otterley »

x0x0 wrote: post #50
turtlebits wrote: post #23

I wish CDK was fully baked enough to actually use. It's still missing coverage for some AWS services (sometimes you have to do things in cloudformation, which sucks) and integrating existing infra doesn't work consistently. Oh and it creates cloudformation stacks behind the scenes and makes for troubleshooting hell.

I also had a really rough go with cdk. I personally found the lack of upsert functionality -- you can't use a resource if it exists or create if it doesn't -- to make it way more effort than I felt was useful. Plus a lack of useful error messages... maybe I'm dumb, but I can't recommend it to small companies.

Upserting resources is an antipattern in cloud resource management. The idiom that works best is to declare all the resources you use and own their lifecycle from cradle to grave.

The problem with upserting is that if the resource already exists, its existing attributes and behavior might be incompatible with the state you're declaring. And it's impossible to devise a general solution that safely transitions an arbitrary resource from state A to state A' in a way that is sure to honor your intent.

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

#125

Post by ngrilly »

striking wrote: post #30
mati365 wrote: post #20

Earlier quoted context omitted.

Why not? Install trafeik or any other load balancer, setup two services, and restart one after one.

https://kamal-deploy.org/docs/configuration/proxy/ I think GP's point was that Kamal has all of these things already, so you don't have to set them up.

Precisely. I've been implementing some kind of blue-green deployment with both systemd and dockerd, but it was an imperfect and incomplete solution. Kamal put much more effort into it and it seems more convenient and reliable (but I haven't tried it yet in production).

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

#126

Post by ngrilly »

stackskipton wrote: post #38
FridgeSeal wrote: post #27

Earlier quoted context omitted.

Ah yes my favourite thing to have to do, rolling my own deploys and rollbacks. It’s stuff like this that’s just a thousand papercuts that dissuades me from using these “simpler” tools. By the time you’ve rebuilt by hand what you need, you’ve just created a worse version of the “more complex” solution. I get it if your workload is so simple ir low requirement that zero-downtime deploys, rollbacks, health/liveness, aut…

Sure but Kumal getting all those features means it strays close to Kubernetes in complexity and it quickly because "Why not Kubernetes? At least that is massive popular with a ton of support."

Kamal is doing most of this, but on a single node. This is the limitation that differentiates it from k8s, but also makes it much simpler.

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

#127

Post by terminalbraid »

spicyusername wrote: post #110
terminalbraid wrote: post #100

Earlier quoted context omitted.

Does Typescript offer a strong type system?

Yes

What's your argument here? For example, Typescript allows lots of operations on objects that cannot be known at compile time because it relies on the user to inform it of types accurately, anything can be coerced into anything without complaint with "as", and it allows for arbitrary operations on an "any" type without complaint.

I've heard it referred to it as an "optionally typed" or "gradually typed" system, which, having worked for years in Typescript and other languages like Rust and Kotlin, etc, I agree with.

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

#128

Post by 878654Tom »

slillibri wrote: post #111
skywhopper wrote: post #109

Earlier quoted context omitted.

They mean var vs local vs from-a-resource. There are some places you can’t use some types of variables. It can be annoying but it’s not really a huge problem if you design your approach with that in mind. The worst part is that the Terraform team at Hashicorp often excuse not fixing these design issues as “safety measures” which isn’t entirely untrue but when over half of your users want something, sometimes you shou…

That makes sense I guess, I just never considered locals or data resources as variables.

Same, locals are in my head like consts. You define it and it stays that way. A shortcut for a repeated value.

Data resources are you requesting a dynamic value of your environment.

Variables are dynamic values that a user can change.

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

#129

Post by kevincox »

arkh wrote: post #91
jnsaff2 wrote: post #83

Earlier quoted context omitted.

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.

And it breaks every time a variable gets a `:` inside of it and now you are producing invalid yaml everywhere you forgot to call `| toYaml`.

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

#130

Post by x0x0 »

otterley wrote: post #124
x0x0 wrote: post #50

Earlier quoted context omitted.

I also had a really rough go with cdk. I personally found the lack of upsert functionality -- you can't use a resource if it exists or create if it doesn't -- to make it way more effort than I felt was useful. Plus a lack of useful error messages... maybe I'm dumb, but I can't recommend it to small companies.

Upserting resources is an antipattern in cloud resource management. The idiom that works best is to declare all the resources you use and own their lifecycle from cradle to grave. The problem with upserting is that if the resource already exists, its existing attributes and behavior might be incompatible with the state you're declaring. And it's impossible to devise a general solution that safely transitions an arbit…

Hmm.

If you don't mind sharing, suppose (because it's what I was doing) I was trying to create personal dev, staging, and prod environments. I want the usual suspects: templated entries in route53, a load balancer, a database, some Fargate, etc.

What are you meant to do here? Thank you.

Post reply on HN