troposphere VS cloudformation-resource-providers

Under the IaC category, in July 2023, AWS added loops to CloudFormation, finally ticking a box the community has been asking for since troposphere. I suspect that, in combination with the Terraform licensing changes, it may keep people using CloudFormation for a while longer.

Because ECS Compose-X uses Troposphere, I was able to create a very light and simple python library(https://github.com/JohnPreston/troposphere-awscommunity-applicationautoscaling-scheduledaction) to distribute the resource for other Troposphere users to re-use.

Written in house, but the library troposphere is the primary component of how it is built. Example stacks are here.

I am kind of going off topic here, but isn't the point of being an SA to be created with code services to deliver solutions at scale that are cost-effective? How in the hell can you do that when you can't write a simple Python template that generates code at 50 times the rate you can manually? How can you ever be expected to deploy a serverless solution if you can't write any code yourself? There has to be some level of proficiency there.

Wouldn't using troposphere[1] be easier?

[1] https://github.com/cloudtools/troposphere

You might have seen some tutorials on how to set up S3 buckets using the AWS Console. This works fine, but I'm a firm believer of managing your resources with code. I've chosen the native solution of AWS, called AWS CloudFormation. This makes it easier to reproduce the setup if I ever need to tear it down of move it to another account or region. Below is the full CloudFormation template, I've used a framework called Troposphere, a Python library that creates CloudFormation.

For CF for example I no longer write template in yaml or shudders json, and instead I use troposphere.

refer : https://github.com/cloudtools/troposphere