Welcome!

@CloudExpo Authors: Liz McMillan, Zakia Bouachraoui, Yeshim Deniz, Pat Romanski, Elizabeth White

Related Topics: Containers Expo Blog, Java IoT, Linux Containers, @CloudExpo, @DXWorldExpo, SDN Journal

Containers Expo Blog: Article

Uber Taxis and New Business Models

In a world of NFV we cannot easily map the businesses & business models of today onto the possible business models of tomorrow

A recent post by John Wilmes on the TM Forum website caught my eye for drawing a parallel between the Uber car service business model and the telecom service provider business model as network functions virtualization (NFV) becomes a reality. Wilmes uses this metaphor to remind us of the potential value of dynamic pricing as a tool in carrier efforts to match supply to demand. He also cautions service providers to be careful how they sell the message of dynamic pricing to their customers. So far, so good.

However, this gave me pause: "NFV will let them [operators] create more of almost any part of their infrastructure on the fly, and turn it off when no longer needed, but that too comes at a price - one that is proportionately much higher than what Uber faces. While Uber needs only to make minimal investments in drivers who furnish their own cars, operators also have to buy the ‘cars' up front, or at least reserve them from infrastructure providers."

The message seems to be that customers may face a future of higher prices, supply shortages or both, if surge pricing takes over thanks to NFV. This rather surprised me for two reasons. First, taxis and buses are more efficient in their use of road and energy resources than cars are, even if we still like to drive our own cars sometimes. Similarly, MetraTech became actively involved in the European Telecommunications Standards Institute (ETSI) NFV program mainly because we believe that NFV would result in a dramatically more efficient deployment of network resources and efficient resource allocation should, overall, reduce costs. Services would now be deployed in a cloud-like fashion, making customers happy and providing service providers with new revenue streams. Secondly, my experience is that, despite the small commotion over Uber's surge pricing plans, those of us who use Uber recognize that the system has made it easier and cheaper to get a cab in some locations. According to the drivers I have spoken to, they're driving more and waiting less, so they're more productive. Sounds like a win-win to me.

Wilmes' Uber metaphor suggests we think of Uber, the company, as the service provider, and the car owner and drivers who are contracted to Uber as being the equivalent of network elements, providing transportation from location to location. We could recast the metaphor, and perhaps come to a different conclusion. The car owner and drivers are in fact the service providers, and Uber is an agency that links potential customers to service providers more efficiently. The drivers, in fact, may not own their vehicles, and for some, the optimal business model is to lease a vehicle and set up a maintenance contract with the leasing company, just like bus companies and airlines do.

Perhaps in an NFV-driven world there could be many service providers - both small and large companies - that operate geographically, similar to taxi drivers in the Uber model. The service providers lease the technology from other businesses, whose job is to invest in the infrastructure, build it and run it, selling space in the system to all-comers who can then repurpose the technology at will, according to changing end-customer demands. And where is the future equivalent of Uber in this scenario? We need to think of Uber, not so much as a service provider to end users, but as an agent - a service provider to the service providers who serve the end customers.

Since we are talking about agents, let's remember that as the Internet of Things evolves, agents will effectively be apps that serve both humans and machines. Now, there's a coincidence. What is Uber? It's actually an application that allows end users and service providers to connect. Uber, the company, makes money when people use their app, which represents an old and comfortingly familiar business model.

There is a pleasing symmetry here. Just as chunks of technology in an NFV-driven network can have transient lives in different roles, end users and their service providers will have transient relationships that will last just as long as they are needed. This uber-flexibility, not just of hardware, but of business relationships, will create a competitive market that should benefit customers greatly. On the other hand, perhaps service providers will have a tough time for a period, just as traditional taxi companies stumbled for a time, attempting to use regulation to preserve their old business models instead of embracing the new.

The fun of thinking of the future in this way is that when we try to connect the dots from the present to the future, we can easily come up with something of a tangle. In a world of NFV (and software-defined networking [SDN] too, of course) we cannot easily map the businesses and business models of today onto the possible business models of tomorrow. Whatever we dream up could be wrong. But the biggest mistake of all is to assume that things stay unchanged.

Wilmes follows up his gloomy prediction with this thought: "And the business and technical agility that they need to amortize those costs more quickly with dynamic pricing is also expensive to acquire and maintain."

Perhaps this is what underpins his gloom: keeping track of NFV is going to be difficult and expensive. I have good news for him. Billing systems that enable dynamic pricing across a web of complex business relationships are already here, and when NFV is widely deployed, those systems, including MetraNet will have the industrial power, precision and scalability to handle whatever financial transactions NFV can throw at us. None of this will be trivially easy, but NFV itself is not a trivial exercise. If it were, we would have done it years ago, just like we would've developed Uber back when we still had horse-drawn cabs - if only we'd also had giant data centers, ubiquitous mobile data connectivity, smartphones, journey planning algorithms, GPS and flexible billing and settlement.

More Stories By Esmeralda Swartz

Esmeralda Swartz is VP, Marketing Enterprise and Cloud, BUSS. She has spent 15 years as a marketing, product management, and business development technology executive bringing disruptive technologies and companies to market. Esmeralda was CMO of MetraTech, now part of Ericsson. At MetraTech, Esmeralda was responsible for go-to-market strategy and execution for enterprise and SaaS products, product management, business development and partner programs. Prior to MetraTech, Esmeralda was co-founder, Vice President of Marketing and Business Development at Lightwolf Technologies, a big data management startup. She was previously co-founder and Senior Vice President of Marketing and Business Development of Soapstone Networks, a developer of resource and service control software, now part of Extreme Networks.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by sharing information within the building and with outside city infrastructure via real time shared cloud capabilities.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.