In a previous post, I suggested that Uber’s business model was less about rides and more about locating available capacity and dispatching it to wanting customers. That they happen to be working with ride capacity is almost secondary; the business model is based more on location and allocation than on the ride itself.
But that is not all that Uber has done.
Uber realized quite early on that they had to make the transaction of requesting capacity centered around the customer. While most cab companies had a central dispatch, the entire orientation of the operational model was centered around the company itself. Customers were the drivers of the business, but they were an afterthought in the operating model. Is it any surprise that these same customers eventually decided they were fed up and embraced with open arms a new ride service?
As we extend the analogy of Uber to the network, it means that whatever mechanism we devise to request new capacity has to be oriented around the users of that capacity. In a cab setting, the users are paying customers; in a network, the end users are the applications or the tenants consuming the capacity.
Uber’s problem was slightly easier to solve than the IT equivalent. Uber’s ultimate end users are live, frequently thinking (though not always after a night on the town) human beings. When they need capacity, they are capable of taking action on their own. But Uber just didn’t set up a phone relay service. Instead, they created an interface that required only minimal input.
In essence, what Uber established was a basic interface using a language that both the user and the system could speak. All the user has to provide is a pickup location and the type of service (black car or UberX). By allowing the transactions to take place in the simplest way possible, dispatching of capacity in a timely fashion is possible. There is little overhead, and most of the transaction can be either automated (in the case of making the request) or distributed (in the case of validating the request).
This is an extremely simple model, but the simplicity should not be mistaken for a lack of sophistication. The process of requesting capacity has been difficult for years. You either hold up your hand and try to catch a speeding car, wait in a taxi line, or make a phone call and hope your ride shows up in a timely fashion. Reinventing this process takes a lot of the pain out of getting a ride.
Applying the concepts to the network, requesting capacity is exceedingly difficult. First, there is no real shared language between the applications and the network. Second, making requests frequently requires manual configuration changes, or relies on a set of systems that are ridiculously difficult to engineer and maintain. The result is that the idea of even requesting capacity is so foreign as to be unseen in most networks. And while hardcore network engineers are quick to point out the various pathing technologies that exist (“Isn’t this what MPLS solved a decade ago? Or ATM a decade before that?”), what they are missing is that the issue isn’t just allocating capacity – it’s the process of requesting that capacity in the first place.
Beyond the initial request, Uber does three other things that are simple but effective in their request-dispatch model.
- First, they have a built-in validation loop. After you request capacity, drivers get information about the requestor. They can then decide whether they want (or can) provide capacity. And finally, they call the requestor to verify.In a network context, as soon as you make it possible to request additional service (be it bandwidth or any other network service), you can assume that every application or tenant will try to take advantage. You cannot have a blind system of request-accept. There needs to be a verification step that, minimally, checks who the requester is and checks how the request fits relative to current load and other requests on the system. This provides a meaningful way of doing prioritization. It could be that some applications are always granted capacity, but other applications are only granted their requests if load is below some threshold.
- Second, Uber has built a simple way of paying for the transaction. This is more than just swapping credit card numbers. The application tracks when the transaction begins and, perhaps more importantly, when it ends. Sure, money exchanges hands, but this also provides information to the system that indicates capacity is being returned to the available pool.Within a data center, allocating capacity is great, but not every application or tenant flow is a long-lived flow. If the transaction is complete, the system needs to know. And in the case of service providers (or cross-charging IT centers), there might even need to be an exchange of digits (or a logging of service for later billing).
- Finally, Uber builds in a two-way reputation system. Both the rider and the driver rate the experience. This allows riders to dodge sketchy drivers and drivers to avoid annoying customers. It also provides a metrics-driven way of evaluating whether the capacity dispatch service is pleasing customers.It is not just getting from point A to point B that matters; the quality of that journey is important too. In networking, it is not just about connectivity. Increasingly, IT is being measured on application experience. Building in a closed-loop feedback system can be an effective way to ensure this. For example, if a particular path is optimized to minimize loss, then loss statistics might be a good way to validate the service. If it is about speed, then ingress-to-egress latency might be a more meaningful metric. Whatever the success criteria, it needs to be specified, measured, and ultimately evaluated.
Uber has done some very clever things to round out their operational model. All of it starts with a deceivingly simple interface that makes requesting capacity simple. Networking could do well to adopt similar philosophies.[Today’s fun fact: Everyday more money is printed for the game of Monopoly than for the U.S. Treasury. I wonder if that is in terms of number of bills or total value of those bills. A single trillion-dollar note might tip the scales.]