Multi-Cloud isn't a trap any more than any other practice is a trap. Any practice is a trap if it takes away from your core mission too much or requires resourc

Multi-Cloud isn't a trap any more than any other practice is a trap. Any practice is a trap if it takes away from your core mission too much or requires resources you don't have. I call such things "engineering bikeshedding" -- solving some other problem instead of your core problem. I think doing multi-cloud for something "normal" and mundane is probably over-engineering. If you want to avoid vendor lock-in just avoid using the most proprietary features of your cloud vendor, or use them in ways that would not be terribly hard to port later (e.g. it's not hard to swap something else out for S3). Yes your DC or cloud provider will have issues every once in a while, but in the grand scheme of things it won't matter unless your service is one that demands damn near 100% uptime as a strict requirement. Multi-cloud makes sense when you need near-100% reliability. There are few things where reliability requirements are this stringent. It can also make sense when you need a great deal of geographic diversity or portability.