AWS Makes Cloud Formation Stack Creation Up to 40% Faster
infoq.com
infoq.com
Making something twice as fast is great IMO, and as a firm believer in iterative improvements, I'd never knock it.
Eg. if setting up a stack goes from 100s to 60s, that's a marked improvement.
I really wish AWS conceded the IaC war and stopped putting resources into Cloudformation. I never suffer as much as when I have to work with CF. The only worse thing I can think of is having to interact with Azure, which around 5 years ago was a terrible experience all around with regard to automation.
Going back to my CF rant: As soon as you get into any amount of complexity (and this also includes CDK, as it inherits all of CF problems), like for example using nested stacks and custom resources, it becomes almost impossible to troubleshoot incidents and problems. Error messages are obtuse. Fail states are too frequent. Update and deploy times are incredibly slow. Working with CF makes me reconsider my whole job every time. I curse the day that I chose to ignore my general precaution with CF and go for a database (Opensearch) managed with CDK.
There's a night and day difference between managing infrastructure state with Terraform and CF. Terraform also has its quirks and warts, of course, but at the very least there's very little that cannot be recovered by yourself. And it is also fast enough. CF is mostly a black box of misery.
Besides CF, I’ve done it directly in the web console and that still seemed pretty slow (though that would have been a while ago, maybe it has improved).
Agreed. Sometimes I edit a core library of mine so nearly all my lambdas need to get update but I hate having a 10-20min deploy time. Some of that is GitHub Actions (their CI is so slow, I'm looking to switch) but CF itself is slow.
I’ll have to investigate what the effects are of moving my projects off my personal account and into an organization. Long term that was always the plan but as a single-founder LLC I had no reason to use anything but my GH account I already paid for.
Now i have to set explicitly an additional DependsOn to the queue's queuePolicy.
Really good thing is the declarative nature of it. When you release upgrades to AWS accounts where you don't have any control, this makes everything safer (and simpler to manage).
I've always found that Terraform does it exceptionally well, mostly because of the dependency graph and how good providers map resources so that they don't end up in a dead lock.
What, it's Terraform's fault that you haven't bothered to write one yourself?
What it does have is modules, which accomplish the same. And of course, if you don't want to write them then just as with L2/L3 constructs you are limited to using others'.
Let's just all code in assembly then? Because we all should bother to write anything and everything from scratch?
And it is also possible to write in assembly, will you?
> The complaint was that they had to use a third party or community one
And isn't that fair? People want support? Official support? Is that wrong? And yes community modules especially since they might not be from the same group lack consistency, documentation and often doesn't get updated as regularly. The magic is the vendor is the only 1 that can properly coordinate updates.
> as though those people are doing by some kind of magic unavailable to them
Then why are you using Terraform? The APIs behind Terraform are also available to you so you can use that directly. There's no magic unavailable to you either. And you go beyond not using those APIs and build your own servers and data centers too.
I don't get why Terraform is a fair abstraction you're defending yet you're arguing against people wanting a higher level of abstraction.
Modules are the same abstraction as L2/L3 constructs. In either case if you don't want to use someone else's (and you want one) you write your own. If you then haven't, it's not Terraform's or AWS CDK's fault.
Crossplane (although it's quite new, and missing a lot of things that Terraform has)
I know how CloudFormation behaves, and none of the wrappers have convinced me that translating through CloudFormation makes sense. ("through" because if you're using CDK, you're translating from imperative to declarative to imperative... why?!)
I tried it on a recent greenfield project, and now I’m kicking myself for not giving it a try in earnest earlier.
So all the core CDK code is written first in JS/TS and then stubs for the other languages are added
Unfortunately this is often done without consideration for how the other supported langs actually work, and artefacts of e.g. JS lack of support for kwargs leak through
This is why e.g. the typing in CDK Python is completely broken - pretty much uniformly the concrete types like "Resource" don't implement their corresponding interface like "IResource" (to a type checker)
(There are many other typing niggles like this but that's the most egregious and pervasive one)
At the end of the day, having to explicitly cast concrete types as their interface to satisfy type checker is a minor annoyance, albeit a stupid one that could have been avoided with more care in the core library.
I could live with that, but I encountered so many bugs and issues trying to use CDK on current project that it's now much clearer to me why every company I worked at previously was using Terraform.
Pretty sure some of those issues are ultimately CloudFormation ones. The cumbersome CF > CDK JS > CDK Python stack is great for obfuscating errors and making debugging hard or impossible though.
Pulumi do something similar, albeit with Go as the core language and Terraform underneath. From what I've seen with a little use they have a much more successful result though, Pulumi Python was not a complete mess, and deploys faster and more reliable with better error feedback. I guess they just took more care to get it right.
I would have been perfectly happy to use CF if they added the notion of higher level constructs at CF level, but for whatever reason they haven't. So I use CDK because it provides the ability to reuse service compositions from third party libraries as well as across different internal projects.
CDK is imperative but imperatively building the configuration is not at all the same as imperatively managing the infrastructure. Even if with CDK the configuration is imperatively built you retain all the benefits of having declarative infra - version control, selective auto update, rollback to previous state etc.
Yes, while CF is clunky and slow, and I am sure everyone who uses it has at times gotten stuck with rollback failures, but CDK does provide a somewhat better dx on top of it.
And the other way round
It can now explode our deployments that create more than 50 ALB rules per MINUTE even faster.
Seriously:
1. Why does it not know about the rate limits other services have.
2. Why does it not automatically retry if it is rate limited.
3. Why is there a rate limit of less than a request per second in the first place!
If you haven’t noticed, I hate CF with the passion of a thousand suns.
[0] - https://aws.amazon.com/cloudcontrolapi/ [1] - https://registry.terraform.io/providers/hashicorp/awscc/late...