I know what you mean but it’s been quite fine for me. With AWS, you have a JMS compliant message router in SQS, and SNS is okay, just might need an adapter to the message schema. I don’t like some of their limitations that are foreign to me when integrating over Artemis, Pulsar or Rabbit, and Kafka. Lambdas are just runtime system containers, you can use Spring Cloud Functions or any of the myriad of compatible approaches. RDS is but a scaled HA Postgres or MySQL service. Redis, DynamoDB, MKS, Keyspaces, and so on, can all be hosted on-premises. Not really a lock-in.
> I don't think that's the way most people are going anyway
Unfortunately some are. And not only that, but also full steam ahead on a 100% locked-in, read _all_ the AWS (serverless)services, AWS-only stack. I speak from unfortunate experience.
Yup me too. Just got out of working at a B2B SaaS that was 100% AWS serverless - Lambda, S3, dynamoDB and all that.
I worked there for 3 years! When I started 3 years ago - the owners touted the benefits of all of it. And I agree its not all totally bad. There are some valid use cases for small enterprise projects.
BUT after 3 years it was really starting to wear me down. The codebase just kept growing, there were so many lambdas to keep track of. It was so hard to test and observe the system in production. Sure you can address some of these pitfalls by creating your own tools that wrap AWS API calls but it never ends. It doesn't make your life easier, you still have to write a bunch of extra glue code because a lot of the tooling for these serverless platforms is terrible and left up to frameworks to solve.
