lessons learned from global telecom operators' cloud journeys - zeev likwornik, tal barenboim -...

Lessons learned from global telecom operators’ cloud journeys

Zeev Likwornik

Head of Amdocs Cloud Center of Excellence

Amdocs Technology & New Offerings

[email protected]

OpenStack Day Israel 2017

Information Security Level 2 – Sensitive

© 2017 – Proprietary & Confidential Information of Amdocs2Information Security Level 2 – Sensitive

© 2017 – Proprietary & Confidential Information of Amdocs2

Key Cloud

challenges for telcos

Organization

Selecting the right stack

Complexity of ecosystemRoadmap

Re-architect applications to cloudApplications

Skills Scarcity

Organizational changes

Operability

Managing hybrid environments

(private/public/hybrid)

Bi-modal operations (legacy and

new applications)



CSPs are moving to Cloud mainly to increase agility

3

Business agility driving innovation

Enable continuous cost

efficiencies try and err

INNOVATIONFail fast

Speed new updates, upgrades, products and

services to market through faster code-to-

production cycles and seamless continuous

releases

AGILITYFaster Time to Market/TTR

Information Security Level 2 – Sensitive© 2017 – Proprietary & Confidential Information of Amdocs4

CSP’s Cloud agility is driven mainly by DevOps

Top Challenges to DevOps adoption


Telecom operators cloud maturity model

Bare metal1Infrastructure

Virtual machines2

Hybrid cloud4

Multi cloud5

Private & Public Clouds3

Applications Physical1

Virtualized2

Cloud-enabled3

Cloud native4

Cloud next gen

5

1

2

3

4

5

Agile & automation

Siloed teams

Continuous integration

Continuous delivery / DevOps

NoOps

People & Processes

Value gained

OperationalEnablers

TechnologyEnablers


Source: Matt Beal – Director, Innovation & Architecture May 2017Light Reading Live Event

Vodafone’s phased approach to Cloud



By 2020, the majority of CSPs’ workloads will be on cloud

Cloud adoption by telcos is well underway

Physical Virtualized Public Cloud

10% 20% 10%On-Premise 70%

Hybrid Cloud

EM

EA

& C

AL

AA

PA

C

Physical Virtualized Public CloudPrivate Cloud

10% 25% 25% 10% 10%On-Premise 60% Off-Premise 40%

Hybrid Cloud

NA

M

5% 25% 30%

Physical Virtualized Private Cloud Public Cloud

On-Premise 60% Off-PremiseHybrid Cloud

20%

20%

SaaS

20%

SaaS

10%

SaaSPrivate Cloud

40%Off-Premise 30%

10%


Cloud Center of Excellence

Vendors Trusted design customers

Jointly plan roadmap, timelines and needed investment

Significantly minimize risks and reduce costs associated with embracing new and emerging cloud technologies

Influence leading vendors and market roadmaps

Offer comprehensive, certified solutions to our customers

Selected examples:

Define cloud strategy & roadmap Support customersGrow knowledge in the organization

OpenStack and containers in the telco domain

Real world challenges for ISVs

Tal Barenboim

Technology Evangelist

June 2017


Quick refresh

Amdocs sells BSS/OSS/Network mission-critical software for Telcos/CSPs

SLA and support is critical for our customers

Telcos build their own internal private clouds

Amdocs software is a GUEST in a Telco on-premiseinternal cloud

Amdocs software must adhere to the Telco’s own internal cloud and policies


OpenStack is KVM…

CSPs use multiple OpenStack distributions

Multiple CSPs use multiple KVM releases from differentLinux vendors

Your app is running in as Guest VM in KVM

KVM from Linux distro vendor A is not the same KVM from Linux distro Vendor B (kernel)

Guest OS (VM) support under multiple versions of KVM is MAJOR PROBLEM


KVM support – unsustainable model in production

Linux vendors REALLY supports only their KVM implementation

A Linux Guest VM from vendor A running on KVM from Linux Distribution of vendor B is not really supported

Linux Vendors do not certify each other KVM – Linux Distro Vendor Lock

