I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to throw more resources at a specific part of the whole.

Second - with each cloud provider's serverless service, I've noticed that the underlying complexity is shifted into your application and provisioning. They're a great example of leaky abstractions. The name 'serverless' may lure you into thinking that you don't need to think about servers any more, but actually you do have to adjust to the way they've implemented a service that you're using. Think of Lambda cold starts, or have a look at the DynamoDB pricing page. There's still a server running somewhere.

Personal experience: I've found that ECS (Fargate) is a decent step into the serverless realm, if you've been running normal containers on normal EC2s. It does take away the EC2 management aspects, and it's especially useful if you have some applications that are resource hungry, and some are not. It's a cheap way to run ETLs (we use the ECS Operator from Apache Airflow, which itself is on EC2). It doesn't take long to learn, and it's a good place to start. It does come with its own baggage... the 'stack' that you had on a single EC2 is now scattered about; you may need AWS Cloud Map for service discovery, ALBs for networking, SSM/KMS for secrets, Cloudwatch for logging.

That's when you realize, those sticker infested laptops at Devops conferences are actually modern architecture diagrams.