Hi guys, just wanted to let you know how happy we ...
# sst
m
Hi guys, just wanted to let you know how happy we are with what you did with sst. We can't wait to get rid of all the serverless component code.
a
I did it after some months, feels good to have all in TS 🙂
d
@Martin Wawrusch You’re coming from Serverless “*Components*”? We we’re following that framework since early dev. We continuted to use Serverless “Framework” (CFN base) at the time and never really used “Components” (CloudProvider SDK base). Interested in your perspective on why the switch over to CDK (CFN base)?
f
Thanks @Martin Wawrusch! That’s awesome to hear 💪
@Dan Van Brunt i played with components a bit, it seems the infrastructure state was stored and managed on SLS’s server. I’d be more comfortable if the state was backed by something more mature like Terraform.
m
We started with the original Serverless Framework many years ago (0.2 or 0.4), but needed a working AppSync config very early on, hence using 'components' - unfortunately it had at least two bugs in multi account configs that would randomly update roles in the wrong account, or not update at all, taking down production systems. Bothe on a semi regular bassis. Serverless was not interested in fixing those bugs... I am in the business for many years and have never seen a company managed as badly as serverless. Not to mention their chaos when it comes to issue management and them not reacting to any kind of suggestion for example if you ignore issues on github it's probably better to close issues there and redirect the users to a central platform.
oh and their UI was atrocious - adding new services, after an upgrade, was a multi step with first publishing, then updating the providers interactively, then publishing again. And it was no infrastructure as a code.
d
@Frank https://serverless-stack.slack.com/archives/C01HQQVC8TH/p1643177467184000?thread_ts=1643150746.182400&cid=C01HQQVC8TH 💯 Early on in the development I was talking to Austin and said as much myself. Saw the benefits of a platform that wasn’t tied to any one single CloudPlatform, however, did not like the idea of needing to rely on SLS server to deploy, nor have the deploying machine be the thing you needed to rely on. Eg. With CFN, its CFN that is responsible for provisioning and state management, not your local machine.