SST Ditches AWS CDK: Time to Move on to Ion
• 5 min
Serverless & Cloud Development Specialist at Fively Passionate about serverless and cloud technologies, I share insights based on my experience. Exploring and advancing modern cloud development.
Explore how SST shifted from AWS CDK to Ion, uncover the challenges of the old bucket construct, and see the benefits of starting new software projects with SST 3 Ion.
As we all know, staying ahead means embracing the latest in technology and innovation fields. Recently, SST, a pioneer in serverless solutions, made a significant shift by moving away from the AWS Cloud Development Kit (CDK) to Ion, a new and promising framework.
This bold move signals a change in how developers will build, deploy, and manage cloud resources. With this article, I want to study the reasons behind SST's decision to transition to the new version, explore its benefits, and discover what it means for the future of cloud development.
AWS CDK Concerns: Why It’s Not a Good Choice Anymore?
First, let’s start with AWS CDK: what’s wrong with it in the context of SST?
Well, the first two versions of SST were basically the wrappers and enhancers of AWS CDK. If we go to any construct of the first two versions of SST we will find a connection to AWS CDK (look at imports):
In fact, these first two versions allowed us to use AWS CDK and SST together in one codebase. For example, SST never provided the constructs for Step Functions, but developers could seamlessly use AWS CDK’s constructs to describe and manage Step Functions, demonstrating the compatibility and extendibility of using both tools together.
The deployment process was based on AWS CDK as well, which included Cloudformation template generation and stacks deployment. However, the reliance on AWS CDK brought with it lots of limitations, particularly in terms of deployment speed and transparency, so that the deployment time was unpredictable.
Also, developers could often face the infamous “ROLLBACK_FAILED” status and then you need special techniques to deal with the status as well as your panic attack.
The worst nightmare was cycling dependencies of stacks. This was not just a minor inconvenience - it fundamentally impacted how infrastructure updates could be managed. It also meant that if you need to update your infrastructure then you just update it.
For example, when you need to do something as simple as renaming a stack in the CloudFormation model, then you don't merely rename the existing stack but instead need to create an entirely new one.
Such CDK behavior necessitated meticulous planning from developers. If you already have a resource that you need to “check out” into your IaC and then update it, then you need to use Custom Resource, which significantly complicates the update process, and so on and so forth.
This has damaged a lot of mental health for every developer trying to manage and scale their cloud infrastructure efficiently. But it was not SST’s fault. These were faults inherited from AWS CDK and CloudFormation.
So what SST decided to do is that they ditched AWS CDK and jumped from templates-driven IaC to API-driven IaC. This meant that the resources on the lower level were created by AWS SDK and managed by SST instead of Cloudformation.
For this, they found out that Pulumi which uses Terraform Providers (because it uses Pulumi Classic) is the best option.
How SST 3 Ion Will Work?
Below, you can see a piece of the new SST bucket construct. Just compare the previous bucket construct with a new one: you may notice right away the imports from Pulumi. It means the whole deployment process will be built on Pulumi now.
With the integration of Pulumi, SST now supports all of the Pulumi packages, which opens up a vast array of new capabilities and integrations previously unavailable in the older versions that relied solely on AWS CDK. This includes access to a wide range of Pulumi's own components, along with a large number of custom components developed by SST itself.
The most radical advancement is that they can support other clouds as well now! SST now includes support for providers beyond AWS, such as Azure, Google Cloud, and even niche providers like Cloudflare, for which SST has already created a number of specialized components. This capability, known as providers in Pulumi's terminology, allows SST to operate across different cloud platforms seamlessly.
That’s not everything! One of the most groundbreaking features introduced with the move to Pulumi is the ability to link resources from one cloud provider to resources from another. This cross-provider linking eases the creation of multi-cloud infrastructure as code (IaC), so that you can manage and orchestrate your applications across multiple cloud environments using SST's enhanced and user-friendly API.
Should I Switch to Ion or Stay with SST v2?
So, my advice is the following: if you already have an old SST codebase - switching to Ion will not be a trivial task. The underlying architecture changed so radically that we are talking about two different libraries here. It will require a careful consideration of how much effort it can be and how to avoid downtimes.
However, if you have a brand new project, then surely you should start with SST 3 Ion: the benefits of adopting this platform are clear and significant. While the SST 3 Ion is not officially stable yet I don’t think it will be an exaggeration to say that we are one inch from there. The creators of SST are very public and well-known on X/Twitter, and it drives them to do their best to fix bugs very fast. Thus, you can join their official Discord - in my opinion, some of the bugs could be resolved in a couple of days.
Also, if you need expert guidance or hands-on assistance with your cloud projects, Fively cloud specialists are here to help. Whether implementing a new project with SST 3 Ion or transitioning from an older system, our team can provide the support and expertise necessary to ensure your project’s success.
Stay tuned for more like this.
Services Account
Need Help With A Project?
Drop us a line, let’s arrange a discussion
