A Public Registry for AWS CloudFormation | Hacker News Reader

A Public Registry for AWS CloudFormation

aws.amazon.com

65 pointsgmays35 comments

Can someone explain to me if people still do new projects using CloudFormation? If so why?

I'm in an enterprise and they do everything with CloudFormation, but it doesn't really make sense to me. None of the code is reusable, it's yaml or json, which isn't easy to write to begin with.

I remember in the early days there were 2 frameworks that would compile to CF. I googled recently and found Lono, and it looks nice, but there's a fraction of the modules available that are available for terraform and getting help is also limited by the number of users. And then there is the big question for me why are building things that make CF look like Terraform[0].

I'm not a fanboy of Terraform either, there's plenty of stuff that I didn't like about it. But even AWS themselves almost seem to have more reusable templates in Terraform than they do CF.

[0] https://lono.cloud/

I enjoy writing near-pristine CloudFormation. My only tweak is that I write "literate" templates in Markdown using ```yaml blocks, then strip everything else out before executing them.

I (re)use a lot of templates as "products", e.g. I have an RDS PostgreSQL template that I've been maintaining and using for years.

CloudFormation modules are great for encapsulation and reuse if you actually have anything you want to reuse at sub-template granularity. I rarely do. For example, we have a bunch of API services that all work the same way. In that case, the granularity of reuse is the template. I don't have a bunch of different services/products that all need to reuse a given resource in the same way.

For the same reason, I'm not very excited by CDK and other CloudFormation-producing tools.

I started mucking around with Terraform, but immediately discovered I needed to create a provider (custom resource). That's an incredibly manual process to begin with, but almost all of it is translating between Terraform representation (structures based on HCL2) and the JSON representation of whatever API you're using. So much translation when 99.999% of the APIs you'll use will be JSON. Aaaaaarrrrghhhh.

Sorry.

> but immediately discovered I needed to create a provider

That doesn't make any sense to me, if you're coming from CloudFormation. What for?

Terraform often doesn't cover complex, less commonly used AWS services or features. For example, practically zero coverage of the entire Media Services suite of products.

And for those edge cases, you can use this: https://registry.terraform.io/providers/hashicorp/aws/latest...

Which still gives all the power of HCL to generate the CF stacks. No need to create a new provider.

Migrating a 1500+ line CloudFormation template to Terraform (with some hope that a little extra flexibility would simplify the solution) only to keep using CloudFormation (through a Terraform-shaped hole) for the most complex parts of the problem... would not have been helpful.

Hence my mention of HCL. Between the language and Terraform modules, you're certainly not just "using CloudFormation through a Terraform-shaped hole". You have proper Terraform available to work with the CF template. You can even fully abstract each resource behind a module 1:1 if you wanted to.

In a way, it's similar to how you'd treat C with inline assembly.

The major benefit of CF (if you don't need to manage non-AWS resources) are rollbacks. Basically, in almost all situations, if something cannot be provisioned, or a service doesn't become healthy, CF would roll back to the previous state.

With Terraform you are mostly on your own, and you can easily end up in broken state, which needs to be manually fixed.

> Basically, in almost all situations, if something cannot be provisioned, or a service doesn't become healthy, CF would roll back to the previous state.

Until it doesn't and then you are in a completely unfixable state, must file support tickets and get AWS support to debug it and figure out how to unbork it.

Meanwhile terraform gives you tools to investigate and fix it.

Unless I was doing something really stupid with null_resources, a rollback for me has always been achievable either over a terraform destroy, or a new terraform apply after reverting a commit.

Speaking as someone who works in AWS Support, AWS Support can only support Terraform on a best-effort basis.

There have been many times where someone provides me a small snippet of an error message from Terraform, and the error is so vague as to be useless. I then have to ask the customer for more detailed logging to even figure out what APIs Terraform is even calling. After that I can maybe cobble things together with CloudTrail to figure out the issue.

But that's only because I have personal experience with Terraform. If you get a support agent who isn't familiar with DevOps generally and only knows CloudFormation? You're not going to get the same level of support. Meanwhile, we have a full team and competent internal tooling to troubleshoot CloudFormation. Using Terraform instead of CloudFormation limits the speed and competency of the support you can get from AWS.

Speaking as someone who plays with both at work and personally, here's what I think:

If you're in an AWS monolith with a large team that uses AWS Support as your primary support channel (i.e. you don't have in-house AWS experts), go with CloudFormation. Terraform doesn't do anything on AWS that CloudFormation can't, and AWS can better support you.

If you're in a multi-cloud scenario, it's better to use Terraform (if only because you don't have to learn two different syntaxes).

If you're a one-person shop or don't rely on AWS Support for support? Do whatever you want.

(And while I do work at AWS, please know I could care less whether you use CloudFormation. I'd rather you use the tool best for the job, even if it isn't an AWS product. While some people may conspiratorially say that AWS tries to lock you into AWS services to the exclusion of anything else, most people at AWS just want you to use the right tool for the right job. I have no problem telling someone not to use AWS if it doesn't work for their usecase -- nor do most of my co-workers)

Main reasons to use CF over TF in the AWS world include: rollbacks (giving you some form of transactionality), better understanding of success criteria (though arguably Terraform now can understand what it means for an ECS deployment to succeed), and more complete support for newer features.

I would argue against your final point. They may support some features that Terraform does not, but on the whole I would expect Terraform to have a more complete feature-set than CloudFormation.

All I’m saying is that many new features are supported by CF first, for obvious reasons. Overall though yes, TF has a broader feature set and better documentation. I generally prefer to read TF AWS docs to reading AWS’ own, even outside of TF context.

Lots of early infra as "code" used yaml. But I certainly don't touch any IaC stuff that wouldn't allow me to easily move between vendors. AWS have terraform because it can drive adoption.

It is in Amazon's interest to drive lock-in and it certainly seems their biggest goal.

If you don't like Terraform, perhaps you would consider Pulumi? It's similar, but doesn't pretend that yaml is sufficient. Infrastructure as Actual Code.

https://www.pulumi.com/

Keen to hear of similar tools myself.

> But I certainly don‘t touch any IaC stuff that wouldn‘t allow me easily move between vendors.

How does Terraform achieve that better than CF besides that it has the ability to provision other providers? If you want to switch from say AWS to Azure, you are still required to reconfigure each and every resource as they are named differently, behave probably differently and have different parameters. In that time you probably have learned the equivalent of CF in Azure (if there is some).

It‘s not unachievable, but saying it‘s „easy“ is far away from the truth.

How does terraform make it easy to move between vendors when CF doesn't allow it at all?

Is that actually a question you are seriously asking?

The providers for AWS/Azure/Openstack/VSphere look very similar, to the extent that terragrunt templates can smooth over the differences.

Calling renaming provider resources 'reconfiguring' is a stretch. If that's the worst thing you ever have to do, then I would suggest you're not doing much that is complicated in this space at all.

Because this can be done piecemeal and in place. Additionally if you use modules and the like it can be done in swaths without issue. Additionally you can tie things across domains. Use Route53 with Azure servers, etc.

If you've spent the last 7 years writing CloudFormation scripts, why would you bother switching? If you're starting from scratch today, though, i agree that Terraform is better for most use cases.

CDK is backwards compatible with CFN templates and could act as a drop in replacement. IaC improves DX and saves so much more time, compared to debugging JSON/YML.

I haven't used CDK - you recommend it over Terraform then?

> writing CloudFormation scripts

templates, not scripts, Declarative. And CFN is much more lean and reliable than TF, I recommend it for new to AWS people.

Most of the CloudFormation files I've seen were painfully imperative.

lol

Everyone I talk to hates CF and is moving to or already exclusively using Terraform.

Terraform is not exactly something people I know love. We accept its existence and that’s it.

Yep, everyone loves it in the beginning and then the warts start to show. It's a really bad feeling when you get stuck not being able to do something in HCL. Then you Google it and find 50 other people had the same issue and were told _you're not supposed to do that_

> and then the warts start to show.

It's warts, all the way down.

I didn't say I liked it, just made an observation.

When API keys are involved, I need a lot more confidence in the security of the software than what I am seeing so far.

I'm willing to trust Datadog for configuring their own services, but the community providers scare me from a security perspective. What I can see from the early uploads are community providers accessing secrets manager to fetch API keys. What happens when a provider requests permissions for all secrets? How well will the UI surface broad permission grants? What if providers bake in "telemetry" to spy on me ?

The biggest issue with CF and CDK is the lack of support for features when they launch in the CLI and WebConsole.

One controversial opinion: I feel AWS should reduce surface area and deprecate the CLI in favor of CDK (requiring CDK support for launching a new service and/or feature). To emulate the deprecated AWS CLI, developers can write/edit "CDK scripts" that are uploaded via an AWS CLI-lite.

Disclaimer: I work at Amazon, but not on AWS and have no insight or influence over anything AWS does. Please read this as "just another developer who uses AWS".

Ah I just can't get into the CDK. I much prefer just writing the JSON Cloudformation and executing it via the cli...

Yes the CDK is a major step backwards. Just because you can reduce reuse doesn’t mean you should.

Operations is an exercise in complexity management, not feeling smart.

Sure, I’m happy for other people to use CF over CDK.

I mostly mean to say AWS doesn’t need a full featured CLI. Devs should just use CF/CDK through a CLI-lite.

That also force AWS to block feature launches till CF supports them.

Same, I'd love to see more support on Cloudformation and projects like SAM

Reply on news.ycombinator.com