SLA provided by Linux Vendors are unsustainable for production use

Hardware

RHEL’s KVM

My App VM

RHELSupported!

Hardware

Ubuntu KVM

My App VM

RHELNot supported!


OpenStack Networking: Not that simple

CSPs have their own networking requirements and policies around OpenStack

OVS (Open vSwitch) may not be used by some CSPs at all!

You tested on OVS, but the customer does not use OVS – your app may be impacted

Your app depends on specific networking capabilities and performance baselines, not possible with OVS. Yet the customer is not moving from OVS.

Align your networking requirementsand expectations with the customer


Containers: Oh the hype….

Containerization is built-in capability of the Linux kernel (cgroups, lxc, namespaces,etc)

Hence containers are Linux (capability)

Containers promise portability - they potentially can run on any Linux where there is a compatible container engine (docker,rkt)

However, some Linux vendors embrace the “Containers are Linux” stance, but only THEIR Linux, breakingthe entire portability of containers

Distributing containerized software for an ISV is a serious challenge

Networking containers may not be as straightforward as you might think


Containers portability: Or lack of…

RHEL 7 Base Image

Containerized App

Co

ntain

er

RHEL 7 HOST OS (kernel)

Docker Engine

RHEL 7 Base Image

Co

ntain

er

Ubuntu Linux HOST OS (kernel)

Docker Engine

Supported!Base Imageand Host OS match!

Not Supported!

Containerized App

Red Hat Linux VM or Physical Host Ubuntu Linux VM or Physical Host

Base image user space libraries are compiled with each vendor’s specific Linux Kernel release, and key libraries such as glibc.Linux Distribution vendors support only their user space libraries run on THEIR Linux HOST OS kernel. NO SLA guaranteed otherwise


Distributing containerized software: Hold on!

Containers is packaged software. It’s a packaging format.

We package the base image, our 3rd parties dependencies + our app

Distributing our software in this way is way cool, yet highly problematic:

Are you using commercial software in your container? - you need OEM/Embedded licensing agreement to distribute your software in a container.

Does your app depends on 3rd party GPL libraries and components? – distributing your software which linked to GPL libraries and packaging those GPL libraries with your software has significant LEGAL impact on your software code

Using Oracle JDK/JRE for your containerized app ? That’s commercial software!

Are you building your own containers or using ready made containers from docker hub and other registries? Think security!

Security updates to the base image mandate you will rebuild your containers and re-provision it. Does your software support this?


Container’s networking: endless options

Containers ecosystem support pluggable SDN fabrics for container to container networking

Commercial container management platforms (CMP/CaaS) may already have built in SDN fabrics that may not meet your networking requirements at the capability and performance levels

When not using CMP/CaaS - You are required to pick the SDN fabric for your containers – which one to use?

The SDN fabric you picked and tested in-house – may not be the one the customer is using. This can seriously impact your app.

Some SDN fabrics for containers do not support Jumbo Frames, IP Multicast, and some have serious impact on your host CPU/MEM resources

Align your networking requirementsand expectations with the customer


Summary

Linux, OpenStack distributions and containers are a business!

OpenStack and Linux distribution vendors protect their business, prohibiting supportable interoperability, yet focus on vendor locking the customer though the support channel

Testing and certifying your app on multiple KVM and Linux distros releases is required

Your virtualized app running in KVM, networking behavior and performance depends on whatever virtual switch the customer is using, not what you tested in-house.

Containers are cool, yet the hype is so big as Linux vendors lock you to their distribution if you require support. No true portability possible.

Containers are a packaging format. Pay attention to what you package and the legal aspects.

Containers can be a security and IT nightmare to maintain, if there is no one that maintains this inside your company.

Containers SDN networking differ in capability and performance. Choose wisely. Test and align with your customer.

Information Security Level 2 – Sensitive© 2017 – Proprietary & Confidential Information of Amdocs19 Information Security Level 2 – Sensitive© 2017 – Proprietary & Confidential Information of Amdocs19

Questions?

[email protected]

Thank you

[email protected]