Live data from Hacker News

Release of AWS CDKv2 and Construct Hub

aws.amazon.com

41–44 of 44 posts

Re: Release of AWS CDKv2 and Construct Hub

#41

Earlier quoted context omitted.

Pulumi isn't "built on terraform", that's a common misconception. See here: https://www.leebriggs.co.uk/blog/2021/11/06/pulumi-faqs.html

Thanks for the correction! I've never used Pulumi directly, and thought it was just a wrapper around terraform providers. Do you think it changes anything about how I've characterized it above?

Read the link again....you're not wrong:

> Pulumi doesn’t “use” Terraform under the hood at all, it uses Terraform providers in order to map the cloud provider API surface.

Which is a real devious piece of sophistry.

Re: Release of AWS CDKv2 and Construct Hub

#42

Earlier quoted context omitted.

You will never find a tool that does a good job of translating between different platforms like that. The systems are too different, and the details matter too much. The value of being multi-platform is that it lets you manage resources in multiple clouds with the same tool, and coordinate the changes. For example; it would let you have application instances and databases in GCP, and manage your DNS is AWS. When you…

Another real-world example I've used that doesn't even require you to have multi-cloud: deploying an EKS cluster to AWS, deploying charts to EKS and finally creating a CNAME to the ALB in Cloudflare. You could even add Cloudflare Access, Workers etc.

I'd still call that multi-cloud ;)

I've done something similar in the real world. We used cloudflare for our dns / application firewall, but we kept a route53 zone mirrored after cloudflare had a spat of issues. It would have let us switch our dns provider as quickly as dns would allow if we had to drop cloudflare.

Re: Release of AWS CDKv2 and Construct Hub

#43

This is great if you only target AWS and only have a small scope, but for anything else it sucks (just like CloudFormation itself). This is one the main problems with most of the CDK-abstracted SDKs for clouds in general where you're essentially just going to re-implement Terraform or SaltStack or Ansible but with your own code that doesn't have the same portability in technical and human terms. That knowledge about…

I don't get the obsession with ansible and terraform as CF replacements.... When I explored both, I found no way to "translate" an AWS VM into an azure VM, you have to use completely different modules and inputs. Same for just about every module I could find... I see almost no benefit if you're working in one cloud to use a "platform agnostic" tool, if that platform agnostic tool uses platform-specific modules. We tr…

Sounds like you had a bad experience when you tried to set application state (a VM) using a declarative tool (Terraform). That's not very surprising and also not even remotely related to what I wrote.

At the same time, CloudFormation does nothing for Azure, so I don't understand where your comparison is coming from.

CloudFormation can only do AWS. Period. And unless you somehow manage to pin yourself to AWS in a greenfield scenario that means it will not be sufficient.

At the same time, CloudFormation is (in my opinion) a nasty way to describe desired state, and sharing anything (i.e. results) with anything else (i.e. non-AWS systems) is not possible, meaning you have to write something for that yourself.

If you are creating a single AWS account with a VPC, some subnets and a few EC2 instances, you're essentially just doing fake-cloud and you might as well do that in the console with no IaC whatsoever. That is not meant as some weird derogatory statement, but I'm not talking about managing a handful of resources in a single account here. I'm also not talking about a magic multicloud translator, but about IaC orchestration across multiple providers (terraform terminology applied).

If we take AWS out of the equation and look at something else, i.e. Cisco ACI, VMware NSX, Palo Alto, F5, those all have Terraform providers as well. No CloudFormation tho. So what if you're setting up a BGP peering over your DirectConnect, you gonna do the CloudFormation thing on the AWS side and manual configuration on the Palo Alto side? That would require at least 3 different CloudFormation stacks that you manually have to run in the right order.

Re: Release of AWS CDKv2 and Construct Hub

#44

Earlier quoted context omitted.

You will never find a tool that does a good job of translating between different platforms like that. The systems are too different, and the details matter too much. The value of being multi-platform is that it lets you manage resources in multiple clouds with the same tool, and coordinate the changes. For example; it would let you have application instances and databases in GCP, and manage your DNS is AWS. When you…

Another real-world example I've used that doesn't even require you to have multi-cloud: deploying an EKS cluster to AWS, deploying charts to EKS and finally creating a CNAME to the ALB in Cloudflare. You could even add Cloudflare Access, Workers etc.

I'm doing the same thing. First a repo is setup in GitHub using the GitHub provider, when that is done, the base configuration for Flux is added in there and then the lifecycle on that is going to ignore future changes.

Next, an AWS account is generated and then a CIDR is read from Netbox. That is used to create the VPC and subnets, and after that an EKS cluster is created. Next the Kubernetes provider is used to install everything needed for Flux, and it is pointed to the GitHub repo that was setup earlier.

At this point the team that wanted a dedicated Kubernetes cluster can just put their charts and manifests in the github repo and it is automatically deployed.

Post reply on HN