Amdocs team talks about challenges their telecom clients went through on the way to becoming more software-defined.

1. Lessons learned from global telecom operators’ cloud
journeys
Zeev Likwornik
Head of Amdocs Cloud Center of Excellence
Amdocs Technology & New Offerings
Cloud@Amdocs.com
OpenStack Day Israel 2017

2. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs2
Information 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)

3. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs3
CSPs are moving to Cloud mainly to increase agility
3
Business agility driving innovation
Enable continuous cost
efficiencies try and err
INNOVATION
Fail fast
Speed new updates, upgrades, products and
services to market through faster code-to-
production cycles and seamless continuous
releases
AGILITY
Faster Time to Market/TTR

4. 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

5. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs5
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
Operational
Enablers
Technology
Enablers

6. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs6
Source: Matt Beal – Director, Innovation & Architecture May 2017
Light Reading Live Event
Vodafone’s phased approach to Cloud

7. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs7
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
EMEA&CALAAPAC
Physical Virtualized Public CloudPrivate Cloud
10% 25% 25% 10% 10%
On-Premise 60% Off-Premise 40%
Hybrid Cloud
NAM
5% 25% 30%
Physical Virtualized Private Cloud Public Cloud
On-Premise 60% Off-Premise
Hybrid Cloud
20%
20%
SaaS
20%
SaaS
10%
SaaSPrivate Cloud
40%
Off-Premise 30%
10%

8. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs8
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

9. OpenStack and containers
in the telco domain
Real world challenges for ISVs
Tal Barenboim
Technology Evangelist
June 2017

10. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs10
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-premise
internal cloud
Amdocs software must adhere to the Telco’s own
internal cloud and policies

11. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs11
OpenStack is KVM…
CSPs use multiple OpenStack distributions
Multiple CSPs use multiple KVM releases from different
Linux 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

12. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs12
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
RHEL
Supported!
Hardware
Ubuntu KVM
My App VM
RHEL
Not supported!

13. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs13
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 requirements
and expectations with the customer

14. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs14
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, breaking
the 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

15. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs15
Containers portability: Or lack of…
RHEL 7 Base Image
Containerized App
Container
RHEL 7 HOST OS (kernel)
Docker Engine
RHEL 7 Base Image
Container
Ubuntu Linux HOST OS (kernel)
Docker Engine
Supported!
Base Image
and 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

16. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs16
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?

17. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs17
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 requirements
and expectations with the customer

18. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs18
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.

19. Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs19 Information Security Level 2 – Sensitive
© 2017 – Proprietary & Confidential Information of Amdocs19
Questions?
cloud@amdocs.com

20. Thank you
Cloud@amdocs.com