On Uber and IT Infrastructure

Uber is doing their part to disrupt an industry that hasn’t seen much innovation in decades. And for cities whose public transportation is only moderately effective, the change cannot come fast enough. But what is Uber actually providing? And based on that, what are they competing for?

With any ride service, the temptation is to think of the business primarily as shuttling people to and fro. Accordingly, people building out this type of business have focused on adding ride capacity. For cab companies, this meant adding additional vehicles. Cab drivers are basically renting the cabs from the owners. For cab companies, the business more closely approximates property rental than anything else. And given the wages for drivers and the general way they are treated, it is probably not a surprise that cab owners have a reputation not unlike slumlords.

So you take an industry that is generally reviled in many major cities (New York stands out as an exception here) and you fail to really evolve the business model for decades, and you end up with something that is ripe for disruption.

Enter Uber. But what is Uber really doing?

They aren’t going out and buying a fleet of cars like the cab companies and black car services that have cropped up. Uber is really not about transportation. What they have done is create a clever way to identify available capacity in the system, and then deploy that capacity as needed.

If you look at where Uber is most successful, it is in cities where cab service is dreadful. By dreadful, I mean that it is difficult to get a cab in a timely fashion. Take San Francisco, for instance. Getting a cab in SF can be nigh impossible. Even when you call central dispatchers, wait times can be atrocious. And if you are trying to use a cab on a high-volume night, you are better off packing some comfortable shoes and hoofing it around the city. For San Francisco, Uber represents a painless way to get just-in-time delivery of a ride service.

Because Uber’s business is around discovery and redeployment of capacity, the real competition for Uber is not for fares. To scale their business, they need access to more fluid ride capacity. The more capacity they have in the system, the better their deployment service. They can extend their reach and shorten the time-to-wait for a ride service. This means that the real fight Uber needs to win is the one for drivers. It’s not the cab companies so much as the other ride sharing services (like Lyft) that threaten to cap Uber’s ability to add additional capacity.

So what does this have to do with IT infrastructure?

IT infrastructure generally (and data centers in particular) are about providing resources to satisfy application or tenant workload requirements. The capacity required takes three general forms: compute, storage, and networking. The objective is not merely providing some aggregate capacity but rather pairing that capacity with a specific demand. And as cloud continues to grow, it is increasingly about providing just-in-time delivery of that capacity.

On the compute and storage side, we have solved a big part of this challenge. Virtualization essentially frees up compute resources, which means that application workloads can be satisfied as-needed through application portability. If you need additional horsepower, you launch a new application instance on a VM that resides on some server with capacity to give. In this context, the dispatching of available capacity is moving the application workload to a server. And tools like DRS allow for the definition of resource pools that can then be allocated as needed.

But what about the networking side?

To date, the networking world has evolved in much the same way as the cab companies. The game has always been about adding addition cabs to the fleet (more capacity to the network). And while we can use monitoring tools to determine where capacity is not being fully utilized, there is no simple means of dispatching that capacity to where it is needed. Additionally, even the tools we have to shape paths are not particularly well-suited for providing just-in-time capacity.

There is an opportunity in the networking space to move in this direction. SDN as a movement provides a couple of tools that are architecturally necessary if this is to become a reality. A central controller is a logical way to locate available capacity. With a global view of the network as a resource, the controller is in a unique position to see how the physical transport is actually being used.

But imagine using Uber if it only told you where the available cars were but could not dispatch them to you. Without performing both actions – locating and dispatching – the service is incomplete. So it is in networking. Knowing where capacity resides is interesting but not terribly useful. The network needs the ability to dispatch that capacity to suit the applications. And one final point, whether dispatching occurs in the moment or at a scheduled time is dependent on the needs of the customers (applications or tenants, in this case).

Ultimately, what Uber is doing is actually quite impressive. But there is subtlety in the strategy and the innovation. The whole of IT might be able to learn a bit from Uber’s creativity.