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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
