Open Stack

On 08/24/2016 04:26 AM, Peter Willis wrote:
> Colleagues,
>
> I'd like to confirm that scalability and multi-site operations are key
> to BT's NFV use cases e.g. vCPE, vCDN, vEPC, vIMS, MEC, IoT, where we
> will have compute highly distributed around the network (from thousands
> to millions of sites). BT would therefore support a Massively
> Distributed WG and/or work on scalability and multi-site operations in
> the Architecture WG.

Love all the TLAs.

I've asked this before to numerous Telco product managers and engineers, 
but I've yet to get a solid answer from any of them, so I'll repeat the 
question here...

How is vCPE a *cloud* use case?

 From what I understand, the v[E]CPE use case is essentially that Telcos 
want to have the set-top boxen/routers that are running cable television 
apps (i.e. AT&T U-verse or Verizon FiOS-like things for US-based 
customers) and home networking systems (broadband connectivity to a 
local central office or point of presence, etc) be able run on virtual 
machines to make deployment and management of new applications easier. 
Since all those home routers and set-top boxen are essentially just 
Linux boxes, the infrastructure seems to be there to make this a 
cost-savings reality for Telcos. [1]

The problem is that that isn't remotely a cloud use case. Or at least, 
it doesn't describe what I think of as cloud.

Cloud to me means:

* Lots of hardware consolidated in datacenters for efficiency and 
security/management
* Software-as-a-Service interface, meaning the service is driven by 
users/tenants (i.e. no IT helpdesk to call to provision something) and 
provided over the Internet to a dumb device or browser
* (HTTP) API-driven access to launch compute, storage and network 
resources from large pools of those resources

Furthermore, applications written for the cloud (i.e. cloud-native apps) 
are built from the ground up to assume and tolerate failure, to be as 
close to shared-nothing as possible, to not need to be aware of where 
they are running or what particular server they are running on and to 
rely on well-defined APIs between (micro-)services.

v[E]CPE describes a purpose-built Telco application that doesn't meet 
any of the above definitions of what "cloud" is all about.

vCPE also doesn't look like a cloud-native application either: A single 
customer's vCPE software application is not capable of running on more 
than one machine at a time (since obviously it's running on the 
customer's set-top box or router).

Look, I'm all about designing Nova and other cloud services to function 
well in distributed environments where multiple datacenters are running 
a single OpenStack deployment spread over many regions.

But v[E]CPE just isn't cloud to me. And trying to morph Nova or other 
OpenStack services that were designed to run as services in a datacenter 
just isn't something I feel the OpenStack community needs to be focusing 
on. Run Nova (or Kubernetes, or Mesos, or any other cloud management 
platform) in the datacenter. Run a custom software application on the 
set-top boxes that can communicate with datacenter cloud services. Let's 
please not commandeer one of them to fit a model it was never built for.

My two cents,
-jay

[1] I say cost-savings because instead of shipping the customer a new 
piece of hardware when they purchase a new service (or sending a 
lineman), instead the telco now simply sends a command to the customer's 
router or set-top box to launch a VM that provides that service. One 
could say that the Telcos could just as easily ship a monolithic 
software application that would run on the set-top box and allow 
features to be toggled on and off, and I'm pretty sure many telco 
software applications are already like this, but deploying and managing 
monolithic applications is more complicated and expensive than shipping 
a VM image that contains a custom-built service that the customer can 
use at will.

p.s. I also don't think it's a good idea to run nova-compute on a fitbit 
watch.