Before designing anything, the architect owes the organisation an honest answer to whether multi-cloud is needed at all. In most cases it is not, and adopting it anyway doubles complexity, dilutes expertise and delivers none of the benefits people expected. This lesson lays out the case against, so the decision is made with eyes open.
The costs
Two sets of services to learn, two identity systems, two networking models, two billing structures, two security postures, and tooling that must abstract over both. Teams become shallow in each rather than deep in one.
The benefits that do not materialise
Portability rarely arrives because applications depend on managed services. Price leverage is weaker than expected. Resilience across providers is undermined by the shared components that connect them.
The honest recommendation
For most organisations, one primary provider used deeply, with exit planning and open standards where cheap, beats two providers used shallowly. Say so, in writing, before proceeding.
Action Step
Write a one-page memo for a hypothetical leadership team arguing against multi-cloud for an organisation you describe, listing the costs concretely. Keep it; the next lesson writes the counter-argument.
This course is vendor-independent: it is not affiliated with, endorsed by or accredited by any tool vendor or certification body, names products only for identification, and issues no credential. Verify current documentation before applying anything in production.