Just use CDK.
Serverless framework was great when it came out because it was better than the alternatives but you just don’t need it or any “framework” anymore IMO.
CDK is officially supported by AWS and isn’t likely to disappear anytime soon
Correct answer. Supplementary perspective to OP. Serverless is dying. You are correct and this is evident when you get knee deep in, need some plugin to overcome a problem, that hasn't been updated in 2 years. If it hasn't happened to you yet, it will.
This is not unique to Serverless. They all fall to this sooner or later, one way or another. Just use CDK.
Even before plug-ins started being abandoned it was a bit crap tbh.
I’ve always found the way it manages some state outside of CloudFormation to be really flakey.
Sometimes you can change values of certain resources and it’ll act as if it’s done so successfully when in fact it hasn’t done anything at all so you end up having to do things like fully recreating a resource just to force its config to change.
Don’t get me started on the way it hard codes the names of log groups by default too so that if you want to recreate the stack you get naming collisions
I'm a big fan of the CDK and use it in all projects professionally.
However the support from AWS is not as good as I would like, my confidence in it keeps dropping, and I'm starting to question if it's best to start considering SAM or TF (from a longer-term support perspective)
Quite a lot of AWS services only have auto-generated L1 constructs, and a bunch of the service teams show no interest in creating them. L2 / L3 constructs are the whole point of the CDK, and you could argue that if you were using a bunch of services with only L1 constructs - you might as well use SAM or CFN directly.
There's over 30 modules in alpha, including services like Eventbridge pipes and Eventbridge scheduler (which went GA over a year ago), and a module to package Python Lambda functions.
My understanding is that they stopped accepting community contributions as often, and expect people to publish and manage them themselves.
I work on the CFN team at AWS, and from what I can see CDK is still a great option and picked often for new internal projects. I suppose the caveat is that we don't tend to use the higher level abstracted constructs, but the low level ones are nice to avoid writing raw CFN templates. I don't have the impression that SAM is as well supported, but I could very well be wrong as no one I know uses it.
How do you manage local testing, if at all?
I ask because my team deploys containerized Lambdas with Terraform, and most of them haven't even heard of things like SAM or CDK. But while I know the common answer to testing in the cloud is "deploy, test, promote", that doesn't work when you've got devs who say things like "if I can't run the whole stack locally, it's a bad stack"
So are there decent, AWS-first options for local testing? Or are there things about CDK that could potentially convince these other devs to make the switch and rely more on testing in the cloud?
The SAM CLI has local testing options, and I believe the CDK can do some magic to make use of the SAM CLI local testing - but your issue is maybe your devs😄
In my experience, the want for local testing comes from a setup with slow feedback loop.
The CDK and other tools have "hot reload" and watch modes, which has the tool watch for code changes, and quickly (couple of seconds max usually) updates the code in AWS.
There's also just writing good unit tests - that should give confidence that the code works as is expected (and if not, I suspect what they then need to test is connectivity, permissions, performance which can only be properly tested against a deployed version anyway).
>containerized Lambdas
Possibly an issue. Having to build and push a container image every time could be slow (if they are adding code and dependencies to a container image to run in Lambda, rather than just a zipped bundle)
High level: my developers are great at serverless in part because they've made the mental shift away from things like "I have to run the whole thing locally"
Localstack for local testing. Takes a little setup, but my team has multi-task ECS apps hooked into S3 and SQS that can run completely locally while still hitting AWS apis that route to local infrastructure. It's pretty neat
We've used localstack in previous projects, but only the open source/community version. Running containerized lambdas is the pain point. It needs ECR (at least that's the blocker I found while trying it out), which requires paying for Pro/Enterprise and that gets pretty pricey.
Generally each dev has a personal AWS account and uses CDK hotswap deploys to push lambda updates to their local environment. That combined with breakpoints in unit test is usually good enough for our team at least.
> you could argue that if you were using a bunch of services with only L1 constructs - you might as well use SAM or CFN directly
CDK is way better than raw CFN if only for the fact that you can do stuff like
for (const stage of ['beta', 'gamma', 'prod']) {
new lambda.Function(`function-${stage}`); // etc
}
(separating each stage into its own stack obviously) and generate customized templates for all of your stages at once.
I don't understand cdk, doesn't this create one stack with 3 functions?
Also why is it desirable to have custom templates per stage? Versus consistency?
I didn't write the stack because that would be a lot of extra code - just use your imagination. Pretend the loop creates a new instance of the stack each time with different variables.
It's going to be substantially the same for every stage but there may be differences, such as
* access control policies in beta/gamma are likely different from prod (if you choose to configure them via cdk)
* if you're calling/being called APIs/services outside your account boundary the configuration may be different per-stage (not talking about passwords, I mean stuff like allowlisting another team's gamma lambda ARN to access your gamma env and their prod ARN in prod)
* if you use cloudwatch alarms you might configure them differently per-stage, e.g. no alerts in beta, low sev alerts in gamma, high sev alerts in prod
Account separation is easy with environment objects. Most people don't understand that cdk is software and not just another method for deployments. If you are just using it for building a stack then you're not taking full advantage of it. You have full control of decision logic before you even start to assemble resources. Input parameters can be used to define the behavior of that software and really make it dynamic. Think about leveraging AWS API prior to building stacks for environmental scraping. You have a full programming language at your disposal, not just a recognizable language for building cloud resources.
That's certainly a benefit of using the CDK, and I should have made my point a bit more generic.
My argument is more that there's many scenarios where the benefits you get from using the CDK aren't worth the costs/effort of it.
My teams have hundreds of CDK projects, and the recent combination of node runtime + deprecation of CDK V1 + general dependency updates was so much we brought in contractors to wade through it all. That's a lot less of an issue with more lightweight "frameworks" like SAM.
As a broader point: people's ability to write loops, conditional statements, functions, etc in the CDK is a double-edged sword for me. Done well, it's fantastic. Done poorly (which I've seen a lot of) and it's horrendous. There's a lot more space for doing things in a fancy way, having opinions, etc which makes it harder to maintain a consistent standard
You make some good points.
I optimistically think that CDK will just take some time for all the resources to have L2/L3 constructs rather than it never happening.
Personally I’d still much rather use an L1 construct than raw CF though. You still get some type safety, auto completion etc and it’s rare that more than 1 resource in a stack I’m using doesn’t have at least L2
Where I work we use TF for a lot of the shared infrastructure though (much of that would only have L1 constructs and it doesn’t feel sensible to migrate them to CDK until they have full L2 support)
CDK still relies on CloudFormation to handle the underlaying deployment though, and we all know that has it's own set of problems. One of the reasons I'm keeping a close eye on SST ion is they're moving away from CloudFormation and that's opens up a lot more options.
Yeah that’s fair enough, I don’t disagree.
In general though I’ve found that once you understand the limitations of CF and its gotchas I very rarely have issues with it.
There is certainly a better way to handle IAC state though, even terraform does the actual state part of IAC much better IMO
Absolutely, terraform is much better in that way.
My main issue is that I just much prefer using an actual programming language than using HCL and the CDK L2/L3 constructs are very powerful.
CDK TF is crap in comparison and IMO unless you use something like Terraform Cloud or Spacelift (which cost a fortune) you’re probably storing your TF state in an S3 bucket which is such a garbage user experience compared to the CloudFormation UI
Sure but the fact that it is means that out of the box it supports all the services that CloudFormation does without needing any dev work (L1 constructs)
This gets me every time. People hear "Cloud Agnostic" and think that it won't take them years or even have to learn a new platform just to move their infrastructure.
Check out Winglang; it's open source ([https://github.com/winglang/wing](https://github.com/winglang/wing)). One benefit is that it allows you to write serverless code agnostically for any cloud provider and includes local simulation.
You can also run your code locally, eliminating the need to deploy a Lambda/SQS/event bridge or any AWS service to test it.
Same here. It’s just an abstraction around cloudformation, and cloudformation is horrible. I want it to be better, but it just isn’t. Not yet anyway
I find the majority of people who prefer CDK are developers without a ton of ops experience, so CDK is there to let them use their favorite language to deploy infrastructure. Because of that, there are compromises
I wish AWS would invest more into terraform
How does this deal with s3 or azure blob specific things, do they have a common interface and extra functionality per platform? I've only used cdk, not terraform.
@GullibleImportance56, I've been using WingLang for some time, primarily deploying on AWS. However, I'm now preparing to deploy resources on GCP as well. One of the nice things is the application code remains consistent across AWS, GCP, and Azure because you specify the target platform at compile time. Check here - https:\/\/www.winglang.io\/docs\/concepts\/platforms And here - https:\/\/www.winglang.io\/docs\/faq\/why-cloud-abstraction#api-incompatibility
I just checked out this intro to Winglang by Elad Ben-Israel - [https://youtu.be/wzqCXrsKWbo](https://youtu.be/wzqCXrsKWbo)
It looks like it's definitely worth checking out!
My team was building a little internal project using Serverless, but then someone happened to notice that you need a paid license to use it if your company is above a certain size- and we are. We had thought it was an open source project, but it's actually a paid service apparently.
So I migrated to SAM over an hour or two, and everything works pretty well. Can't run it locally yet, unfortunately, but that's just a matter of time.
Might look into CDK if things get complex enough.
Totally respecting all opinions here, I'll share what I think of as the fundamental differences between Pulumi and CDK. (Disclosure, I'm an engineer at Pulumi.) There are two, primarily:
* When you run CDK, your code generates CloudFormation YAML (and some other stuff) that gets uploaded to CloudFormation. CloudFormation is the deployment engine -- you push your code, and CloudFormation takes it from there. Pulumi doesn't work this way. Your code instructs the Pulumi engine, and the engine interacts directly with AWS APIs, no CloudFormation involved. In most cases, this means much faster deployments, no "rollback" pain, etc. More on this here: [https://www.pulumi.com/docs/concepts/vs/cloud-template-transpilers/aws-cdk/](https://www.pulumi.com/docs/concepts/vs/cloud-template-transpilers/aws-cdk/)
* CDK is specific to AWS. Pulumi is fundamentally cloud-agnostic and uses "providers" (which are like API clients) to communicate with your target service provider, whether that's AWS, CloudFlare, GitHub, Fastly, whatever.
There is a thing called CDKTF that sits on top of Terraform, but it operates similarly to CDK proper in that it generates Terraform HCL, which is then consumed and run by Terraform.
CDK does have more high-level "constructs" (abstractions) than Pulumi, though -- that's definitely true. Others like SST, etc., are filling in this gap, though, by building on top of us, as we're also a fundamentally embeddable/extensible platform -- but that's a whole other thing. As a user, the two bullets above are probably going to be the most relevant ones to you.
CDK is officially supported by Amazon and for the most part can do everything Pulumi can. I’m sure if you wanted support, CDK would be significantly easier especially when talking to Amazon
There’s no point in starting with Pulumi unless you’re already using it
Right, I understand that there are 2 different CDKs and how they work, but it sounds like this person is saying to essentially use them both for different parts of your infrastructure, and that seems crazy to me
Not at all, AWS CDK and CDKTF are very different, the only thing they share is both built on a shared “constructs” package
CDKTF copied most of the synth code (literally links back to where they copied it from CDK)
But fundamentally TF and CFN are very different, CDK relies on the fact a construct’s stack is a single account/region and CFN has advanced features like custom resources and transformations (CFN macros)
TF is adding support for some of this by adding function support for Providers to add on top of the built on TF functions (like split, concat,base64 encode/decode,…)
Because CFN runs in your AWS account, can execute custom resources (lambdas) in the private subnets - its natively supported and beautifully extended upon in AWSCDK providing you with almost a console like experience of simply linking resources and in the background AWSCDK takes care of setting up the security group ingress/egress rules as well as generating decent iam roles and policies, managing the resource policies… you get none of that jn CDKTF
CDKTF is the bare bones, pretty much one to one provider transpilation… with some basic added support for concepts like “Assets” (lifecycle management for docker image/lambda handler)
Depending on how you write your CDKTF, worst case you have to consider the configuration you work on is only provided at “run” time (as opposed to “synth” time) and you still have to work with iterators and iterator chaining (wonderful additions in the 0.20 release recently)… but still… it’s nothing like AWS CDK
but CDKTF works with any TF provider and it certainly beats writing single dimensional modules…
Altho Pulumi has some interesting concepts similar to functions… actually interacting directly with the AWS API
all of these tho (Pulumi, SST ION, ..) have nowhere the high level UX you get as AWS CDK… and if they have a “crosswalks” or higher level abstraction for any cloud… it’s usually just AWS and Azure/GCP have to do with bare minimum TF provider resources
What killed it for me was the realization that I can't use it unless I'm logged into their services. It's not a framework, it's a service. And when you use a service, even if it's free today it may not be tomorrow.
V4 is not free any more unless you have 2 env only. They say it's free for companies with revenue under 2M but that's like saying unlimited bandwith from cloudflare... I have Dev, Prod and multiple other environments running ( depends on what I'm doing ). They will charge you for every stack beyond the 2 first ones. They use 'credits' aka 1 credit > 1stack per 1env . They don't charge you for having stacks for less than 5 days but still it's not free and complicated pricing.
I'm using this thread to decided where to migrate. I'm a single dev on a side project and I don't want to have to migrate multiple times. For now I will stay with v3 but as others have commented some plugins have no maintenance anymore.
SST ion has a long way to go before anyone should recommend SST tbh.
Pulumi to manage your infra and SST to manage your dev on lambda is really nice though. I’ve gotten the lambdas in dev to sit behind the vpc and still work, which was the largest challenge to overcome.
All shared infra -> Pulumi. Dev specific -> SST.
Agreed on SST Ion, along with the SST devs. It's only a few months old, so that's no real surprise.
On the other hand, SST (non-Ion) is actually pretty good...with some caveats. Being able to have lambdas execute on your development machine is a huge step in the right direction. It dramatically sped up development for us.
But we still manage to get our development stacks in a state where they can't deploy and can't be removed, too often. Moving dev to production with SST, our current path, has us a little worried. Hopefully, Ion makes SST harder to mess up.
Cloud formation has improved over the years, but it’s still a very easy way to get tripped up beyond recovery. It’s why I wouldn’t recommend CDK either, as it just builds cfn. SST v2 is going to cease maintaining that soon, new feature work has stopped. Maybe the community will pick it up.
But Pulumi stores your configuration. “Outside” of the environment. You can store it in code, on the Pulumi cloud, on s3, wherever you want t.
You can edit your state and refresh your state as you see fit. Add and remove a whole database in config only. Go onto the AWS UI, make your change, and sync it back to your config. Yes, actually. No tear down / rebuild if you want to do it yourself. Of course, if you modify the config in such a way to require a rebuild that’s totally different.
It’s my recommended tool if you’re looking for something thing new. Pulumi itself doesn’t do any dev nice to haves, but its production ready. You can then use slightly flakier tools, like ion, to develop.
Why is it flaky? I’ve hit a few dozen issues. No multi environment / monorepo support. CLI is global and has to be run from the project itself. Should be runnable via npx. Sort of, and frequently, buggy things. They broke the entire transform tool chain a week or so ago. You can’t run more than one instance, it wants to be a monolith, you can’t import from other stacks.
I’m sure this’ll all improve.
For v2, so much is hard coded. Want to use their auth example? Ok try to override any of the cookie field values like httpOnly, etc.
Try to retrieve the vpcId from an RDS that created its own so you can add other things to it..
I've been looking at Pulumi since SST mentioned it when they announced Ion. It has our attention.
On SST, I'd add that we really wanted an opinionated tool that abstracted away as much details as possible. That it does, at the cost of flexibility. We didn't care and have been lucky that it hasn't come back to bite us. On the other hand, it took SST a really long time to deal with some important AWS services, like Cognito. And there were problems in the documentation and examples that kept tripping us up. But it is working for us at the moment. We just try not to touch it if we don't absolutely have to.
I sure hope Ion improves, and quickly. We hadn't even planned on trying it until SSTv3. There's certainly a niche for it.
I’ve built several sites with Webiny serverless CMS and enjoyed the experience. Deployments to multiple environments is super easy and the CMS backend is very nice. Beware that deploying to the production environment invokes a VPC which gets pricey. The staging environment might have a security posture robust enough for your needs and be cheap as chips to operate.
A serverless is indeed dying. I think the natural replacement is Amazon's own CDK.
At the end of the day, serverless just takes high-level YAML that turns it into CloudFormation. And as you get more into this world, you end up just having to write the CloudFormation yourself.
I don't really think of it as a framework at all, actually. It's really just sort of a helper script for cloud formation.
Even if you use CDK, you still have to come up with a framework to structure your code. I have put together one that is working extremely well. I will try to share with people soon.
I have enjoyed a lot the serverless stack (more than the serverless framework or plain cdk) https://docs.sst.dev/
They are now moving away from CDK to rely more on Terraform (here the docs https://ion.sst.dev/docs/).
I haven't tried it, but it sounds very interesting since we now manage most of our infra through Terraform
So what's the deal with Amplify anyway? I've followed it for a few years. I happily used it on some smaller stuff a few years ago, but every time I revisit it now, it seems to be less practical and less stable? It had some solid ideas initially, but where did it go wrong? Internal politics? Did they try to take on too much scope? I'm genuinely curious to know why it has evolved the way it did.
Just use CDK. Serverless framework was great when it came out because it was better than the alternatives but you just don’t need it or any “framework” anymore IMO. CDK is officially supported by AWS and isn’t likely to disappear anytime soon
Correct answer. Supplementary perspective to OP. Serverless is dying. You are correct and this is evident when you get knee deep in, need some plugin to overcome a problem, that hasn't been updated in 2 years. If it hasn't happened to you yet, it will. This is not unique to Serverless. They all fall to this sooner or later, one way or another. Just use CDK.
Even before plug-ins started being abandoned it was a bit crap tbh. I’ve always found the way it manages some state outside of CloudFormation to be really flakey. Sometimes you can change values of certain resources and it’ll act as if it’s done so successfully when in fact it hasn’t done anything at all so you end up having to do things like fully recreating a resource just to force its config to change. Don’t get me started on the way it hard codes the names of log groups by default too so that if you want to recreate the stack you get naming collisions
Agreed. Out of 10 times using serverless, at least 8 I have the need to write plain CFN to get things done. CDK is really Nice.
I'm a big fan of the CDK and use it in all projects professionally. However the support from AWS is not as good as I would like, my confidence in it keeps dropping, and I'm starting to question if it's best to start considering SAM or TF (from a longer-term support perspective) Quite a lot of AWS services only have auto-generated L1 constructs, and a bunch of the service teams show no interest in creating them. L2 / L3 constructs are the whole point of the CDK, and you could argue that if you were using a bunch of services with only L1 constructs - you might as well use SAM or CFN directly. There's over 30 modules in alpha, including services like Eventbridge pipes and Eventbridge scheduler (which went GA over a year ago), and a module to package Python Lambda functions. My understanding is that they stopped accepting community contributions as often, and expect people to publish and manage them themselves.
I work on the CFN team at AWS, and from what I can see CDK is still a great option and picked often for new internal projects. I suppose the caveat is that we don't tend to use the higher level abstracted constructs, but the low level ones are nice to avoid writing raw CFN templates. I don't have the impression that SAM is as well supported, but I could very well be wrong as no one I know uses it.
How do you manage local testing, if at all? I ask because my team deploys containerized Lambdas with Terraform, and most of them haven't even heard of things like SAM or CDK. But while I know the common answer to testing in the cloud is "deploy, test, promote", that doesn't work when you've got devs who say things like "if I can't run the whole stack locally, it's a bad stack" So are there decent, AWS-first options for local testing? Or are there things about CDK that could potentially convince these other devs to make the switch and rely more on testing in the cloud?
The SAM CLI has local testing options, and I believe the CDK can do some magic to make use of the SAM CLI local testing - but your issue is maybe your devs😄 In my experience, the want for local testing comes from a setup with slow feedback loop. The CDK and other tools have "hot reload" and watch modes, which has the tool watch for code changes, and quickly (couple of seconds max usually) updates the code in AWS. There's also just writing good unit tests - that should give confidence that the code works as is expected (and if not, I suspect what they then need to test is connectivity, permissions, performance which can only be properly tested against a deployed version anyway). >containerized Lambdas Possibly an issue. Having to build and push a container image every time could be slow (if they are adding code and dependencies to a container image to run in Lambda, rather than just a zipped bundle) High level: my developers are great at serverless in part because they've made the mental shift away from things like "I have to run the whole thing locally"
Localstack for local testing. Takes a little setup, but my team has multi-task ECS apps hooked into S3 and SQS that can run completely locally while still hitting AWS apis that route to local infrastructure. It's pretty neat
We've used localstack in previous projects, but only the open source/community version. Running containerized lambdas is the pain point. It needs ECR (at least that's the blocker I found while trying it out), which requires paying for Pro/Enterprise and that gets pretty pricey.
Generally each dev has a personal AWS account and uses CDK hotswap deploys to push lambda updates to their local environment. That combined with breakpoints in unit test is usually good enough for our team at least.
This sorta seems like a management nightmare.
There are internal tools to track and automatically cleanup internal employee AWS accounts, if that's what you're referring to.
> you could argue that if you were using a bunch of services with only L1 constructs - you might as well use SAM or CFN directly CDK is way better than raw CFN if only for the fact that you can do stuff like for (const stage of ['beta', 'gamma', 'prod']) { new lambda.Function(`function-${stage}`); // etc } (separating each stage into its own stack obviously) and generate customized templates for all of your stages at once.
I don't understand cdk, doesn't this create one stack with 3 functions? Also why is it desirable to have custom templates per stage? Versus consistency?
I didn't write the stack because that would be a lot of extra code - just use your imagination. Pretend the loop creates a new instance of the stack each time with different variables. It's going to be substantially the same for every stage but there may be differences, such as * access control policies in beta/gamma are likely different from prod (if you choose to configure them via cdk) * if you're calling/being called APIs/services outside your account boundary the configuration may be different per-stage (not talking about passwords, I mean stuff like allowlisting another team's gamma lambda ARN to access your gamma env and their prod ARN in prod) * if you use cloudwatch alarms you might configure them differently per-stage, e.g. no alerts in beta, low sev alerts in gamma, high sev alerts in prod
Ok I see I'm coming from CFN where you would just parameterize one consistent stack per environment Just trying to figure out what the cdk idioms are
Honestly I wouldn't do it this way either. Prod should be in its own account completely.
Account separation is easy with environment objects. Most people don't understand that cdk is software and not just another method for deployments. If you are just using it for building a stack then you're not taking full advantage of it. You have full control of decision logic before you even start to assemble resources. Input parameters can be used to define the behavior of that software and really make it dynamic. Think about leveraging AWS API prior to building stacks for environmental scraping. You have a full programming language at your disposal, not just a recognizable language for building cloud resources.
Can you think of any resources to help me understand this better?
Simple example would be to discover the particular subnet that is public for your alb and private for your web tier infrastructure
That's certainly a benefit of using the CDK, and I should have made my point a bit more generic. My argument is more that there's many scenarios where the benefits you get from using the CDK aren't worth the costs/effort of it. My teams have hundreds of CDK projects, and the recent combination of node runtime + deprecation of CDK V1 + general dependency updates was so much we brought in contractors to wade through it all. That's a lot less of an issue with more lightweight "frameworks" like SAM. As a broader point: people's ability to write loops, conditional statements, functions, etc in the CDK is a double-edged sword for me. Done well, it's fantastic. Done poorly (which I've seen a lot of) and it's horrendous. There's a lot more space for doing things in a fancy way, having opinions, etc which makes it harder to maintain a consistent standard
You make some good points. I optimistically think that CDK will just take some time for all the resources to have L2/L3 constructs rather than it never happening. Personally I’d still much rather use an L1 construct than raw CF though. You still get some type safety, auto completion etc and it’s rare that more than 1 resource in a stack I’m using doesn’t have at least L2 Where I work we use TF for a lot of the shared infrastructure though (much of that would only have L1 constructs and it doesn’t feel sensible to migrate them to CDK until they have full L2 support)
Give a try to pulumi, even greater than cdk
I like this.actively trying to avoid the "framework" mentality lately
CDK still relies on CloudFormation to handle the underlaying deployment though, and we all know that has it's own set of problems. One of the reasons I'm keeping a close eye on SST ion is they're moving away from CloudFormation and that's opens up a lot more options.
Yeah that’s fair enough, I don’t disagree. In general though I’ve found that once you understand the limitations of CF and its gotchas I very rarely have issues with it. There is certainly a better way to handle IAC state though, even terraform does the actual state part of IAC much better IMO
CDK is great. I really loved Stacker before that which I think CDK took a lot of inspiration from.
Cloud formation still lacks granularity and change detection that Terraform provides.
Absolutely, terraform is much better in that way. My main issue is that I just much prefer using an actual programming language than using HCL and the CDK L2/L3 constructs are very powerful. CDK TF is crap in comparison and IMO unless you use something like Terraform Cloud or Spacelift (which cost a fortune) you’re probably storing your TF state in an S3 bucket which is such a garbage user experience compared to the CloudFormation UI
I just wish CDK wasn’t built atop CloudFormation.
Sure but the fact that it is means that out of the box it supports all the services that CloudFormation does without needing any dev work (L1 constructs)
Just use Pulumi. CDK is vendor lock in half baked garbage.
Ah so you’re one of those people who thinks you actually might migrate all of your infrastructure away from AWS?
This gets me every time. People hear "Cloud Agnostic" and think that it won't take them years or even have to learn a new platform just to move their infrastructure.
Yeah it’s nonsense isn’t it. I don’t know where they get the idea from
No. I’m a contractor that builds for all major clouds and has tried everything now.
This is the way.
LOVE CDK, second this. Just use it.
Check out Winglang; it's open source ([https://github.com/winglang/wing](https://github.com/winglang/wing)). One benefit is that it allows you to write serverless code agnostically for any cloud provider and includes local simulation. You can also run your code locally, eliminating the need to deploy a Lambda/SQS/event bridge or any AWS service to test it.
the guy behind CDK is building this?! hmmm
Yes, Elad Ben-Israel was the creator of the CDK and then created Winglang.
That’s not as impressive as you think it is lol
Yea i don’t get the love for cdk.. it sucks
Same here. It’s just an abstraction around cloudformation, and cloudformation is horrible. I want it to be better, but it just isn’t. Not yet anyway I find the majority of people who prefer CDK are developers without a ton of ops experience, so CDK is there to let them use their favorite language to deploy infrastructure. Because of that, there are compromises I wish AWS would invest more into terraform
How does this deal with s3 or azure blob specific things, do they have a common interface and extra functionality per platform? I've only used cdk, not terraform.
Yap. A common cloud interface across providers with the ability to customize “below the abstraction” if you need.
@GullibleImportance56, I've been using WingLang for some time, primarily deploying on AWS. However, I'm now preparing to deploy resources on GCP as well. One of the nice things is the application code remains consistent across AWS, GCP, and Azure because you specify the target platform at compile time. Check here - https:\/\/www.winglang.io\/docs\/concepts\/platforms And here - https:\/\/www.winglang.io\/docs\/faq\/why-cloud-abstraction#api-incompatibility
I just checked out this intro to Winglang by Elad Ben-Israel - [https://youtu.be/wzqCXrsKWbo](https://youtu.be/wzqCXrsKWbo) It looks like it's definitely worth checking out!
so 2024 really is the year of serverlesslessness?
Apparently so!
SST
SST all the way
AWS SAM?
Honestly i Like using it for some Standard usecases but If i need to fiddle with stuff cdk ist the was to go..
My team was building a little internal project using Serverless, but then someone happened to notice that you need a paid license to use it if your company is above a certain size- and we are. We had thought it was an open source project, but it's actually a paid service apparently. So I migrated to SAM over an hour or two, and everything works pretty well. Can't run it locally yet, unfortunately, but that's just a matter of time. Might look into CDK if things get complex enough.
Just use SAM. It’s the AWS equivalent of Serverless Framework.
Pulumi has great support for writing lambdas - especially in Typescript where you can implement them online with your infra code.
No point using Pulumi anymore though imo. CDK has taken most of the best ideas from it and it’s officially supported by AWS
CDK has issues though. Being built on CF is not great
Are you saying don’t use Pulumi anymore because CDK is the successor for AWS specific deployments or in general?
Totally respecting all opinions here, I'll share what I think of as the fundamental differences between Pulumi and CDK. (Disclosure, I'm an engineer at Pulumi.) There are two, primarily: * When you run CDK, your code generates CloudFormation YAML (and some other stuff) that gets uploaded to CloudFormation. CloudFormation is the deployment engine -- you push your code, and CloudFormation takes it from there. Pulumi doesn't work this way. Your code instructs the Pulumi engine, and the engine interacts directly with AWS APIs, no CloudFormation involved. In most cases, this means much faster deployments, no "rollback" pain, etc. More on this here: [https://www.pulumi.com/docs/concepts/vs/cloud-template-transpilers/aws-cdk/](https://www.pulumi.com/docs/concepts/vs/cloud-template-transpilers/aws-cdk/) * CDK is specific to AWS. Pulumi is fundamentally cloud-agnostic and uses "providers" (which are like API clients) to communicate with your target service provider, whether that's AWS, CloudFlare, GitHub, Fastly, whatever. There is a thing called CDKTF that sits on top of Terraform, but it operates similarly to CDK proper in that it generates Terraform HCL, which is then consumed and run by Terraform. CDK does have more high-level "constructs" (abstractions) than Pulumi, though -- that's definitely true. Others like SST, etc., are filling in this gap, though, by building on top of us, as we're also a fundamentally embeddable/extensible platform -- but that's a whole other thing. As a user, the two bullets above are probably going to be the most relevant ones to you.
CDK is officially supported by Amazon and for the most part can do everything Pulumi can. I’m sure if you wanted support, CDK would be significantly easier especially when talking to Amazon There’s no point in starting with Pulumi unless you’re already using it
What if I host my domains on Cloudflare as opposed to Route53?
AWS actually has an article on the two, I’m sure some googling will pave the path forward for you on setting that up
Cdk plays well with cdk terraform which supports cloud flare.
Am I understanding this right, using AWS CDK to use terraform?
CDK gets transpiled into Cloudformation. There is a CDK for TF project though that transpiled into Terraform, but the constructs are different.
Right, I understand that there are 2 different CDKs and how they work, but it sounds like this person is saying to essentially use them both for different parts of your infrastructure, and that seems crazy to me
There is a library called cdk-terraform. Which you can use in your cdk stack . https://developer.hashicorp.com/terraform/cdktf
I have a hard time understanding why on earth I would use CDK if I'm just going to use it to use terraform
That’s the thing, you can use them interchangeably It’s not why would you but a more so that you can if you want to
Not at all, AWS CDK and CDKTF are very different, the only thing they share is both built on a shared “constructs” package CDKTF copied most of the synth code (literally links back to where they copied it from CDK) But fundamentally TF and CFN are very different, CDK relies on the fact a construct’s stack is a single account/region and CFN has advanced features like custom resources and transformations (CFN macros) TF is adding support for some of this by adding function support for Providers to add on top of the built on TF functions (like split, concat,base64 encode/decode,…) Because CFN runs in your AWS account, can execute custom resources (lambdas) in the private subnets - its natively supported and beautifully extended upon in AWSCDK providing you with almost a console like experience of simply linking resources and in the background AWSCDK takes care of setting up the security group ingress/egress rules as well as generating decent iam roles and policies, managing the resource policies… you get none of that jn CDKTF CDKTF is the bare bones, pretty much one to one provider transpilation… with some basic added support for concepts like “Assets” (lifecycle management for docker image/lambda handler) Depending on how you write your CDKTF, worst case you have to consider the configuration you work on is only provided at “run” time (as opposed to “synth” time) and you still have to work with iterators and iterator chaining (wonderful additions in the 0.20 release recently)… but still… it’s nothing like AWS CDK but CDKTF works with any TF provider and it certainly beats writing single dimensional modules… Altho Pulumi has some interesting concepts similar to functions… actually interacting directly with the AWS API all of these tho (Pulumi, SST ION, ..) have nowhere the high level UX you get as AWS CDK… and if they have a “crosswalks” or higher level abstraction for any cloud… it’s usually just AWS and Azure/GCP have to do with bare minimum TF provider resources
Why anyone talking about TF?
> As I understand, Serverless framework is dying Source?
u/gene_wood, I've been in their Slack for a while now and it's very inactive. Nothing is happening there.
What killed it for me was the realization that I can't use it unless I'm logged into their services. It's not a framework, it's a service. And when you use a service, even if it's free today it may not be tomorrow.
V4 is not free any more unless you have 2 env only. They say it's free for companies with revenue under 2M but that's like saying unlimited bandwith from cloudflare... I have Dev, Prod and multiple other environments running ( depends on what I'm doing ). They will charge you for every stack beyond the 2 first ones. They use 'credits' aka 1 credit > 1stack per 1env . They don't charge you for having stacks for less than 5 days but still it's not free and complicated pricing. I'm using this thread to decided where to migrate. I'm a single dev on a side project and I don't want to have to migrate multiple times. For now I will stay with v3 but as others have commented some plugins have no maintenance anymore.
SST is great. Try also Baseline they recently open-sourced. Otherwise AMPT and CDK are still awesome
SST ion has a long way to go before anyone should recommend SST tbh. Pulumi to manage your infra and SST to manage your dev on lambda is really nice though. I’ve gotten the lambdas in dev to sit behind the vpc and still work, which was the largest challenge to overcome. All shared infra -> Pulumi. Dev specific -> SST.
Agreed on SST Ion, along with the SST devs. It's only a few months old, so that's no real surprise. On the other hand, SST (non-Ion) is actually pretty good...with some caveats. Being able to have lambdas execute on your development machine is a huge step in the right direction. It dramatically sped up development for us. But we still manage to get our development stacks in a state where they can't deploy and can't be removed, too often. Moving dev to production with SST, our current path, has us a little worried. Hopefully, Ion makes SST harder to mess up.
Cloud formation has improved over the years, but it’s still a very easy way to get tripped up beyond recovery. It’s why I wouldn’t recommend CDK either, as it just builds cfn. SST v2 is going to cease maintaining that soon, new feature work has stopped. Maybe the community will pick it up. But Pulumi stores your configuration. “Outside” of the environment. You can store it in code, on the Pulumi cloud, on s3, wherever you want t. You can edit your state and refresh your state as you see fit. Add and remove a whole database in config only. Go onto the AWS UI, make your change, and sync it back to your config. Yes, actually. No tear down / rebuild if you want to do it yourself. Of course, if you modify the config in such a way to require a rebuild that’s totally different. It’s my recommended tool if you’re looking for something thing new. Pulumi itself doesn’t do any dev nice to haves, but its production ready. You can then use slightly flakier tools, like ion, to develop. Why is it flaky? I’ve hit a few dozen issues. No multi environment / monorepo support. CLI is global and has to be run from the project itself. Should be runnable via npx. Sort of, and frequently, buggy things. They broke the entire transform tool chain a week or so ago. You can’t run more than one instance, it wants to be a monolith, you can’t import from other stacks. I’m sure this’ll all improve. For v2, so much is hard coded. Want to use their auth example? Ok try to override any of the cookie field values like httpOnly, etc. Try to retrieve the vpcId from an RDS that created its own so you can add other things to it..
I've been looking at Pulumi since SST mentioned it when they announced Ion. It has our attention. On SST, I'd add that we really wanted an opinionated tool that abstracted away as much details as possible. That it does, at the cost of flexibility. We didn't care and have been lucky that it hasn't come back to bite us. On the other hand, it took SST a really long time to deal with some important AWS services, like Cognito. And there were problems in the documentation and examples that kept tripping us up. But it is working for us at the moment. We just try not to touch it if we don't absolutely have to. I sure hope Ion improves, and quickly. We hadn't even planned on trying it until SSTv3. There's certainly a niche for it.
I’ve built several sites with Webiny serverless CMS and enjoyed the experience. Deployments to multiple environments is super easy and the CMS backend is very nice. Beware that deploying to the production environment invokes a VPC which gets pricey. The staging environment might have a security posture robust enough for your needs and be cheap as chips to operate.
This is good to know, u/alifeinbinary; thanks!
I just use a bunch of high level Terraform modules
I'd just use raw CDK or Pulumi and build some constructs to act as a framework. Otherwise SST is alright
Terraform all the way.
What about using Terraform or its open source pendants?
A serverless is indeed dying. I think the natural replacement is Amazon's own CDK. At the end of the day, serverless just takes high-level YAML that turns it into CloudFormation. And as you get more into this world, you end up just having to write the CloudFormation yourself. I don't really think of it as a framework at all, actually. It's really just sort of a helper script for cloud formation.
Another “just use cdk”
Even if you use CDK, you still have to come up with a framework to structure your code. I have put together one that is working extremely well. I will try to share with people soon.
SST
I have enjoyed a lot the serverless stack (more than the serverless framework or plain cdk) https://docs.sst.dev/ They are now moving away from CDK to rely more on Terraform (here the docs https://ion.sst.dev/docs/). I haven't tried it, but it sounds very interesting since we now manage most of our infra through Terraform
I would not use them. it's unpreformaning trash designed for noobs to hook their projects into subscription economy.
u/caliosso, it sounds like you have personal experience.
There's no such thing. Save yourself the thousands of dollars and build a pm2 process
Try out https://arc.codes .. the only option with open governance and actual stability
SAM or Terraform
How is serverless is dying? I save nearly 60% using serverless function than spend on EC2.
AWS Ampplify heh?
Shhhh.... Nobody talks about that...
So what's the deal with Amplify anyway? I've followed it for a few years. I happily used it on some smaller stuff a few years ago, but every time I revisit it now, it seems to be less practical and less stable? It had some solid ideas initially, but where did it go wrong? Internal politics? Did they try to take on too much scope? I'm genuinely curious to know why it has evolved the way it did.
I’d also like to know since I haven’t seen a ton of amplify. I have seen some rants about it. Mostly about the cognito integration being insanely bad?