https://serverless-stack.com/ logo
Join Slack
Powered by
General question, based on a discussion that I’m h...
# general
a
General question, based on a discussion that I’m having with some developers on my company. I started to use SST/CDK for some of my new services in the company, and other teams has been using SDK. For example, to create queues, or buckets…. The discussion is around… why would somebody stop using AWS SDK and move into AWS CDK? I’m looking for some lecture, or documentation that I can share with my team. I love CDK due I’m coming from a Serverless Framework background and feels natural to me. But some other developers are SDK users and they have a different mindset.
s
How do they use AWS SDK? Are they writing custom scripts to create resources with the SDK directly? I'm not sure I understand the comparison.
a
I’m not SDK expert.. but it looks like you can create queues, buckets, etc, “on demand”.
They create those from the JS client, basically.
Instead of pushing things to a Queue, they check first if exists, if it doesn’t, they create it (with SDK).
I always used SDK as a “client” of the infrastructure.
But there are those cases where the SDK can also perform changes on the infrastructure, not only “consuming” resources but “creating and managing” them.
So that’s where it gets confusing for these guys… they don’t see the benefit of having CDK projects, if they can do “all in one place” within the SDK.
I want to hear if other people had those discussions before, or it’s just me 😂 .
In my mind… it’s kind of… SDK it’s the low level layer, and CDK is mid level… then SST it’s on top of all.
b
so in their code, everytime they want to send a message to an SQS queue, they first check if that queue exists, and if it doesn’t create it? if that is the case, it seems like they are sticking IaC code into business layer code.
s
I think of the SDK as a totally separate tool than CDK.
a
Yes, I think the same way.
s
a
I think CDK purpose is to encapsulate infrastructure in an isolated layer.
😮
s
CDK is Infrastructure as Code, which means you can write code to create AWS resources like API Gateway, DynamoDB or Lambda. On the other hand SDK helps to interact with these AWS resources for ex: fetch the items from DynamoDB or list the contents of S3 bucket.–
b
also, IaC should be in charge of creating the entire environment. and then business code should do business work, but have some assumptions on the existence of the environment or just proper error handling.
s
☝️ That's how I think of it
a
Yes, I see it the same way.
Going to take some definitions from that thread.
b
yea, using sdk to script out building your infra is an anti pattern
s
I....didn't even know that was possible 🤷
b
especially because cdk compiles down to cloudforamtion. meaning you have stacks of resources.
whereas if you are creating everything ad hoc with sdk, it is a bit harder to manage from a devops perspective
s
Wait, what if they are using the SDK to interact with Cloudformation 😆
a
They don’t use CF… is one of my main complains.
But with SDK you can create CF too, I think.
b
yea, this is for accessing cloudformation
not really building the templates
a
Copy code
createStack(params = {}, callback) ⇒ AWS.Request
Creates a stack as specified in the template.
b
yea you can build it that way. i am guessing they did this before CDK even existed. old habits die hard
a
Anyway they don’t use CF.. they just use SQS SDK, S3 SDK, etc…
Yeah, for sure, old habits.
CDK it’s pretty new, to be honest.
b
do they have scripts just for the creation side of things. or do they have it interspersed in the business logic?
a
It’s part of the business logic… another pain point.
b
ouch, yea. that can be problematic for trying to create a new environment
s
My sincerest condolences
a
Yeah totally. Also it’s imposible to re-use resources.
Hahaha, yeah, part of my job is to get this right… luckily CDK exists and makes my life easier.
s
I've found myself in this position before; having to explain how something should work from the position of being absolutely baffled about how it's currently being done
it's not an easy task
I mean, in many respects, it's not a technical problem you're facing
a
Yeah I know… this is the hard part of the job right? writing code is easy, haha.
Many times it’s a cultural challenge… but well… there is no ideal world.
d
I am late to this convo, but it sounds like you are really arguing the virtues of DevOps and IaC, not so much CDK vs SDK. AWS actually does a decent and concise job of this, imo:
Infrastructure was traditionally provisioned using a combination of scripts and manual processes. Sometimes these scripts were stored in version control systems or documented step by step in text files or run-books. Often the person writing the run books is not the same person executing these scripts or following through the run-books. If these scripts or runbooks are not updated frequently, they can potentially become a show-stopper in deployments. This results in the creation of new environments not always being repeatable, reliable, or consistent.
In contrast to the preceding, AWS provides a DevOps-focused way of creating and maintaining infrastructure. Similar to the way software developers write application code, AWS provides services that enable the creation, deployment and maintenance of infrastructure in a programmatic, descriptive, and declarative way. These services provide rigor, clarity, and reliability.
b
Yes a bit of that. But he is also saying that the code base has a good amount of IaC sprinkled in it. For instance, something like checking if a queue exists before writing to it, and if it doesn;t then creating the queue then writing to it. Which can be quite problematic for a few reasons.
c
whereas if you are creating everything ad hoc with sdk, it is a bit harder to manage from a devops perspective
I think this is a bit of understatement 😛 If you're not using stacks, or religiously tagging resources managing your assets/infrastructure will be a downright shit show. This is how security issues and ballooning costs creep into cloud workloads
Well this and NATs
g
Another argument to make here is that CDK is declarative (yes, despite using an imperative langauge). The output is a description of what the infrastructure should look like and CF automatically applies that for you. This especially comes into play when you need to apply changes to some deeply nested resource e.g. permissions. If the infrastructure is described imperatively, you might create a queue if it doesn't exist for example but forget to apply permissions the first iteration of the code; after you merge an update that does set the permissions, it will work for subsequent queues but not for the first one (since it already exists and the imperative check-create action skips it)
(this comparison might also work in fullstack circles: its sort of like VDOM vs DOM 😄)
Open in Slack
PreviousNext
Powered by