Video is super well-structured, the graphics and examples are shown in a super nice way... This video is legit better than a lot of big channel productions, man!
IAC should be "what you want" in the simplest way and I can't see anything simpler than a simple declarative language... but nothing is sufficient and things are getting much more complex than they should be and KISS is a concept that more and more is put aside. It's a nightmare to keep up to date these days! A lot of cool and useful stuff is in the queue to be learned because in the next interview for a job or with your Devops manager you will be asked for a new way to do the very same thing with arguable advantages because a lot of people around the world are not happy with any tool that works the way they are or not works exactly the way they want. Jesus, is frustrating. Thanks I'm not a dev because I know how much they suffer with each new framework or package that shows up every day by the other hand developer are never happy with nothing that exists for more than 5 minutes or less!!
I think the audience is for software devs handling infra and sys ads handling infra. I get the allure of not thinking about OOP using Terraform and also like to tame codes using CDK. I think what we should think how easy should we make the onboarding process of both types of potential team members.
As someone who's worked with both Terraform and CDK, I prefer terraform. The idea of using classes to encapsulate resources is tempting but in practice I find I end up fighting against the restrictive classes when I'm wanting to do something that wasn't defined as a method in the CDK.
Interesting.. I didn't feel this struggle.. I think that if you understand how to use the escape hatches, you can easily go around the defined methods to do some edge case customizations. this page was very helpful to get more flexibility when needed. docs.aws.amazon.com/cdk/v2/guide/cfn_layer.html
@@perfectbase Thanks I'll see if this helps my flow. Although I've realized part of my frustrations is that I believe IaC should be written in a declarative and direct manner, much like tests. IMHO while CDK definitely is easy to write, it can be very difficult to read for a large project because every project is written in a different way. Having that enforced structure will help readability in the long term.
With Terraform, there is no discussion of the implementation language. It's HCL, end of story. With CDK, discussions about the use of Python over Typescript or Java or C# can come under discussion if a customer has a heavy preference for one of the languages possible. There are quirks in Python that are not present in TypeScript .. and vice versa. There are advantages to a full object system, when using CDK .. and there are disadvantages because everything has to be wrapped in the appropriate object. CDK's Level 2 constructs are opinionated and akin to using Terraform Modules that you don't fully understand. The multi region, multi account deployments in CDK are maybe a lot easier to juggle, than the same infrastructure implemented in Terraform. Importing existing infrastructure into an IaC system is much easier if done in Terraform, than in CDK. Add an extra role to an AWS account, over the phone, guiding a customer .. That's something I'd do in CloudFormation, no doubt. I happen to have extensive experience with both Terraform, CloudFormation and CDK and each of the systems have merit. What one absolutely should not do is: manual changes via the aws console. If you press the orange or blue buttons, you've already lost.
Good point.. not totally sure though. Maybe I can see the setup for deploying the first stack being a little bit harder, but after that in a lot of cases you can basically write the same thing you were writing on terraform. Just with a different syntax.
Video is super well-structured, the graphics and examples are shown in a super nice way... This video is legit better than a lot of big channel productions, man!
IAC should be "what you want" in the simplest way and I can't see anything simpler than a simple declarative language... but nothing is sufficient and things are getting much more complex than they should be and KISS is a concept that more and more is put aside. It's a nightmare to keep up to date these days! A lot of cool and useful stuff is in the queue to be learned because in the next interview for a job or with your Devops manager you will be asked for a new way to do the very same thing with arguable advantages because a lot of people around the world are not happy with any tool that works the way they are or not works exactly the way they want. Jesus, is frustrating. Thanks I'm not a dev because I know how much they suffer with each new framework or package that shows up every day by the other hand developer are never happy with nothing that exists for more than 5 minutes or less!!
Never really paid attention to AWS CDK, going to take a better look into it! Great vid
I think the audience is for software devs handling infra and sys ads handling infra. I get the allure of not thinking about OOP using Terraform and also like to tame codes using CDK.
I think what we should think how easy should we make the onboarding process of both types of potential team members.
As someone who's worked with both Terraform and CDK, I prefer terraform.
The idea of using classes to encapsulate resources is tempting but in practice I find I end up fighting against the restrictive classes when I'm wanting to do something that wasn't defined as a method in the CDK.
Interesting.. I didn't feel this struggle.. I think that if you understand how to use the escape hatches, you can easily go around the defined methods to do some edge case customizations.
this page was very helpful to get more flexibility when needed.
docs.aws.amazon.com/cdk/v2/guide/cfn_layer.html
@@perfectbase Thanks I'll see if this helps my flow.
Although I've realized part of my frustrations is that I believe IaC should be written in a declarative and direct manner, much like tests. IMHO while CDK definitely is easy to write, it can be very difficult to read for a large project because every project is written in a different way. Having that enforced structure will help readability in the long term.
Very nice! Thank you ❤
Thanks for watching!
With Terraform, there is no discussion of the implementation language. It's HCL, end of story. With CDK, discussions about the use of Python over Typescript or Java or C# can come under discussion if a customer has a heavy preference for one of the languages possible. There are quirks in Python that are not present in TypeScript .. and vice versa.
There are advantages to a full object system, when using CDK .. and there are disadvantages because everything has to be wrapped in the appropriate object.
CDK's Level 2 constructs are opinionated and akin to using Terraform Modules that you don't fully understand.
The multi region, multi account deployments in CDK are maybe a lot easier to juggle, than the same infrastructure implemented in Terraform. Importing existing infrastructure into an IaC system is much easier if done in Terraform, than in CDK.
Add an extra role to an AWS account, over the phone, guiding a customer .. That's something I'd do in CloudFormation, no doubt.
I happen to have extensive experience with both Terraform, CloudFormation and CDK and each of the systems have merit.
What one absolutely should not do is: manual changes via the aws console. If you press the orange or blue buttons, you've already lost.
Nice take!
“If you press the orange or blue button, you’ve already lost” 😂
Good one!
Hi but Terraform is a bit better or easier for newbies who are not from a programming background or a software developer at least that is what I think
Good point.. not totally sure though. Maybe I can see the setup for deploying the first stack being a little bit harder, but after that in a lot of cases you can basically write the same thing you were writing on terraform. Just with a different syntax.
CDK is amazing :)