For me it is SST, IF it is not a huge enterprise/consulting project. There I still don't trust it to 100% unfortunately. Then I'd probably go with plain Pulumi 🤔

The whole performance of this API is now determined by the slowest function.

That is probably the first sign to start decoupling your architecture a bit, figure out your most crucial workflow (publishing the post) and put the rest on the background. Fire & forget 🚒

1️⃣ Publishing the post
2️⃣ Calculating analytics
3️⃣ Backing up the post in GitHub
4️⃣ Sending a newsletter

You API is still a 𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬 request 🔄

That means your user sits and sees a loading indicator until all of that is finished.

But for real incident alerting I definitely recommend creating composite alarms and not just metric alarms. Simple to not have alert fatigueness.

What are your typical composite alarms?

By not just looking at Lambda errors you can eliminate false positives by also just looking at 500 HTTP errors.

Of course, this depends heavily on your context.

The screenshot you can see are all my shared accounts for my current side projects.

Once you sell one (happened already) you can simply transfer the account to a new organization and done!

For development typically my dev profile like `ck-dev` and for production deployments `ck-prod`

For the few accounts or clients that are still on IAM Users or assuming IAM roles I have them in my "normal" sessions within Leapp.

In Leapp I log into my SSO session and can then activate the account I need.

Since they are all on different profiles I can simply activate them and my IAC (CDK or SST typically) is using the correct profile.

(the script below is from @marcbowes article - marc-bowes.com/dsql-how-to...)

Yes - it is not a proper application. But still having a SQL DB at hand to make some basic aggregations helps A LOT.

I'm hyped to see how it will be used
I'm a bit afraid of calculating upcoming costs

- A much larger plan (Business) was added that supports

Let's see how it goes!

These combined with recordings give you insane insights!

Posthog has such a generous free tier - it really only costs you if you have lots of views.

In event-driven the producer shouts: "Hey eventbus, I published a post. I don't care what happens next, I'm done"

This is the main difference if you build things event-driven.
Your producer doesn't need to know what happens next.

In function-driven the producer shouts: "Hey Lambda, do that next!!!"

At a certain point this won't scale and can have drawbacks. Nevertheless, I would always start with that!

In an 𝐞𝐯𝐞𝐧𝐭-𝐝𝐫𝐢𝐯𝐞𝐧 world the API would put it on some kind of event bus - and THATS IT.

It doesn't care nor does it know what happens next.