Post-launch experiences from a locally developed internal proof of concept implementation

4/15/2015– strictly confidential, confidential, internal, public – 1

EXPERIENCES FROM AN INTERNALLY BUILT POCSEBASTIAN SCHUMANN, SLOVAK TELEKOM15. April 2015. London, UK

SCOPE

Post-launch experiences from a locally developed internal

proof of concept implementation

Service description

Used technologies and integration challenges

Lessons learned

April 2015, London, UKS. Schumann: “Post-Launch Experiences From An Internally Developed PoC”, WebRTC Global Summit 2

@s_schumann

Feedback is welcome! Get in touch during/after the event.

SLOVAK TELEKOM

Former fixed & mobile incumbent (merger in 2010), Zoznam, Posam, DIGI

Diverse service portfolio (fixed/mobile network and communications services, Internet access + content, data services, CPE, ICT services(data center + cloud), radio/TV broadcasting, call center services, …)

The major shareholder is Deutsche Telekom AG.

Successful deployments in SEE as well as in DT group:

Fixed network IMS migration finished end of 2014

Leader in IPTV, offering hybrid sat TV (s. 2009) & OTT app (s. 2012)

Extensive FTTx deployments (360k households)

First nation-wide 4G/LTE network (end of 2014 52% pop. coverage)

Only Telekom group member that rolled out WebRTC-based service company-wide and accessible for everyone


Slovak Telekom Group is the telecoms market leader in Slovakia

RECAP 2014

Many presentations about my view on operators and the WebRTC paradigm, misconceptions, reasons etc.

Experiences of Slovak Telekom in various units and theory & practice

Drive towards innovation independently of traditionalvendor’s legacy-first approach for WebRTC

Three in-house innovation designers with “a mission”

Belief in “change from within” and active learning

Own development of internal proof of concept

Many challenges and expectations

To be used by entire company


SERVICE DESCRIPTION –TELEKOM C-PEAK

In short...

... C-Peak is an innovative way to communicate with everyone in Slovak Telekom

It is a WebRTC proof of concept implementation to get in touch easily, in high quality, and uncoupled from telephony

Unique links built from E-mail address, added to every employees signature

Audio/video/messaging from personal portal, “ping” users to get in touch

No telephony break-out or other legacy elements

No passwords (token based access centered around E-mail)

No one-size-fits-all: Many features consciously omitted … for now (directory, collaboration, conferencing, PSTN)


348 reg. users (>10%)

>200 conversations in 2015 alone

TECHNOLOGY I/III –GETTING STARTED

Our “own” preconditions

Open-source software, modern stack, comprehensible, extensible – No “vendor black box”

No integration with legacy systems – we want to show the power of the web (and be independent)

First-time trial – not many internal prerequisites

Lack of modern APIs, no real integration environment

Execution environment would have needed complex approval procedure, no “typical” project


Open-source software + MEAN stack for development

Public third party services offering APIs that will not be implemented

Development on public cloud with public IP + no restrictions transition to future “staging environment”

Conclusions

TECHNOLOGY II/III –THE IMPLEMENTATION


“Typical” web developer tool- kit experience

Simple HTML + CSS and JavaScript experience enough

This “stack” was been used for implementing and demonstrating various demos

Different features

Customer tailored

Nothing that is Telco/NT specific – pure web dev

Simple “clean” design to demo early results

The usual suspects Bootstrap, JavaScript, etc.

Open-source wherever something more needed, e.g., ZeroClipboard, video.js

Front-End

Node.js + Express, MongoDB

Unirest, Nodemailer

Various libraries for direct service integration

Framework with a lot of flexibility and high level of abstraction (EasyRTC)

Firefox/Chrome abstractions, additional functions

Support beyond C-Peak to demo as much as possible

Back-End

WebRTC

TECHNOLOGY III/III –THE ENVIRONMENT


API topic often neglected due to business case discussions another good sample what it is useful for

Shift now to internal lab only, but no reason to have waited

Learn from external service provider

Development: Virtual machine before internal environment ready

IaaS preferred over PaaS so everything can run off one box

Production: Application server, TURN server, two external load balancers

Server

External: E-Mail (Amazon SES), SMS (Nexmo), Monitoring (New Relic)

Internal: E-Mail via Outlook SMTP, proprietary REST API for SMS + Monitor

HAProxy (load balancing on AS, HTTPS termination)

coturn (TURN server integrated between networks and for “classic” TURN)

Piwik (own analytics to troubleshoot and evaluate)

APIs

Software

Why this split? – Time & Processes! Getting started and demonstrate something fast was key.

LESSONS LEARNED –BUILDING IT

It is easier to use IaaS for development if not easy access to dev resources (even waiting a month is long and can be used for developing already)

Corporate networks the most challenging (media traversal, security policies)

Default browser and installation permissions need to be checked

Availability of internal APIs cannot be assumed

Involve management early for “air support”, discuss with stakeholders independently

Include both IT and NT (IT can do now what NT does, NT needs to get IT skills)

Do not get irritated by legacy thinkers or doubters


Trial and error seems to do well in the beginning. Try to get something out there!(and afterwards think how to do it next time with bigger investments)

LESSONS LEARNED –RUNNING IT

Not everyone will be using it or finds it useful, but it is right what some people needed

Generally positive feedback about active involvement in innovation rather than “time jealousy”

Shape acceptance for “unusual activities”

The initial aim of specializing tool and omitting features not fully appreciated by users change of own attitude

Communication services is a sensitive area (especially if the new stuff works really well) acknowledge it, but esp. with WebRTC there is space for both evolution and innovation

Don’t fight alternatives (e.g. Lync) – explain why there’s place for both and highlight benefits


OUTLOOK –WHAT IS NEXT?

Addition of requested features

UI improvements + manuals

Business products for various levels

Get “full clearance” how to handle WebRTC projects – both big and small – in the future for larger projects

Think about “architectural” approach for future projects

Build it?

Buy it?

Rent it?

Balance between “boring unavoidables” and innovation


SUMMARY

We learned a lot and are first in our group offering a cross-network WebRTC communications service

Accessible to >3000 employees, open to connect with anyone from anywhere

No vendor involvement or dependency

Thinking and doing things differently worked

Try to study it and repeat!

Elaborate contrasts and what they mean (NFV vs. virtualization, VoLTE vs. WebRTC communications, etc.)

Building instead of talking works now, especially for the “renegades”

People will be stunned to perceive it themselves if they all of a sudden know the people that built it

Prototyping means learning

We have developed various prototypes and every single challenge was also a lesson learned (some shared today)


Stop political games! Use NT and IT resources efficiently! Find the right peers!

THANK YOU.Sebastian Schumann

Application & Platform Innovation | Slovak Telekom, a.s.

[email protected]

@s_schumann

+421 903 419 345

… or simply click https://c-peak.telekom.sk/u/[email protected]

Post-launch experiences from a locally developed internal proof of concept implementation

Technology

Transcript of Post-launch experiences from a locally developed internal proof of concept implementation