Absolutely, and not said enough — but do this in a risk managed way. Hold yourself accountable to really give that thought. Terretta doctrine on this is “Aggr

Absolutely, and not said enough — but do this in a risk managed way. Hold yourself accountable to really give that thought. Terretta doctrine on this is “Aggressively exploit CSP differentiation, with a credible migration plan you keep in the drawer.” To borrow an AWS metaphor on “One way doors versus two way doors” decisions, do pre-think, but don’t pre-code. Just think as you design the house about whether you might someday want to go through that door another way. It’s inexpensive now to make design decisions that make that easier later. At an enterprise, fully understand the BCP or business continuity plan. You will likely be stunned how long functions are considered OK to be offline for regulator-compliant BCP planning purposes, relative to the SLAs that I.T. gets yelled at about. Your job before committing to vendor lock in is to write down a plausible plan to get out of the lock in that fits (when effort is doubled twice) inside the BCP plan window, and maintain that plan as part of the platform documentation for the capability in question. When you study the economics of re-investment by Azure, Google, and AWS, it’s impossible for an enterprise to achieve the same capability-evolution curve without floating on that rising tide. The hard part is to figure out how to not get capsized by change waves or get swamped if the CSP pulls the plug in your boat. These are part engineering, part business/procurement/legal problems, but much less costly than holding yourself to either a lowest common denominator or fully abstracted principle.