Don't take the wait-and-see approach

Let’s start at the beginning, as the saying goes; and in the case of this blog that seems to be the question of what the group I work in – ETSI MEC – does, what it produces and how it fits into the overall Edge Computing ecosystem.

Coincidentally, this is related to one of my favorite myths, which goes something like this. “There are soooo many standards, industry bodies and open source groups working on MEC. With all of these organizations competing with each other, it’s not clear which one to choose. I think we need to wait for the dust to settle before doing anything in MEC.”

Like most myths, this one has a not-so-small core of truth. It is true that there are quite a few standards, industry bodies and open source groups working on Edge Compute related topics. And, it is certainly true that this has created a certain amount of confusion in the marketplace.

What is not true, however, is that these organizations are competing with each other; by and large we do complementary work. How can that be? Let me illustrate that by paraphrasing a conversation I was actually a part of.

Speaker 1: “When it comes to MEC, I have a hard time recommending to my senior management whether we should go with ETSI, OpenStack, OpenEdge or another one of these groups.”

Speaker 2: “I am puzzled – when you speak to your senior management about transport for your web services, do you have a hard time recommending whether to go with IP, TCP or HTTP?”

The point is that the MEC ecosystem is complex and work is needed in various portions of the stack – and that is exactly what the various groups are doing. Let’s give some specific examples.

The OpenStack foundation has a SIG focused on making OpenStack work on small distributed cloud. In the lingo of our (i.e. ETSI MEC) reference architecture, they are developing a VIM which is targeted for edge computing – something which is acutely necessary. ETSI MEC, which is showing a VIM in our reference architecture, does not work on it – it’s out of scope for us.

Industry organizations, such as 5GAA, are thinking about how to build a complete system to address the needs of their specific industries and how work products of other groups help. In this context, see, for example, 5GAA’s paper on the subject. 

Last, but certainly not least, let’s consider the example of ETSI ISG MEC. Our standards are focused on APIs. To be more specific, we focus on APIs in two specific areas.

First, we focus on the management of MEC cloud infrastructure-as-a-service. Like ETSI NFV standards, these define APIs for management of virtual infrastructure in a telco environment, but at the mobile edge and for what may be third-party applications. In fact, while these APIs can be used standalone, they are built to also be integrated within ETSI NFV framework.

Second, we defined APIs which expose certain key services to edge applications. These APIs define a common, standardized MEC PaaS “core.” Application providers can therefore rely on these “core” services being available to their applications. Conversely, operators and equipment vendors have a reasonable certainty that the services they provide will be consumable by application.

I would like to conclude by returning to the last statement of the myth “…I think we need to wait for the dust to settle before doing anything in MEC.” This conclusion speaks as much to the complexity of the edge compute ecosystem (true!) as it does to the perceived competition between key standards-setting players within it (false, as I just argued).

Alas, I don’t think the complexity of the ecosystem justifies the wait-and-see approach, as it is not likely to get any simpler. Neither edge computing in general, nor MEC specifically, is a “solution” or a “system.” Rather it is an umbrella term for a set of technologies used to address a large number of different use-cases under a large number of deployment scenarios.

Moreover, the way these need to be addressed is likely to be highly dependent on the specific conditions of each telco – and thus specific to each telco. This is why I think it is unlikely that any industry organization will be able to come up with a “complete solution” – except either for a very specific use case or at a very high level. Our job is to provide components that can be used to put together highly performing and cost-efficient solutions as well as guidance on how such solutions should be approached…

....and how ETSI MEC is helping with that I leave for another posting.