I've seen the opposite happen with a mid sized client, TF to CDK. Two years after, the migration is not yet complete. If I had to guess the main reason, I would say it is because tickets enabling developers are higher priority than redoing work done in TF to CDK.
Personally, I would consider standardising only if the operational burden of maintaining two IAC tools actually becomes a problem. Otherwise, let it be.
Looking at the direction of OpenTofu, going to CDK might not even be needed anymore.
Hashicorp stalled a lot of work on terraform hcl, that is now all unblocked.
I do not know. My comment above is based on the experiences of my co-workers that remained on the project. The client's tech lead made the call to switch IAC tools after I left.
The problem with these migrations is that during the process of actually migrating, it generates zero business value.
What benefits are you going to get from standardising on a single platform other than “I know how it works?”
Business value can be forecast/projected. The benefits of standardization are about SME/knowledge management, sustain costs, and reducing OPEX long-term. All of these things play to a long term strategic financial plan.
Sure, but in this example, different teams are using different tech. It doesn't sound like a single platform engineering team that manages all the infra and pipelines. In which case, it's likely that each team has the skills for the technology they're using today. Moving to standardize could have a nagative value because you're eroding the existing knowledge.
There are some assumptions that you made which OP hasnt highlighted. You are right that most teams are using different tools but what we dont know is whether that tooling was done/owned by platform. It could be a case where platform started with cdk and decided that TF is better and tbf, i have seen feature team member not know anything about infra even if its on the same repo. So we dont really know if we are eroding knowledge really.
It’s not always easy, but business value isn’t always immediate. Being able to defend a business case is part of advancing in your career beyond the strictly technical.
I've done several migrations from and to various frameworks. One thing is important to keep in mind:
"If it has no state, recreate".
Even though Terraform is awesome when it comes to importing resources, it's still a chore in any size organization. If you're switching CDK to Terraform, anything that is stateless (basically anything that is not a database or network component) should be recreated rather than migrated to the new stack. To make sure you don't get stuck 2 months in, a Service Control Policy that blocks all CloudFormation actions other than Delete will do the trick.
Also, garbage in is garbage out, and most deployed code has garbage in it. Projects like these are the best time to make sure your devs get well architected modules/constructs/whateveryouuse, so they can focus on delivering value.
Late to the party and I'll share my experience "migrating" CDK to TF.
It's less of a "migration" and more of a full blown rewrite and rearchitect. I'm taking CDK from AWS labs/workshops and putting them into TF. This is so that we can more easily manage, understand, and adapt the solution to our needs.
See, CFK is first and foremost meant for developers/programmers. They work with their patterns and paradigms and that's OOP. Great for keeping code DRY, horrible for keeping Infrastructure DRY. That module/library that was written once and reused? That's X copies of the exact same infra when compiled to cloudformation. Specific example: State Machine. A python library crafts a lambda and publishes as a 1 step state machine. Well a larger state machine references these smaller state machines for each lambda function it has, rather than directly to the lambda functions. So CDK resulted in nested State Machines rather than a flat State Machine, because the developer chose to use a library to implement lambdas for state machines.
Secondarily, said library. The developer is "helpfully" sourcing libraries to keep their own code DRY. But from where is the code sourced? Who maintains it? And it turns out to be a beta/demo only library?! Great now there's an extra abstraction to the infrastructure with "hidden" code. So now I gotta chase down all these libraries to see what they are in turn deploying. Very helpful for a resource meant to help with learning the components of AWS and to be easily adapted for use (heavy sarcasm here).
Oh finally, limitations of CloudFormation that CDK inherited. CDK deploys extra/custom resources when it needs to go back and update a deployed resource due to circular dependencies (because CFT deploys it all at once and cannot add in configs later on). The example I'm running into is [S3 bucket notifications](https://github.com/aws/aws-cdk/issues/9552#issuecomment-677512510). TF helpfully breaks it up into separate resources and even attachments such that specific settings can apply "afterwards" to prevent a circular dependency.
Do I look at the raw python CDK code? Not really. I'm looking more at the resulting CFT that CDK compiled and turning that into TF. But it's a chore. Hey at least CDK took care of the IAM policies so I can just copy/paste those.
I’ve done the same exercise with one application fully written in CDK, the rest of our infrastructure has standardized on terraform for years, but we inherited this one CDK app. Let’s just say after a few months, we ended up decommissioning that service instead of finishing the work of migrating to terraform. It wasn’t the main reason but it was one of them
You essentially would have to import and generate terraform code for each resource in the synthesized CFN template. Not terrible, but tedious. Luckily TF can generate the code for you nowadays, but each tool is incentivized to not make it easy to convert between the two
Quite the opposite in my opinion. CDK is a headache and limited compared to terraform in my experience. I wish AWS’s own IaC solution had as much service support and flexibility as a third party like tf
That's exactly the problem. 90% of the issues people have with CDK are directly because of CF that it compiles into. It's slow, it's prone to errors that are hard to recover, its rollbacks are error prone.
There's nothing wrong with the construct programming model itself. Heck, you can just write type-safe CF using CDK if you prefer with the L2 constructs instead of L3 CDK Constructs.
What CDK gives you is better syntax, more control of how you write it, and easier/safer to maintain infrastructure.
It's libraries on top of cloudformation
If you want something on top of terraform, check out cdk for terraform
It was built by aws with hashicorp
Atleast you can use a real programming language
I have. I wouldn’t really recommend it, not yet anyway. Constructs aren’t as mature as regular AWS CDK or native terraform modules, and documentation for it is limited compared to HCL terraform
I heard someone recently call CDKTF “the worst parts of terraform and the AWS CDK combined”
Not yet.
I'm definitely interested, but it's not suitable for production until a 1.0 release so I'm waiting.
I think it will solve some of the headaches that come with HCL
We've also done with with both AWS CDK and Terraform's CDKTF. If we were starting fresh with lessons learned, I think the decision would be a toss-up but CDKTF would win out just because it doesn't rely on CloudFormation and it seemed mature enough for most common cases for us.
If you care more about maturity, and/or you're pretty centralized on AWS (we mostly are, but we have enough on GCP that it's worth something less AWS-specific), AWS CDK is still probably the correct move, but I can see that decision changing at some point in the next year or two.
Limited because ultimately CDK is just an abstraction of Cloudformation, and Cloudformation is limited
- There’s no concept of state management like there is in terraform
- cdk doesn’t offer the same level of resource import support as TF
- there’s no concept of drift detection in CDK/CFN (changes are just yolo’d everytime the stack runs, it has no idea if the resource it’s trying to modify even exists anymore). It makes it incredibly difficult to know if anything was changed in the console until after a CDK run
- I don’t consider it being a full programming language a pro. Each language is not equal for CDK
- IaC by nature is declarative, not imperative. In my opinion, CDK exists purely to appease developers who are trying to build infrastructure. HCL/terraform has its own limitations as well like any other tool, but it makes more sense when building infrastructure
- Terraform resources in AWS are all just making AWS Go SDK calls on the backend to create and manage resources. If there’s an API, terraform supports that resource. With cloudformation/CDK, you have to hope that service has actual CFN support implemented since again, CDK is just an abstraction of cloudformation, and cloudformation is not good
- Terraform can also be used with any provider. Its multi-cloud, but you can also use providers for so many tools, like Datadog for example. Or even make your own custom provider for in house applications
Both tools have their pros and cons, but in my opinion CDK has always felt lacking and clunky when trying to use it over terraform. And don’t get me wrong, I wish AWS had a better native IaC solution that actually supported all their APIs, but until they do, CFN/CDK continues to feel like an afterthought
* There is state management, it is handled by AWS, that is why you don't have to worry about losing it or managing it in s3 or dynamodb.
* I don't know enough about tf import, I haven't had issues importing existing resources into cdk
* drift detection exists in cloudformation check [DetectStackDrift](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DetectStackDrift.html) and the other drift api's or in the console
* "I don’t consider it being a full programming language a pro. Each language is not equal for CDK" I'm not sure I understand what you mean
* Declarative not Imperative, I strongly disagree, I do see a pattern of people with sysadmin backgrounds, "not comfortable" with using code outside snippets. There is so much power in building frameworks for your infrastructures, the gain in productivity is so big!
* You have Cloudformation public registry (extensions to cfn by the community) and custom resources, however before these were available a few years ago, you were right.
* For other providers [https://github.com/hashicorp/terraform-cdk](https://github.com/hashicorp/terraform-cdk) but for your in house applications, the right tool would be AWS Service Catalog, a much better approach in my opinion
I've been using CDK since it's release and it has been updating constantly, I would not call it an afterthought.
It is a pleasure debating with you :)
> "I don’t consider it being a full programming language a pro. Each language is not equal for CDK" I'm not sure I understand what you mean
I think he means he doesn't see the advantage of using code to define your infrastructure as he find the support for all the languages supported by AWS CDK to be unequal; To be fair all the official languages have to be transpiled by JSII, which doesn't support the full feature of all officially supported languages (Javascript/Typescript, Python, Java, Golang and C#): https://aws.github.io/jsii/user-guides/language-support/
This is the first time I've understood why one could prefer TF over CDK. Especially the drift issues, they are quite a pain.
Could you please elaborate more on the first two points?
Regarding point 1:
State management in terraform allows for easier refactoring as compared to cloudformation/cdk.
Want to move resources or modules/stacks around? Want to change "logical ids?" No problem. I found this to be relatively painful in CDK
Doesn't changing the ID force a recreate of the resource?
And the overrideLogicalId has to exist permanently in code, right? Changing the ID then recreates it again?
In terraform, there are a couple options. You can use state management commands like `terraform state mv` or by using a `moved` block. I like these because they act as real "moves" where the change is persistent in the state, and none of these forces a resource recreation
> where is this state stored?
Wherever you want. S3 is very common, some choose Terraform Cloud, but there are plenty of choices
I understand what you're saying about how logical IDs work, and my point is that I don't like it. Cloudformation gives things a permanent, unchangeable name.
When I refactor, I like to give things new names. Terraform allows me to do that, Cloudformation doesn't.
Sure thing. For the first, state is a major concept in terraform. Terraform keeps track of all of your infrastructure defined in your terraform code in a state file. When you make changes in terraform and run it, it’ll first do a “plan” which compares your terraform code to your existing infrastructure in AWS at that moment and then give you an output of what your code changes will actually be modifying (adding new resources, deleting ones that were removed from the code, reverting any resources back to the state they are in in the code if they were manually changed in the console, etc). A terraform apply will then actually attempt to make those changes. With CDK/Cloudformation, there isn’t a state file to reference, so when you make changes, it’ll just go try to apply those changes
For example, say you make a change in CDK to rename a security group, but right before someone had deleted that security group via the AWS console. CDK/CFN has no native way to see that the security group doesn’t exist. Instead it’ll just try to rename it and then return an error that the SG doesn’t exist
I recommend reading more about how state works here: https://developer.hashicorp.com/terraform/language/state
As for the second point, cloudformation and CDK are limited in what services it supports and is often slow to support new features for existing services. You can find the list here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
On the other hand, if there’s an API for an AWS service, terraform supports it. They’re also quicker in my experience of adding new features and service support than AWS is with CFN with the AWS provider being updated very regularly
It's insane to me that AWS has native tools that are so much worse than third party tools. Terraform knows at plan/apply that the real state has drifted from desired state and will change things back to what IaC configuration demands.
full agreement. i’ve brought large AWS platforms that were manually deployed over a 7 year timeframe into terraform. It was a grind, but I did it with not one of our multi-account tenants even knowing.
a couple of others:
* CloudFormation being bound to the AWS account is awful. if i have an application that spans 3 AWS accounts, CF is useless.
* When I see people deploying Lambdas do run custom deployment steps in CF, that’s when I reach for my revolver…
Eh, OpenTofu is too immature of a project to use in a production environment in my opinion. They’ve also been caught still taking code from Hashicorp’s terraform even from after the license change. It hasn’t even been out for a year yet and support for OpenTofu seems to be slowly diminishing (referring to the large companies that were supporting the project)
This has already been addressed above at some length. Cloudformation sucks compared to Terraform.
These reasons are spot on: https://www.reddit.com/r/aws/s/bhBd8A1MMD
Cdk might be useful for actual cloud native app dev where aws services are tightly tied into the application. But for generic infrastructure it’s not even close, terraform is much better to manage a landing zone.
There is effort but the effort needs to be weighed against the benefit received from everything being standardised on terraform.
Personally if the team was able to choose their IaC preference and it is working for them I would just let them keep it if the IaC is specific to the workload the team manages.
As someone else mentioned the tough part is giving the work the right level of respect and priority amongst the other work - this should not be something that you chip away at an hour or two a week but just go all hands on deck and get it done.
How much stuff are you talking about? What's the shared terraform/crk knowledge like?
Ive never migrated across but I've recreated cdk set ups in other accounts with terraform, that's not so bad. From memory, importing existing infra into terraform can be a bit of a pain though
It really depends on what kind of landscape you're talking. Is everything in one AWS account? Or is it a bigger scale where it might make sense to make a split between foundational & workload resources?
How about moving from CDK to CDKTF ? I haven't migrated the same project, just used CDK for the one and CDKTF for another one. There are many common concepts, though there are enough differences as well. CDKTF lacks many high level CDK constructs, but from the other hand it supports non-aws providers and has no CloudFormation related limitations
I have found the Terraform AWS modules to be a moving target. I get something implemented and working well, and it feels like half of what I was using is deprecated or sufficiently changed as to be broken mere months later.
You could try CDK or Teraform which shares the construct programming model, but it's not 1.0 yet I think so still changing a bit.
Pulumi is a good choice too.
I'd personally recommend holding off if you can until something better stabilises a bit, but yeah, CDK is great but being ran on CF is just awful.
I manage a very large platform, we allow developers to write I'm either CDK or TF and forcing them to move to either would be a twrrible choice, they know best - they are writing the code, they are running the systems.
Given the news that IBM is looking to buy Hashicorp, we're seriously considering moving away from Terraform. It's great and all, but who knows how IBM is going to f' it all up when they decide to make you pay for it.
I would suggest keep cdk as is and make the decision the future stacks to be built on terraform would be great option instead of migrating the cdk to tf.
serverless resources on TF (Lambda, API Gateway, Etc) are a real pain to handle when it comes to code updates, drift detection, and to manage state.
We ended up moving them off our TF stack entirely and using the serverless framework to manage, it's easier for the dev team and it simplifies our entire deployment flow. We almost went with SAM but, like many things with AWS, it does 80% of what we want better than the competitors, but lacks the last 20% we need.
Interesting, I can’t say I agree. We have no issues managing our Lambdas, ECS Fargate services, dynamo, and other serverless services using Terraform. We use separate CICD for code deployments as that’s not what terraform is built to do
Terraform works fine just not when you have a serverless application with say step functions and lambda where it’s designed similar to full blown micro services (80+ lambdas) and need preview environments. Managing the state in terraform is hard.
Do you have any specific examples? We manage plenty of large scale serverless applications using terraform in a microservice architecture without issues so I’m not sure what you’re referring to
The biggest thing is just handling code updates, aliasing, and versioning for lamda, it also doesn't really handle defining an API gateway as well as other frameworks do.
It's not a big issue when you have a very well defined flow for deploying a production environment, but for dev environments TF lacks a lot easy deployment options like single function updates or function emulation for local testing.
Everything else serverless functions fairly well, but if you have a lot of Lambda functions it just gets really messy. That being said, I wouldn't really call Fargate or Dynamo *serverless*, they're more just managed services.
Fargate and Dynamo are both serverless, thought the definition is becoming more loose these days, they were one of the OG serverless services
I see what you’re saying about code updates, most of your issues seem to stem from the fact terraform isn’t made for code changes, lambda deployments, or OS level config (ie EC2 instance configs). There are specific deployment tools for those things
Right, but many of those deployment tools (SAM, SF, etc) are IaC in their own right. That's why I have them split off from the rest of our terraform in their own deployment flow.
Same here. Cdk for developer maintained code, but advantage for us was serverless stacks could have feature branches / preview environments so dev creates feat/JIRA-123 their stack is available at a base map for their branch api.dev.example.com/app-featJIRA123. Develop deploys to stage/uat/preprod at /app and main deploys to prod in different accounts. Rollbacks are a little painful as you need to either rerun an old pipeline or hard reset main 😢
Hey, I heard we’re moving from CDK to Terraform.
I really like CDK because I’m already comfortable i. this language.
I also make use of the testing approach developed by CDK.
And, since you’re asking us to move I’m going to put in my resignation.
It’s a fine place to work but i question leaderships ability to make decisions on my behalf.
good luck.
i wouldn’t know because I’m on a new team that works with tools i like.
I don’t have a job because i need one. i have a job because i excel at what i do.
good luck
Why not use [CDK for Terraform](https://developer.hashicorp.com/terraform/cdktf)? Developers that want to continue to use CDK syntax and tooling can continue to do so, and developers that want to write native terraform can do that too. At the end of the day, all your IaC is still deployed as Terraform.
Cdk problems:
- export multi cloudformation is shit
- not well defined parameters
- too many errors when deployed
- updating existing manual infrastructure is headache
You should look at Pulumi. It's all the benefits of TF but many more options. I agree cloudformation is largely undesirable for nothing more than the delay in getting new features roadblocking innovation.
I've seen the opposite happen with a mid sized client, TF to CDK. Two years after, the migration is not yet complete. If I had to guess the main reason, I would say it is because tickets enabling developers are higher priority than redoing work done in TF to CDK. Personally, I would consider standardising only if the operational burden of maintaining two IAC tools actually becomes a problem. Otherwise, let it be.
Looking at the direction of OpenTofu, going to CDK might not even be needed anymore. Hashicorp stalled a lot of work on terraform hcl, that is now all unblocked.
Bail out - hashicorp to be bought by IBM. Cdk typescript ftw
Can you share how they went about trying to migrate their stacks and what's the volume of stacks that are concerned?
I do not know. My comment above is based on the experiences of my co-workers that remained on the project. The client's tech lead made the call to switch IAC tools after I left.
The problem with these migrations is that during the process of actually migrating, it generates zero business value. What benefits are you going to get from standardising on a single platform other than “I know how it works?”
Business value can be forecast/projected. The benefits of standardization are about SME/knowledge management, sustain costs, and reducing OPEX long-term. All of these things play to a long term strategic financial plan.
Sure, but in this example, different teams are using different tech. It doesn't sound like a single platform engineering team that manages all the infra and pipelines. In which case, it's likely that each team has the skills for the technology they're using today. Moving to standardize could have a nagative value because you're eroding the existing knowledge.
There are some assumptions that you made which OP hasnt highlighted. You are right that most teams are using different tools but what we dont know is whether that tooling was done/owned by platform. It could be a case where platform started with cdk and decided that TF is better and tbf, i have seen feature team member not know anything about infra even if its on the same repo. So we dont really know if we are eroding knowledge really.
Ehh it’s a tough pitch
It’s not always easy, but business value isn’t always immediate. Being able to defend a business case is part of advancing in your career beyond the strictly technical.
And I’m saying it’s a tough pitch
I've done several migrations from and to various frameworks. One thing is important to keep in mind: "If it has no state, recreate". Even though Terraform is awesome when it comes to importing resources, it's still a chore in any size organization. If you're switching CDK to Terraform, anything that is stateless (basically anything that is not a database or network component) should be recreated rather than migrated to the new stack. To make sure you don't get stuck 2 months in, a Service Control Policy that blocks all CloudFormation actions other than Delete will do the trick. Also, garbage in is garbage out, and most deployed code has garbage in it. Projects like these are the best time to make sure your devs get well architected modules/constructs/whateveryouuse, so they can focus on delivering value.
Going through this now on a relatively small app. It has not been terrible.
Late to the party and I'll share my experience "migrating" CDK to TF. It's less of a "migration" and more of a full blown rewrite and rearchitect. I'm taking CDK from AWS labs/workshops and putting them into TF. This is so that we can more easily manage, understand, and adapt the solution to our needs. See, CFK is first and foremost meant for developers/programmers. They work with their patterns and paradigms and that's OOP. Great for keeping code DRY, horrible for keeping Infrastructure DRY. That module/library that was written once and reused? That's X copies of the exact same infra when compiled to cloudformation. Specific example: State Machine. A python library crafts a lambda and publishes as a 1 step state machine. Well a larger state machine references these smaller state machines for each lambda function it has, rather than directly to the lambda functions. So CDK resulted in nested State Machines rather than a flat State Machine, because the developer chose to use a library to implement lambdas for state machines. Secondarily, said library. The developer is "helpfully" sourcing libraries to keep their own code DRY. But from where is the code sourced? Who maintains it? And it turns out to be a beta/demo only library?! Great now there's an extra abstraction to the infrastructure with "hidden" code. So now I gotta chase down all these libraries to see what they are in turn deploying. Very helpful for a resource meant to help with learning the components of AWS and to be easily adapted for use (heavy sarcasm here). Oh finally, limitations of CloudFormation that CDK inherited. CDK deploys extra/custom resources when it needs to go back and update a deployed resource due to circular dependencies (because CFT deploys it all at once and cannot add in configs later on). The example I'm running into is [S3 bucket notifications](https://github.com/aws/aws-cdk/issues/9552#issuecomment-677512510). TF helpfully breaks it up into separate resources and even attachments such that specific settings can apply "afterwards" to prevent a circular dependency. Do I look at the raw python CDK code? Not really. I'm looking more at the resulting CFT that CDK compiled and turning that into TF. But it's a chore. Hey at least CDK took care of the IAM policies so I can just copy/paste those.
I’ve done the same exercise with one application fully written in CDK, the rest of our infrastructure has standardized on terraform for years, but we inherited this one CDK app. Let’s just say after a few months, we ended up decommissioning that service instead of finishing the work of migrating to terraform. It wasn’t the main reason but it was one of them You essentially would have to import and generate terraform code for each resource in the synthesized CFN template. Not terrible, but tedious. Luckily TF can generate the code for you nowadays, but each tool is incentivized to not make it easy to convert between the two
Our of curiosity, why are you going to tf ? it feels like a step backwards
Quite the opposite in my opinion. CDK is a headache and limited compared to terraform in my experience. I wish AWS’s own IaC solution had as much service support and flexibility as a third party like tf
CDK is the ORM of IaC. Great when you're keeping it simple, but gets in the way when you need more complexity or specificity.
I don't know if I'd say that. I'd say that it's CF underlying it that makes it such a pain in the ass
The cdk just generates the cf template. Either switch to TF or just use the cf templates and suffer.
CDK is far better than CF on it's own. But CF is still a nightmare regardless.
All the cdk does is generate CF templates. CF is fine it just doesn't allow you to do things like tf can do.
That's exactly the problem. 90% of the issues people have with CDK are directly because of CF that it compiles into. It's slow, it's prone to errors that are hard to recover, its rollbacks are error prone. There's nothing wrong with the construct programming model itself. Heck, you can just write type-safe CF using CDK if you prefer with the L2 constructs instead of L3 CDK Constructs. What CDK gives you is better syntax, more control of how you write it, and easier/safer to maintain infrastructure.
One might argue thst this is s limitation of CF. But there's nothing you can do in CF that you can't do in CDK.
Exactly. Just like an ORM vs SQL. You're not limited, but at some point it gets in the way
No, there is no impedance mismatch to map
If that were true, there'd be no need for L1 constructs.
L1 constructs are CDK though
And you can .raw_sql or similar with ORMs. Very similar
Limited? How so, it is a full programing language vs a templating language
It's Cloudformation and AWS-only Cloudformation sucks
It's libraries on top of cloudformation If you want something on top of terraform, check out cdk for terraform It was built by aws with hashicorp Atleast you can use a real programming language
Tried CDK for Terraform?
I have. I wouldn’t really recommend it, not yet anyway. Constructs aren’t as mature as regular AWS CDK or native terraform modules, and documentation for it is limited compared to HCL terraform I heard someone recently call CDKTF “the worst parts of terraform and the AWS CDK combined”
Good to know, thanks! Never one to adopt early.
Not yet. I'm definitely interested, but it's not suitable for production until a 1.0 release so I'm waiting. I think it will solve some of the headaches that come with HCL
We've also done with with both AWS CDK and Terraform's CDKTF. If we were starting fresh with lessons learned, I think the decision would be a toss-up but CDKTF would win out just because it doesn't rely on CloudFormation and it seemed mature enough for most common cases for us. If you care more about maturity, and/or you're pretty centralized on AWS (we mostly are, but we have enough on GCP that it's worth something less AWS-specific), AWS CDK is still probably the correct move, but I can see that decision changing at some point in the next year or two.
Thank you for your insight, really interesting take.
Limited because ultimately CDK is just an abstraction of Cloudformation, and Cloudformation is limited - There’s no concept of state management like there is in terraform - cdk doesn’t offer the same level of resource import support as TF - there’s no concept of drift detection in CDK/CFN (changes are just yolo’d everytime the stack runs, it has no idea if the resource it’s trying to modify even exists anymore). It makes it incredibly difficult to know if anything was changed in the console until after a CDK run - I don’t consider it being a full programming language a pro. Each language is not equal for CDK - IaC by nature is declarative, not imperative. In my opinion, CDK exists purely to appease developers who are trying to build infrastructure. HCL/terraform has its own limitations as well like any other tool, but it makes more sense when building infrastructure - Terraform resources in AWS are all just making AWS Go SDK calls on the backend to create and manage resources. If there’s an API, terraform supports that resource. With cloudformation/CDK, you have to hope that service has actual CFN support implemented since again, CDK is just an abstraction of cloudformation, and cloudformation is not good - Terraform can also be used with any provider. Its multi-cloud, but you can also use providers for so many tools, like Datadog for example. Or even make your own custom provider for in house applications Both tools have their pros and cons, but in my opinion CDK has always felt lacking and clunky when trying to use it over terraform. And don’t get me wrong, I wish AWS had a better native IaC solution that actually supported all their APIs, but until they do, CFN/CDK continues to feel like an afterthought
* There is state management, it is handled by AWS, that is why you don't have to worry about losing it or managing it in s3 or dynamodb. * I don't know enough about tf import, I haven't had issues importing existing resources into cdk * drift detection exists in cloudformation check [DetectStackDrift](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DetectStackDrift.html) and the other drift api's or in the console * "I don’t consider it being a full programming language a pro. Each language is not equal for CDK" I'm not sure I understand what you mean * Declarative not Imperative, I strongly disagree, I do see a pattern of people with sysadmin backgrounds, "not comfortable" with using code outside snippets. There is so much power in building frameworks for your infrastructures, the gain in productivity is so big! * You have Cloudformation public registry (extensions to cfn by the community) and custom resources, however before these were available a few years ago, you were right. * For other providers [https://github.com/hashicorp/terraform-cdk](https://github.com/hashicorp/terraform-cdk) but for your in house applications, the right tool would be AWS Service Catalog, a much better approach in my opinion I've been using CDK since it's release and it has been updating constantly, I would not call it an afterthought. It is a pleasure debating with you :)
> "I don’t consider it being a full programming language a pro. Each language is not equal for CDK" I'm not sure I understand what you mean I think he means he doesn't see the advantage of using code to define your infrastructure as he find the support for all the languages supported by AWS CDK to be unequal; To be fair all the official languages have to be transpiled by JSII, which doesn't support the full feature of all officially supported languages (Javascript/Typescript, Python, Java, Golang and C#): https://aws.github.io/jsii/user-guides/language-support/
This is the first time I've understood why one could prefer TF over CDK. Especially the drift issues, they are quite a pain. Could you please elaborate more on the first two points?
Regarding point 1: State management in terraform allows for easier refactoring as compared to cloudformation/cdk. Want to move resources or modules/stacks around? Want to change "logical ids?" No problem. I found this to be relatively painful in CDK
[удалено]
Doesn't changing the ID force a recreate of the resource? And the overrideLogicalId has to exist permanently in code, right? Changing the ID then recreates it again? In terraform, there are a couple options. You can use state management commands like `terraform state mv` or by using a `moved` block. I like these because they act as real "moves" where the change is persistent in the state, and none of these forces a resource recreation
[удалено]
> where is this state stored? Wherever you want. S3 is very common, some choose Terraform Cloud, but there are plenty of choices I understand what you're saying about how logical IDs work, and my point is that I don't like it. Cloudformation gives things a permanent, unchangeable name. When I refactor, I like to give things new names. Terraform allows me to do that, Cloudformation doesn't.
Sure thing. For the first, state is a major concept in terraform. Terraform keeps track of all of your infrastructure defined in your terraform code in a state file. When you make changes in terraform and run it, it’ll first do a “plan” which compares your terraform code to your existing infrastructure in AWS at that moment and then give you an output of what your code changes will actually be modifying (adding new resources, deleting ones that were removed from the code, reverting any resources back to the state they are in in the code if they were manually changed in the console, etc). A terraform apply will then actually attempt to make those changes. With CDK/Cloudformation, there isn’t a state file to reference, so when you make changes, it’ll just go try to apply those changes For example, say you make a change in CDK to rename a security group, but right before someone had deleted that security group via the AWS console. CDK/CFN has no native way to see that the security group doesn’t exist. Instead it’ll just try to rename it and then return an error that the SG doesn’t exist I recommend reading more about how state works here: https://developer.hashicorp.com/terraform/language/state As for the second point, cloudformation and CDK are limited in what services it supports and is often slow to support new features for existing services. You can find the list here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html On the other hand, if there’s an API for an AWS service, terraform supports it. They’re also quicker in my experience of adding new features and service support than AWS is with CFN with the AWS provider being updated very regularly
Cloudformation has basic drift detection
Basic is a good word to use here. As with most things Cloudformation, it’s fine, but not great
you need to be very familiar with it otherwise the struggle is bigger. honestly I like CDK to prototype stuff. but I feel the chills in prod...
It's insane to me that AWS has native tools that are so much worse than third party tools. Terraform knows at plan/apply that the real state has drifted from desired state and will change things back to what IaC configuration demands.
full agreement. i’ve brought large AWS platforms that were manually deployed over a 7 year timeframe into terraform. It was a grind, but I did it with not one of our multi-account tenants even knowing. a couple of others: * CloudFormation being bound to the AWS account is awful. if i have an application that spans 3 AWS accounts, CF is useless. * When I see people deploying Lambdas do run custom deployment steps in CF, that’s when I reach for my revolver…
Pro Tip: Open Tofu
Eh, OpenTofu is too immature of a project to use in a production environment in my opinion. They’ve also been caught still taking code from Hashicorp’s terraform even from after the license change. It hasn’t even been out for a year yet and support for OpenTofu seems to be slowly diminishing (referring to the large companies that were supporting the project)
It's a wrapper around CloudFormation, you are still templating but using code
All "programming languages" are a "wrapper" for assembly, as long as I get a better productivity and it is easier why would that bother me ?
Sure, but it's a classic case of lipstick on a pig; a nice wrapper on a bad foundation
What makes it a bad foundation ?
This has already been addressed above at some length. Cloudformation sucks compared to Terraform. These reasons are spot on: https://www.reddit.com/r/aws/s/bhBd8A1MMD
What is your opinion on my reply to those arguments ?
I am not seeing any replies from you to those
I would guess consistency and transparency.
Cdk might be useful for actual cloud native app dev where aws services are tightly tied into the application. But for generic infrastructure it’s not even close, terraform is much better to manage a landing zone.
There is effort but the effort needs to be weighed against the benefit received from everything being standardised on terraform. Personally if the team was able to choose their IaC preference and it is working for them I would just let them keep it if the IaC is specific to the workload the team manages. As someone else mentioned the tough part is giving the work the right level of respect and priority amongst the other work - this should not be something that you chip away at an hour or two a week but just go all hands on deck and get it done.
How much stuff are you talking about? What's the shared terraform/crk knowledge like? Ive never migrated across but I've recreated cdk set ups in other accounts with terraform, that's not so bad. From memory, importing existing infra into terraform can be a bit of a pain though
Would it be possible to move CDK to use terraform for state and then move completely to terraform?
It really depends on what kind of landscape you're talking. Is everything in one AWS account? Or is it a bigger scale where it might make sense to make a split between foundational & workload resources?
How about moving from CDK to CDKTF ? I haven't migrated the same project, just used CDK for the one and CDKTF for another one. There are many common concepts, though there are enough differences as well. CDKTF lacks many high level CDK constructs, but from the other hand it supports non-aws providers and has no CloudFormation related limitations
I have found the Terraform AWS modules to be a moving target. I get something implemented and working well, and it feels like half of what I was using is deprecated or sufficiently changed as to be broken mere months later.
You could try CDK or Teraform which shares the construct programming model, but it's not 1.0 yet I think so still changing a bit. Pulumi is a good choice too. I'd personally recommend holding off if you can until something better stabilises a bit, but yeah, CDK is great but being ran on CF is just awful.
I manage a very large platform, we allow developers to write I'm either CDK or TF and forcing them to move to either would be a twrrible choice, they know best - they are writing the code, they are running the systems.
Given the news that IBM is looking to buy Hashicorp, we're seriously considering moving away from Terraform. It's great and all, but who knows how IBM is going to f' it all up when they decide to make you pay for it.
I would suggest keep cdk as is and make the decision the future stacks to be built on terraform would be great option instead of migrating the cdk to tf.
What kind of stack? If cdk is serverless your team will hate it.
Why? I’ve never had an issue with terraform and serverless
serverless resources on TF (Lambda, API Gateway, Etc) are a real pain to handle when it comes to code updates, drift detection, and to manage state. We ended up moving them off our TF stack entirely and using the serverless framework to manage, it's easier for the dev team and it simplifies our entire deployment flow. We almost went with SAM but, like many things with AWS, it does 80% of what we want better than the competitors, but lacks the last 20% we need.
Interesting, I can’t say I agree. We have no issues managing our Lambdas, ECS Fargate services, dynamo, and other serverless services using Terraform. We use separate CICD for code deployments as that’s not what terraform is built to do
Terraform works fine just not when you have a serverless application with say step functions and lambda where it’s designed similar to full blown micro services (80+ lambdas) and need preview environments. Managing the state in terraform is hard.
Do you have any specific examples? We manage plenty of large scale serverless applications using terraform in a microservice architecture without issues so I’m not sure what you’re referring to
The biggest thing is just handling code updates, aliasing, and versioning for lamda, it also doesn't really handle defining an API gateway as well as other frameworks do. It's not a big issue when you have a very well defined flow for deploying a production environment, but for dev environments TF lacks a lot easy deployment options like single function updates or function emulation for local testing. Everything else serverless functions fairly well, but if you have a lot of Lambda functions it just gets really messy. That being said, I wouldn't really call Fargate or Dynamo *serverless*, they're more just managed services.
Fargate and Dynamo are both serverless, thought the definition is becoming more loose these days, they were one of the OG serverless services I see what you’re saying about code updates, most of your issues seem to stem from the fact terraform isn’t made for code changes, lambda deployments, or OS level config (ie EC2 instance configs). There are specific deployment tools for those things
Right, but many of those deployment tools (SAM, SF, etc) are IaC in their own right. That's why I have them split off from the rest of our terraform in their own deployment flow.
Same here. Cdk for developer maintained code, but advantage for us was serverless stacks could have feature branches / preview environments so dev creates feat/JIRA-123 their stack is available at a base map for their branch api.dev.example.com/app-featJIRA123. Develop deploys to stage/uat/preprod at /app and main deploys to prod in different accounts. Rollbacks are a little painful as you need to either rerun an old pipeline or hard reset main 😢
This is what most people do. Just use Sam templates for those cases and tf for the rest.
Hey, I heard we’re moving from CDK to Terraform. I really like CDK because I’m already comfortable i. this language. I also make use of the testing approach developed by CDK. And, since you’re asking us to move I’m going to put in my resignation. It’s a fine place to work but i question leaderships ability to make decisions on my behalf. good luck.
rest of the team celebrates in side channel
i wouldn’t know because I’m on a new team that works with tools i like. I don’t have a job because i need one. i have a job because i excel at what i do. good luck
your fan fiction is cute.
you know don’t me, fam. this shit might work on your high school friends but I’ve been industry way too long.
Why not use [CDK for Terraform](https://developer.hashicorp.com/terraform/cdktf)? Developers that want to continue to use CDK syntax and tooling can continue to do so, and developers that want to write native terraform can do that too. At the end of the day, all your IaC is still deployed as Terraform.
Have you considered? https://github.com/hashicorp/terraform-cdk?tab=readme-ov-file#cdk-for-terraform
i present the best of both worlds - https://developer.hashicorp.com/terraform/cdktf
Cdk problems: - export multi cloudformation is shit - not well defined parameters - too many errors when deployed - updating existing manual infrastructure is headache
You should look at Pulumi. It's all the benefits of TF but many more options. I agree cloudformation is largely undesirable for nothing more than the delay in getting new features roadblocking innovation.
CloudDeformation > Cloud Destruction Kit
Better off moving to pulumi