I've been advocating for a multi-cloud strategy for the last six months because running everything on AWS is leading to vendor lock-in. As we've seen, the pricing benefits from savings plans are lessening, and the risks of a single provider are increasing. Leadership is satisfied with AWS's service levels and has pushed back against increasing complexity or potential security risks. However, I believe that as our code and workloads change, as does traffic and external provider pricing, our architecture needs constant re-evaluation to remain efficient.
I performed TCO models projecting a 30-40% reduction in compute costs by redistributing CPU and memory-heavy workloads to Google Cloud Platform using their discounts and spot pricing. But leadership thinks this is over-engineered and hypothetical.
The real value is in ongoing cost performance and resilience assessment rather than a one-time migration. We're facing increasing traffic due to upcoming events, and the current setup could lead to severe scaling issues. I'm torn between pushing for a solution now or waiting for a cost or availability incident to start a conversation. I'd love to hear from anyone who has navigated similar challenges and how you communicated the need for continuous optimization instead of unnecessary complexity to your leadership.
5 Answers
You're spot on. Cost, performance, and resilience should be ongoing evaluations, not just a one-off decision based on past data.
Consider the financial fallout from a small DDoS attack and explore bandwidth costs across providers—AWS's rates can be high. This can illustrate the risks better.
Cost optimization seems abstract until a traffic spike hits, and then the impact is crystal clear. A proactive approach is key!
This isn’t just about multi-cloud; it’s essential to avoid regretting missed opportunities during an incident. It’s about laying the groundwork now to prevent future pain.
Rather than pitching multi-cloud, focus on an adaptable workload strategy. You're suggesting the right tool for each job while keeping continuous cost evaluations, which is simply good engineering. A solid approach is to start with a single, high-cost workload on GCP for a trial period, gather data, then scale up if the results are favorable.
Exactly! Gradual steps and tangible data can ease those fears of over-engineering and show real benefits without drastic changes.
That makes a lot of sense. Propose a small, controlled experiment rather than a full-scale migration—people are more likely to buy into that.