Updated: May 1, 2020. See the bottom of this article for some clarifications.
Today, news broke that Zoom signed a deal with Oracle Cloud to host their cloud infrastructure, beating out AWS, Azure, and GCP.
You might expect that this is about to be a post full of Oracle bashing. You’re about to be disappointed.
If I were advising Zoom as a consulting client (particularly if we were helping their AWS Contract Negotiation), I’d have told them to do exactly what they did. And, to be honest, I do feel a little dirty saying so. Oracle makes for a terrific villain in my cloud story; remember that time I wished Larry Ellison a happy birthday?
Let’s posit, for the sake of argument, that I’m Zoom. I’m bursting at the seams as my product goes from “enterprise software” to “absolutely everyone is using it.” I can’t scale fast enough to meet demand.
I already have cloud infrastructure deals with AWS and Azure. Thus, you can pretty safely assume that I’ve gotten “the video service that we think of as Zoom” rendered down to something pretty provider-agnostic. Whatever the architecture actually looks like, we can assume it’s not something wrapped around a bunch of Lambda functions querying DynamoDB; it’s an actual cloud-agnostic workload.
We found ourselves a unicorn!
The compute costs are going to be whatever the compute costs are going to be, and storage is likely a rounding error. This is real-time video we’re talking about here. The lion’s share of that spend has got to be data transfer, given the product’s purpose.
The question for Zoom becomes rather straightforward: Who can run our application and provide reliable network infrastructure in a cost-effective way to help us run our business?
217,000 terabytes a month
The Reuters article helpfully points out that Zoom has 217,000 terabytes a month of traffic flowing through it. If we assume all of that is from inside of Zoom’s environment out to the internet (it absolutely isn’t, but it’s a fine worst-case data transfer scenario) and all of it is moving to Oracle now that the deal is signed (certainly not happening, but work with me here), according to public pricing that data transfer would cost, per month: $11,186,406.55 on AWS, nobody knows on Azure because the pricing calculator thinks I’m screwing with it when I put that big of a number into it, and $1,843,630 (hat tip to Jeffery Lyon on that; I moved a decimal in an earlier version of this post) on Oracle Cloud.
Keep in mind that these are retail rates, which Zoom most assuredly will not be paying at their volume.
But look at the difference in pricing with Oracle. You’re *starting negotiations* at an order of magnitude lower than any of your competitors. Plus, Oracle helpfully tells me that if I sign on to a 1-year flex commitment, they’ll throw in a 30% discount unprompted on their website.
There’s just no contest. AWS’s data transfer pricing is a sad joke that should give folks serious pause when evaluating a cloud provider.
And let me reduce my email burden: don’t start with me with the predictable objection: Well, AWS and Azure networking is pristine while Oracle’s is complete molten garbage.
First, I don’t necessarily accept that that’s true; presumably, Zoom didn’t sign the contract without some serious testing first. Secondly, if other providers’ networks are provably better, great—are they provably over 10x better? Because they’re definitely over 10x more expensive.
Given the reliability concern, though, I’d build in a failover model to reestablish a Zoom call connection to a fallback provider—which I suspect already exists today given their use of both AWS and Azure—and call it a day.
If I’m Zoom, I’d do the same
So yes, if I were in Zoom’s position, I’d sign the deal with Oracle and not feel a whit bad about it.
They’re clearly not signing up for Oracle’s “Autonomous Database” shenanigans, they’ve already demonstrated how portable their workloads are, and unless someone at Zoom has taken complete leave of their senses, this isn’t a 10-year deal.
It almost certainly doesn’t leverage cloud-provider-specific services, so “retraining your engineers to work with Oracle Cloud” isn’t going to be a heavy lift—particularly in light of Zoom’s demonstrated ability to work within both Azure and AWS already.
I bag on Oracle a lot. But when it comes to data egress pricing, they make AWS and Azure look like comparative crap.
Credit where credit’s due: Congratulations on the contract win, Oracle.
Update (May 1, 2020)
I’ve been getting a lot of questions about this article and requests for clarification, since some of my points were a little ambiguous. Turns out, when you write about a big story like this one, actual, proper journalists come out of the woodwork with questions! Who knew!
So, to clarify:
As I mentioned above, there’s no way in hell Zoom is paying public, retail rates for data transfer on AWS (or on Oracle Cloud, for that matter).
My back-of-the-napkin calculations highlight the fact that AWS’s public, retail rates for data transfer pricing starts at 10x higher than Oracle’s. So while Zoom certainly isn’t paying AWS’s retail rates, their discounted rate is still likely higher than Oracle’s public rate.
The real story behind this article is AWS’s horrifically-priced data transfer, which I believe had serious influence in Zoom’s decision to start putting workloads in Oracle Cloud rather than doubling-down on AWS.
And to that point, based on information we have, there’s no evidence Zoom is moving its entire infrastructure from AWS to Oracle Cloud.
Remember, data centers come with 3-7 year leases, which Zoom is likely still under contract for, and it takes serious effort to move workloads from one provider to another even with Zoom’s presumed cloud-agnostic abilities.
There’s also no evidence they aren’t moving everything, so who the hell knows. What I do know is that “migrate cloud providers” during the middle of your busiest time as a company ever probably isn’t even on the table. Eric Yuan, CEO of Zoom, did recently comment about this in a public AMA that they are still actively using AWS but he didn’t comment about what the future might hold.
