What are you doing to keep your business “cloud-neutral” at the technical level? Are you writing cloud abstraction layers in your code? Writing Terraform for various clouds? Any good ideas, assuming a containerized application? What about portability of your serverless code?
Typically, I organize my layers of code as such:
Business Logic, Core < Handlers < Front (HTTP routing, sessions/token stuff, ...).
The dependency can only go from the right to the left, so the BL code never gets touched when I decide to add/replace a handler or a frontend.
When you are on AWS Lambda, you code the Front: a glue between your Handlers and the AWS Lambda platform. So the rest of the project can be updated as-is in an ideal case. When you change your cloud provider, you have to rewrite the Front part again. But the layers underneath will be unchanged.
Of course, this is pure theory. In practice, some cases may require you to break this one-way chain for performance or scalability reasons...
I wrote a blog post about how easy it is to get multi-cloud robustness for single page apps here: https://blog.fauna.com/survive-cloud-vendor-crashes-with-net...
Of course it becomes more complex as the app becomes more complex. But more and more of the AWS/GCP/Azure services have multi-cloud equivalents, so this architecture only gets easier to implement.
To that end, I don’t use things with no equivalent anywhere else (Google’s Cloud Spanner), but I also don’t avoid things like RDS, load balancers, API Gateway, etc.