This is very welcome, but also CFN is horribly slow and even 40% faster will still be slow. Reminds me of when MS was very proudly saying that new Teams is much faster than old, which turned out to mean that channel/chat switches take 1s instead of 2s. Yes, huge improvement, but not the order of magnitude improvement that is needed.
I have a bigger problem with "up to": this means it's at most that much faster, but is probably not even such an improvement to begin with. I understand this is marketing, but it'd be great if they shared what's the average improvement they've seen in their customers' workloads (a random sample of).
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.
Came by to say this. Had to deal with CF stacks at $PREVIOUS_JOB and 40% is just not enough to remove it from the "oh god I have to work with this again" area of my mind.
I've been working now around 8 years with cloud stuff. Not a lot of years compared with many of you here, but still enough to feel confident about my dislikes being more than just ignorance or inexperience.
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.
It's a nice number to advertise, but AWS really should make all CloudFormation deployments much faster. There's no reason why updating the code of a single Lambda function should take 30s or even several minutes. It should happen in less than a second, the time it actually takes to call the Lambda API. In general it is way too slow to update a big CloudFormation project comprising many stacks, when only a small portion of the resources are actually changed. This slows down development of CDK based projects for no good reason.
> There's no reason why updating the code of a single Lambda function should take 30s or even several minutes.
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.
Weird self promo but we[1] provide Github actions runners that are much faster than stock. You can get started with just a one-line change to your workflow file. It may help.
[1] https://www.warpbuild.com
I signed up yesterday but you don't support personal accounts yet. I look forward to those being supported! You are who I'm planning to use (since I need macOS as well).
Oh, that’s unfortunate. The docs made it sound like support was coming soon.
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.
Yeah, I've seen them before and it's super cool looking. I might try it but ~$325/yr is a lot for a side business that only needs it here and there. Also, no macOS means I can't move everything over which would be annoying. Thanks for the suggestion though!
Yes, if you use Cloudflare or Vercel or Netlify it does take just a few seconds to update. AWS Lambda updates are mystifyingly slow, and CloudFormation seems to add a ton of overhead regardless how complex or simple your setup is. (I guess this "40% faster!" means they reduced the overhead a bit?)
You can also update a AWS Lambda in a few seconds if you use the aws sdk. Or in a few more seconds if you use pulumi or terraform. It's a problem entirely related to how CloudFormation works in detecting changes.
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).
Yeah I remember when I ran a CDK pipeline in my previous job I could go on a bike, ride through a nearby forest, grab a coffee on the way, come back home, take a shower and it would still run...
Could explain my issue, why my stack started to fail silently. Before, i could setup s3 bucket plus sqs queue, and setting up notification configuration, where s3:ObjectCreation events are sent to that queue, when an s3 object is created. The notification configuration was no longer created.
Now i have to set explicitly an additional DependsOn to the queue's queuePolicy.
Great to see some improvements on that front. CloudFormation is perfect for point-and-click install of third-party software (like mine [1]), but the slowness doesn't make for a great first impression when setting everything up.
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).
Yes. Directly – no CDK or wrappers – using the serverless transform when it makes sense.
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?!)
The libraries for other supported languages of CDK are built as wrappers for underlying JS or maybe TS code via https://github.com/aws/jsii
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.
Plain CF sucks because it doesn't really provide any kind of abstraction capability. So in any kind of real world application the yaml gets humongous that is very hard to review.
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.
There are tons of resource types only available via cfn compared to cloud control api vs terraform vs direct api, any decently complex deployment often requires mixing one or more options just to get full coverage
No? The complaint was that they had to use a third party or community one, as though those people are doing by some kind of magic unavailable to them; they for some reason don't want to use those (maybe they're not suitable for particular use case, I don't know) and it's somehow terraform's fault that they haven't then written their own. It is possible, so I just don't understand what the complaint is.
> It is possible, so I just don't understand what the complaint is.
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.
I'm not arguing against higher abstraction, I'm not saying write assembly.
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.
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'.
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.
Is importing resources to a cloudformation stack still super painful vs creating them? That and the poor drift detection were the primary sharp edges I encountered.
For me slowness is not the main complaint - after all, my employers pays for that. What annoys me most is its flakiness when dealing with complex setups (multiple cross-account interdependent resources). "A resource failed to be removed" and good luck with the diagnostics.
No, their saying cloud formation wasted billions of person years per total deployed stacks, due to poor of use of sleep/waits between resources, and they’ve minimized that. Terraform’s native AWS provider never had that issue, and is still considerably faster. Terraform also has a cloud control based AWS provider [0][1], which might seem some benefit as its the same underlying engine as cloud formation.
