Uber v Lyft: A Story About Making Money in the Cloud – Issue #11

Take Note

February was a quiet month in the cloud, but March started off with a bang when Lyft filed for its much-anticipated IPO. On page 37 of an otherwise dry S-1 filing, Lyft casually mentioned that it is contractually required to spend $300 million with AWS over the next three years. It turns out someone reads these 270-plus page documents, as Twitter caught on almost immediately. There’s been a ton of discussion in the ensuing week. Is this too much to spend? Is it wise to lock in for so long, presumably in the name of a modest discount? As always, we think the question is more important than the answer, and in this case, the better question is: What did Lyft get out of their considerable investment in AWS? In this issue, we dig in and take a look at the cloud’s role in Lyft’s journey.


Uber v Lyft: A story about making money in the cloud

Lyft raised eyebrows everywhere when it filed its S-1 in preparation for its IPO. It turns out Lyft is spending close to $100 million per year with AWS. In fact, it is a contractual obligation. The media gobbled up this story, and the widespread reaction was that Lyft’s cloud spend was way out of whack compared to non-cloud alternatives. Journalists and know-it-all tech pundits on social media painted visions of hipster bean counters treating the infrastructure budget as though it was made of Monopoly money. Lyft’s engineering team was clearly a bunch of kids in need of adult supervision. While that’s a possibility, perhaps there’s more to this story.

To get to the bottom of this, let’s start at the beginning. Uber invented the ride share market, which is always nice if you can do it. The company methodically established a network of drivers and built a phenomenal infrastructure that could track them and pair them with riders worldwide within seconds. With a three-year head start, deep pockets, and an insurmountable brand with drivers and riders alike, Uber became the “verb” for ride sharing before Lyft was an idea. Uber had a strong moat around its business, deep and wide as any.

By starting slow and iterating toward their ultimate business model, Uber was able to gradually work toward an infrastructure that could support a city, a few cities, regions and then countries. This head start enabled their market domination, with no credible competition. When Lyft started, it had no drivers, no riders and no platform. The company did not have the luxury of starting slow. It had to have comparable infrastructure on Day 1 to have any hope of attracting drivers and riders.

So, what did the company do? Broke out the credit card, created an AWS account and got to work. The founders didn’t wait for data centers to be built and leased. They didn’t wait for thousands of servers to be shipped in literal containers. Instead, they built a container-based microservices platform that allowed the company to rapidly move from prototype to scale. They took advantage of serverless and zero touch AWS services like DynamoDB and Lambda. With little knowledge of Uber’s inner workings, Lyft built its own platform in a fraction of the time and cost. And … it was good!

Six years later, Lyft prepares to IPO ahead of Uber. Though lagging in overall market share, Lyft continues to consistently narrow Uber’s advantage. Lyft has executed superbly and capitalized on Uber’s missteps. But none of this would have been possible without having first built infrastructure that could compete on Day 1. And where Uber could scale out its design using late-stage funding, Lyft had to do all this with its much smaller early-stage funding.

Until Uber files for its IPO, offering insight into the company’s financials, it’s difficult to do a true comparison of whether Lyft could save money today by shifting out of the cloud and into a design similar to Uber’s. But it is abundantly clear that Lyft was able to cross the formidable moat Uber had built as a direct result of their decision to build in the cloud six years ago.

Which infrastructure platform is cheaper on a dollar-for-dollar basis is irrelevant. Responsibly managing cost is always a key priority, but nothing is more important than positioning yourself to compete in your market and grow your business. Lyft is agile, ready to respond with similar speed as the now-competitive ride share market continues to evolve.

While Uber strives to repair its image and scales back its overly ambitious operations across the globe, Lyft iterates with impunity. While Lyft has a minimum spend with AWS, it has the freedom to reallocate that spend as it sees fit at any time. Uber can’t so easily replatform, particularly when it becomes a public company — any major change it makes in design will hit its balance sheet hard. Lyft can throw it all away tomorrow and rebuild in a dozen other ways. Its balance sheet won’t change a penny. Lyft has a nice moat of its own now, thanks to the cloud.

In the News

From the Blog

Using Kube2Iam with EKS

Kube2iam allows you to enforce IAM access control policies on your Kubernetes resources. This blog post walks you through installing Kube2iam in an EKS cluster and configuring resources to use it.

Read More

What’s New

The Leading Open Source Serverless Solutions for Kubernetes (Gravitational Blog)

This article looks at a number of the surprisingly mature open source serverless platforms. Serverless has become an unexpected battleground in the cloud. On one hand, cloud providers see serverless as a way to differentiate their platform and create deep lock-in. On the other, the open source community is on a mission to use serverless to normalize platforms and eliminate lock-in. Both might be right, but it is unlikely that both will win. – Cris

AWS S3 Batch Operations: Beginner’s Guide (Medium)

With business bringing their legacy data into the cloud, the need for batch processing is increasing and AWS is listening. This blog post gives an introduction to S3 Batch Operations feature that will alleviate how tedious it currently is to manage large sets of files in the cloud. -Roberto

Size of Cloud Bill: Not about number of customers, but number of engineers you hire (Screaming in the Cloud)

A great discussion about the challenges of managing your cloud costs with practical advice and insights on how to think strategically as you navigate these challenges.    –Heather

Security Tip

I recently had a conversation on Twitter about the need for regular key rotation. AWS, GitHub and others use tools to detect and notify customers of potential IAM key breaches within minutes of it happening. And even a few minutes of access can turn your account into a crypto mining empire–or worse. So, what is the value of rotating every 90 days? Because you need to be prepared for that day when AWS notifies you that one of your access keys was breached. Regular rotation gives you confidence that you can swiftly rotate keys with minimal disruption. If your rotations aren’t smooth (or aren’t happening), it may be a sign that you need better procedures or are juggling too many keys. Use STS for developer access and IAM roles and profiles for access within AWS services. –Cris


© Copyright 2019 Rhythmic Technologies, Inc. All Rights Reserved.