Smarting the Dumb Pipes

les seaux
stupide Oh, sorry, I work for a
french company now.
We are required to
prepare our
presentations in english
poignées de porte de réseau and french...it’s kind of a
new experience for me -

pour une dactylo sueur like being in Canada!

Wednesday, May 26, 2010

smarting the
dumb pipes
network services
for developers This is the story of how
we’re applying the
lessons of an open
ecosystem to a closed
one.


main() {
main() { for(;;) {
puts “hello, world!”; puts “hello, world!”;
} }
}

#include <stdio.h> #include <stdio.h>

main() { main() {
for(;;) { for(;;) {
printf ("hello, world!n"); printf ("hello, world!n");
printf ("I like you.n"); }
} }
} I worked at SourceForge
for all of the last decade,
where my job was to make
sure people could share
technology and make it
better. Now I work in
telecommunications.


I’ve gone from working in
the most open ecosystem
in the world to one of the
most tightly controlled.


the network

You may wonder what
we’re doing here.

We haven’t exactly done
a good job so far of
“working” with modern
developers.


This is Alcatel-Lucent’s
US headquarters. Raise
your hand if you know
what we do.

Nobody? Really? Oh,
well let me tell you.


Central Serving Regional
Offices Office Transport
VoIP Soft Phone 7342 ONT

Indoor
DH Residential Up to 64 1692
CP Gateway MSE
GPON Splitters
DHCP ONTs per
PON Line GX 550
Ethernet, HomePNA Multiservices
or MoCA GPON Metropolis® DMXtend Switch
IPTV Access Multiplexer
Set Top Box 7342 ONT 7342 OLT
POTS Distribution
Analog Phone Cabinet
1692
Sealed Expansion MSE Active 1696
Module 1692 WDM MS
OPS
Active
Access Point DWDM
IP Services Router 1692
OPS
Access Point
IP Services Router 7330 This is what we do. We sell
FTTN GR303 things that let companies
Access Point MDU TR008 build and run the net works
IP Services Router Remote Expansion V5.2
Module Gateway you use every day.
TDM Switch

This graph is an example our
marketing standards team
Metropolis® DMXpress Metropolis® uses to teach us how to make
Access Multiplexer DMXtend
Access Multiplexer neat and legible graphs.
Everything we do is complex.


And it has to be complex,
because one day it’s going
to be bolted into
somebody’s rack...


...or buried underground...


...or left at the bottom of
the sea.


Most developers (and
users) see the net work
as something they put
packets into and receive
packets from.

unspeakably
huge,
complex,
mysterious, packets

stuffy
network packets
thing that
nobody
understands


That’s where the phrase
comes from. Developers
just want the net work
to do one thing: be a
reliable pipe to put data
through.

the “dumb pipe”


And why not? We all expect
things in our everyday life to
behave as if they’re simple
when they’re anything but.

When I’m at home and I
want to discard a liquid of
some sort, I pour it in the
drain.


When I want water, I get it from
the faucet.

I don’t know where my waste
water goes or where my fresh
water comes from, I just trust
that it will work. The pipes in
my house are truly “dumb” to me.
Or, maybe, I’m dumb to them.


This makes the net works feel kind
of bad because, well, nobody likes to
be taken for granted.

What? You don’t feel sorry for
them? Let’s all say “
awwww”.

To be fair, the net works have been
taking us for granted a little bit too.

There’s another, better, reason why
this is a problem.


The bigger problem is that the situation is
financially untenable.

Pricing the net work as a cheap
commodity hasn’t been working very
well.

Services have driven way more demand
than anybody expected, or have designed
the current business model around.

Something new has to be done, or we may
see drastic changes to the net as we know
it: the end of flat-rate ser vice or more and
more dropped calls).

revenue per user network demand industry awesomeness

(disclaimer: this data is complete bs, i made it up to illustrate the point)


user context
preferences, contacts, device, location

content
storage, distribution, transcoding

communications The net works have the
potential to be more
than just a commodity,
though - they can offer

call control, messaging
a lot of capabilities that
developers can’t get
anywhere else.

accounting
payments, authentication, history


Raise your hand if you’ve
had a good experience

...?
partnering with a
carrier and developing
against these ser vices.

Nobody? Really? Wow!


