1.5　到底誰需要標準

在這里，有必要撇開主題討論一下標準化的作用。如果你是一個“電信人”，你的反應可能是：“為什么？我們當然需要標準！”然而，如果你是一個“云人”，你的反應可能是：“為什么？到目前為止，我還沒有必要為標準操心。”因此，當談到MEC時，我們再一次對一個可能至關重要的話題持有不同的觀點，這就是為什么我們需要偏離主題。

為了理解造成這種差異的根本原因，我們需要再次考慮傳統的“IT”和“Web”應用程序是如何開發的。開發團隊做出了許多關鍵決策：架構方法（例如微服務）、開發和運營理念（例如DevOps）、計算平臺（如果你計劃虛擬化，很可能是x86）等，其中包括云提供商/堆棧。一些常見的選擇可能是AWS、Azure、Kubernetes、Mesophere、OpenStack等[1]，其中每一個都有自己的管理服務的方法，也就是說，有自己的API。配置、管理以及保證腳本和服務必須使用這些API。然而，這并不是問題。畢竟，開發團隊只會選擇一個，也許兩個。團隊很有可能已經熟悉了環境，但是即使是全新的環境，經過一段時間的學習之后，你也可以開始正常工作了。此外，如果你使用一個被廣泛應用的平臺，那么無論是在開源領域還是在商業軟件領域，都有很多好的工具可以提供幫助。

讓我們把這個經驗轉化到MEC，記住MEC是關于CSP提供商的邊緣云，也就是說，CSP變成了云提供商。為了簡單起見，我們把注意力集中在美國。在撰寫本書時，美國有四大移動運營商：Verizon、AT&T、Sprint和T-Mobile。也有幾個主要的獨立寬帶/有線電視提供商：Comcast、Spectrum、Time Warner和CenturyLink。有了MEC，它們中的每一個都將成為邊緣云提供商，這似乎與前面列出的AWS、Azure、Kubernetes、OpenStack等生態系統類似，但除了一個關鍵點，那就是：你不能只選擇一個或兩個。作為應用程序開發者，你必須能夠處理以上所有這些。

考慮一下你的用戶，原因就顯而易見了：他們必須能夠訪問你的云實例。然而，盡管你期望大多數用戶大部分時間都能夠訪問AWS，并且能夠一直訪問運行OpenStack的私有云，但是期望運營商1（Op1）的用戶能夠訪問運營商2（Op2）的邊緣云是不合理的。即使能夠訪問，Op2的邊緣云也不是Op1用戶的邊緣云。為了達到這個目的，他們的通信必須“離開”Op1的網絡，穿過互聯網，然后進入Op2的云。這樣任何邊緣優勢（鄰近性、低延遲、最小化網絡帶寬等）都將丟失——事實上，Op1用戶最好網外訪問公共云托管的實例。我們在圖1.4中對此進行了說明。

圖1.4　到公共云和另一個運營商邊緣云路徑的說明

這就要求應用程序開發者能夠與任何地理位置上的大多數CSP一起工作，而應用程序需要能夠出現在這些地理位置的邊緣。然而，對于大多數應用程序開發者來說，這樣的擴展根本不可行，而且即使在可行的地方，所涉及的經濟投入也是難以想象的。這是一個我們將在本書中多次提到的問題，因此給它一個簡短的名稱是很有用的，我們稱之為應用程序開發者的擴展性問題（Application Developers' Scaling Problem，ADSP）。ADSP有許多方面需要注意——如何建立適當的業務關系、指定在何處部署應用程序、如何管理應用程序實例等。這里尤其關注的是技術問題——應用程序開發者如何編寫一次軟件，并確保它能在每個邊緣云上正常工作。

幸運的是，這個問題只是通信行業中一個眾所周知的問題的一個特例，即多設備供應商的互操作性問題。例如：想想不同制造商生產的各種類型的Wi-Fi設備，它們以不同的形狀和尺寸與Wi-Fi接入點配合使用，而這些Wi-Fi接入點設備同樣也是由不同制造商制造的，形狀和尺寸也完全不同（從家用Wi-Fi路由器到企業WLAN，再到打印機中越來越多的軟AP等）。而標準則是通信行業用來解決這一問題的手段。當成功時（如許多技術一樣，許多標準都不成功），標準可以促進新生態系統的巨大增長，推動全新的應用程序和業務。我們見證了IEEE 802.11標準的成功，該標準是Wi-Fi的基礎。還有3GPP標準集，它是GSM時代以來全球移動通信產業的基礎。

因此，解決ADSP的技術問題需要一個標準，更準確地說，是應用程序和MEC云之間的標準化接口。正如我們將在ETSI的MEC中進一步看到的那樣，標準就定義了這樣一個接口。此外，ADSP并不是MEC中涉及多設備供應商互操作性的唯一方面，我們將在后面的一些章節中看到。

[1]我們將VM（虛擬機）和基于容器的環境混合在一起是有意為之的——對于本次討論而言，這并不重要。