SSTはCDKを捨ててv3へ、serverless開発の「localでdebugできない」をどう解いたか

冒頭：serverlessの「localでdebugできない」を狙った

SSTは、serverlessを使いたい開発者がlocalで変更を試し、cloud上の実行環境をdebugする難しさに向き合ったframeworkだ。

2021年7月の公式発表では、公開から約5か月でGitHub stars 2K超、downloads 60K超、Slack community約500人、seed $1Mまで到達していた出典。

創業：Jay VとFrank Wangがserverlessの開発体験を再設計

Jay VとFrank Wangは、Serverless StackとしてSSTを立ち上げた。

Jay Vは公式ブログで、SSTの目的をfull-stack serverless applicationを作りやすくすることだと説明している出典。

最初の価値は、local machineからcloudへ直接接続し、breakpointとinspectを使えることだった出典。

転機・苦労：CDKの限界と大規模な書き換え

SSTはAWS CDKとCloudFormationを土台に成長したが、約3年使った後に設計上の問題へ直面した。

公式ブログは、CFNのblack box性、resource linking、rollbackなど複数の実務上の問題を挙げている出典。

ここでIonという新しいdeployment engineを作り、PulumiとTerraformを使う方向へ舵を切った。

既存ユーザーにはmigration負担があるため、v2の保守も続けると説明した出典。

成長・成功：SST v3でinfraの範囲を広げる

2024年8月、IonはSST v3として正式リリースされた。

SSTは新しいdeployment modelでgotchaを減らし、AWS以外へも広げられるようになったと説明する出典。

その後、ECS/Fargateのcontainer supportやnative Windows support betaを追加し、serverlessだけでなくcontainer applicationも同じframeworkで扱う方向へ進んだ出典出典。

結び：抽象化ではなく、開発者の時間を取り戻す

SSTの道のりは、AWSの複雑さを隠すだけでなく、local開発、deploy、運用を同じcode-first体験にまとめる試みだと言える。

Jay VとFrank Wangが始めたこのprojectは、OSSのcommunityとConsoleを組み合わせながら、開発者がinfraではなくproductに時間を使える状態を目指している出典。

SSTのPMFは、AWS serverlessの柔軟性を保ちつつ、Console操作とIaCの複雑さを減らしたいTypeScriptチームにある。

公式説明はfrontend、API、database、bucket、queueを一つのconfigで定義できる点を前面に出す出典。

2021年の資金調達発表では、local machineからcloudへ直接接続しbreakpointを使える開発体験が、serverless採用時のdebuggingの痛みを狙っていた出典。

SSTのmoatは、単なるdeployment CLIではなく、frontendからdatabase、containerまでを一つのprogramming modelに束ねる実装とcommunityの蓄積。

v3でAWS CDK依存を外し、provider拡張へ進める設計も後発との差になる出典。

ただしcloud vendorの進化で優位性が薄まる可能性はある。

中程度。

frameworkそのものはsingle-playerだが、GitHub contributors、community、examples、OpenNextやOpenAuthなど周辺OSSが利用価値を増幅する。

2021年時点でSlack community約500人という初期のcommunity tractionも確認できる出典。

主対象はTypeScriptでfull-stack appを作るstartup・product teamと、AWSを使うがCloudFormationの細部に時間をかけたくない開発者。

local debuggingとpreview environmentを重視するチームに向く。

一方、cloudを完全に抽象化したい非技術組織や、vendor lock-inを極端に避ける組織には向かない出典。

第一に、local developmentとcloud infrastructureを同じ開発体験へ近づけたこと出典。

第二に、単一のconfigで150+ providersを扱う統合設計出典。

第三に、CDKからIon、SST v3へ移行してgotchaを減らし、AWS以外へ広げられる基盤を作ったこと出典。

第一に、CDK/CloudFormationからIonへのmigrationは既存利用者に負担を生む。

SST自身もv3 migrationはsimpleではなく、v2を保守すると説明している出典。

第二に、AWSやPulumi/Terraformの抽象化が増えるほど、debuggingとprovider差分の理解が必要になる。

第三に、ConsoleのSaaS収益とOSS frameworkの価値を両立する長期モデルは要確認で、公式に具体的な売上は公表されていない。

初期はOSS、Guide、GitHub、communityでserverless adoptionの障壁を下げ、seed round後にteamとcommunityを拡大した出典。

その後はSST Consoleをoptional SaaSとして提供し、v3ではcontainers、Windows、複数providerへ広げる。

機能範囲を広げるほど汎用性は増す一方、初心者にとってのmental modelは複雑になりうる。

主要チャネル: content, seo, twitter, github, discord, wordOfMouth, partnerships

抽象化はproviderを隠すだけでなく、開発者が日常的に困るlocal developmentを改善して初めて価値になる。

SSTはCDKを捨てるほどの設計変更も、既存利用者向けにv2を保守しながら段階的に進めた出典。

大きなmigrationでは、new architectureの速度とold versionの安心を同時に提示することが重要だ。

日本のstartupや社内開発では、AWSを使いながらIaC・preview環境・運用の人手不足を解消したい需要がある。

SSTは「AWSを隠す」より「コードで明示しつつlocal開発を速くする」提案として説明しやすい。

日本語docs、AWS partner支援、enterprise supportが揃えば導入障壁を下げられるが、国内のsecurity・運用要件への適合は要確認。