Indoor
DH Residential 1692
CP Gateway Up to 64
GPON Splitters MSE
DHCP ONTs per
PON Line GX 550
POTS Distribution
1692
Module 1692 WDM MS
OPS
Active
Access Point DWDM
OPS
Access Point
FTTN GR303
Access Point MDU TR008
Module Gateway TDM Switch

Metropolis® DMXpress Metropolis®
Access Multiplexer


Here’s what’s happened instead:
people have found a way around.

Developers figured out how to do a
lot of this stuff, while only relying
on the net work to send and
receive packets.

This has generally been very
successful, but I think that the
net work can play a much larger
part than that.


In order for a developer to
access these capabilities
without needing a
partnership with a carrier
and a full understanding of

st
net work internals, they
need to be exposed using

re
web services.

network enablers

esperanto
ims

sandwich
parlay


Indoor
DH Residential Up to 64 1692
CP Gateway MSE
GPON Splitters
DHCP ONTs per
PON Line GX 550
POTS Distribution
1692
Module 1692 WDM MS
OPS
Active
Access Point DWDM
OPS
Access Point
FTTN GR303
Access Point MDU TR008
Module Gateway TDM Switch

Metropolis® DMXpress Metropolis®
Access Multiplexer


A large benefit of exposing
these capabilities through
web services is that they
aren’t just available to the
cable router, set-top box, or
mobile device that connects
you to the net work...they’re
available to applications
that run anywhere.


The problem with net work

... ?
providers opening up APIs to
developers is that there are
so many of them. Over 700.

Partnering with a single
carrier is hard, who wants
to partner with 700?

enablers

network provider 3
provider 2
provider


What the industry needs is a
centralized place for developers
to code against that knows
which net work to pass the
request along to.

We’re in a good position to do this
because we’re close to the
net works without actually
being one of them.

unified network API

enablers enablers enablers

provider 1 provider 2 provider 3


But wait - we were
talking about money.
How does any of this fix
the carrier business
model?


Some net works charge
developers per-call for
access to their services,
costing as much as five
cents/call for the most
expensive ones.

location: $0.045/call

sms: $0.035/call


sms 300,000/day

advertising 500,000/day
(eCPM of $2)
Let’s say, for example,
you built an application
using SMS and
advertising, and you
were able to get enough
users to send 300k SMSs
every day and show
500k ad impressions.


sms + advertising

revenue: $1,000/day
sms cost: ($10,500)/day

net: ($9,500)/day
By paying for SMS
messages on a per-call
basis, you could possibly
lose a substantial
amount of money...and,
worse, it doesn’t scale.


API pricing models that
charge up-front fees for
developers can make it
really hard to get your
business off the ground.


This may be a bit of a departure,
but I will come back around: Some
things go really well together, like
chocolate and peanut butter,
strawberries and cream,
mayonnaise and french fries,
cocaine and baking soda. +
I think the same thing holds true
for net work capabilities and
other technology.

+
+

sms + advertising

location + billing


Instead of charging per call,
developers can use bundled APIs to
share their revenues with API and
net work providers.

If these providers give you something
of value, and you’re successful enough
to make money, they get paid.
$700
That’s what we’re working on.

$125

developer
ad provider
$75
sms provider
network provider
$70
overhead
$30


sms + advertising

revenue: $1,000/day
to providers: ($300)/day

net: $700/day
Using a bundled API, our
example app begins to
generate revenue.


This is hard. Really hard.

Not only do we need to prove
that the business model
works, but we need to build
the APIs and convince the
carriers to turn them on.

This might take a while, even
though we’re being super
aggressive.


If you have an API that
you think might pair up
with a capability from
the net work to make
something interesting,
email this guy. He’s
sitting right over there.

redg wants
your api
really bad

redg.snodgrass@alcatel-lucent.com
415-254-7921

We have APIs in our lab
that you can play around
with. Although only one
carrier is on-board now,
we’re in talks with lots
of carriers to expand the
program.

http://openapiservice.com


What net work API
would you use in your app
if we were to launch it
tomorrow?

What capabilities have
we not thought of?

what APIs
should the
network
expose?

ross.turk@alcatel-lucent.com
310-498-0797

Smarting the Dumb Pipes

Recomendados

Recomendados

Más contenido relacionado

Similar a Smarting the Dumb Pipes

Similar a Smarting the Dumb Pipes (20)

Último

Último (20)

Smarting the Dumb Pipes