Doug Smith, Red Hat, Inc, Gergely Csatari, Nokia There is an anecdote about a tourist lost in the middle of the countryside in Ireland, who pulls over and asks a local, "How can I get to Galway from here?" To which the local, after thinking for some time, responds, "If I was going to Galway, I wouldn't start from here at all." Cloud native application development can feel like that sometimes, especially in the telecom industry. I have an application, it's running fine on a bare metal server, and now I am expected to make it resilient, scale-out, cloud native, microservice architecture, buzzword compliant. But how do you get there from where you are? This presentation will present the hero's quest, identifying the key constraint to cloud resiliency at each stage, and identifying measures for addressing them. By showing the evolution story from the perspective of two applications, including a real telecom application, this presentation addresses the practical problems. The approach is not "rewrite your app from scratch", it is refactoring for incremental improvements. Doug and Gergely will address the automation of application deployment and configuration, separation of state from behaviour, clustering, handling storage for cloud native applications, monitoring and event management, and container orchestration, so that, at each step along the journey, you know what problem you are solving, and how to get to the next step from where you are. This presentation is in addition to a series of workshops held at the summit sponsored by the Cloud Native Computing Foundation and organized by Dave Neary, and includes a short summary of the topics presented in those workshops in addition to the perspectives on how to complete the quest to cloud native applications.

2. Crossing the River by Feeling the Stones:
From Legacy to Cloud Native Applications
Doug Smith Gergely Csatari

4. 1
2

5. 1Container packaged. Running applications and processes in software containers as an isolated unit of application deployment, and as a
mechanism to achieve high levels of resource isolation. Improves overall developer experience, fosters code and component reuse and
simplify operations for cloud native applications.
Dynamically managed. Actively scheduled and actively managed by a central orchestrating process. Radically improve machine
efficiency and resource utilization while reducing the cost associated with maintenance and operations.
2
3
Micro-services oriented. Loosely coupled with dependencies explicitly described (e.g. through service endpoints). Significantly increase
the overall agility and maintainability of applications. The foundation will shape the evolution of the technology to advance the state of the art
for application management, and to make the technology ubiquitous and easily available through reliable interfaces.

6. We held a co-located Cloud Native
Computing Foundation Day on the 13th
CNCF DAY
Cloud Native VNFs
● Automation
● Monitoring
● Componentization
● State & Storage
● CI/CD Pipelines
● Logs & Telemetry
● Fault management
● Container Orchestration

7. ●
●
●
●
●
●

8. Deployed via
bash script
Pre ‘14
Created
DockerfilesLate ‘14
Early ‘15
API broken out
from monolith,
modularized backend
data stores
Early ‘17
Created Kube
pod specs &
workflow docs
Appropriately broke
out services, used
docker-compose
Mid ‘15
‘16
Add end-to-end CI to
validate container
deployment

9. Business logic
Proprietary operating
system
Proprietary cluster
management
Proprietary hardware
Business logic
Proprietary operating
system
Virtualisation
ATCA hardware
Proprietary cluster
management
Business logic
Proprietary operating
system
Virtualisation
IT hardware
Proprietary cluster
management
VirtualisationCloud
Platform functions
Linux base image
Virtualisation
IT hardware
Container
infrastructure
Cloud
Any host Linux
Business logic
1900’s 2000’s 2010’s 2017 -

10. Homer Nokia TAS
Infrastructure independency: Applications should be able to run
on any hardware, any cloud, any container infrastructure and using any
platform services
Original deployment methodologies
were distro biased, and otherwise
brittle.
Nokia TAS is deployed into several
operators environments and should be
capable to run on any environment the
operator have.
Congruent environments: Both the development, the testing and
the production environment uses the same deliverables, only with
different configuration.
Developers require changes to
ancillary application configuration and
architecture at times, and it becomes
memorialized in the container
deployment scheme.
On the long run we would like to utilize
DevOps and this is a basic concept of it.
Easy software management: The services running in different
containers are independent so they can be upgraded independently
what makes the upgrade of a single service faster.
Homer relies on a number of ancillary
open-source applications to operate,
one can isolate upgrades across
these applications.
Software upgrade is an important aspect
of the operability. With the utilisation of
containers and independent services the
upgrade of the different components will
be more easy.
Fine grained scalability: the unit of horizontal scalability is not a
VM, but a container. This enables more fine grained and
multi-dimensional scalability.
Dynamic scaling could be a boon to
telephony operations as it could
make for easier busy-hour analysis.
The amount and profile of the load
handled by the Nokia TAS application
depends on the behaviour the single
users, therefore a fine grained and
multi-dimensional scalability increases the
hardware utilisation.

11. X

12. X ?

13. LightweightVM
Reef
Continuous integration sound
Pod spec Keys
Persistent Storage Strait
Sea Of Lowly Bash
Scripts

14. X
?

15. Blizzard of operating
system change
Horn of using open source
Network Plugin Straits
of the Kubernetes see
Scale Lagoon
Infrastructure Creek
Bild system islands of the
Containerisation channel

16. Homer Nokia TAS
Persistent storage: Without a persistent volume back-end, storage
is either ephemeral, or bound to a specific host.
Persistent storage is necessary for
data stores. Ephemeral storage
wasn’t sufficient.
Kubernetes configurations: It is cumbersome to manage the
configuration of several pods in Kubernetes, which makes the
management of large applications hard.
Homer uses config maps generally,
plans for further service discovery
integration and Helm are planned.
Nokia TAS uses Helm for this.
Networking: In telecom applications there are cases when more than
networks should be accessible from a container. At this moment
Kubernetes does not provide a native solution for this.
Network isolation and multi-homed
pods proves to be a known gap for
telephony applications by-and-large.
To have a solution which provides multiple
networks without an additional layer of
overlay. Nokia implemented its own
Kubernetes networking plugin.
Monitoring: Horizontal scaling based on custom metrics is required.
Homer is itself a monitoring
application, and Kubernetes liveness
is generally sufficient.
There is a new monitoring and scaling
architecture is under development in
Kubernetes, but it is not ready yet.
Kubernetes services: Kubernetes services are a great support for
horizontal scaling as they include load balancing also. Services are
working only with a single network interface and load balancer is
available only for https.
Future plans may involve using
Kamailio (SIP proxy) for balancing
load.
Nokia TAS is capable to operate using
only one network interface per container if
the infrastructure is not capable to handle
more. In this case services are used,

17. Homer Nokia TAS
No VIM which is capable to manage both VM-s and Docker
containers: At the moment to start a Docker container in OpenStack
a Kubernetes cluster is needed, which is not optimal from operability
point of view. Current direction of Zun is to start directly containers
using Docker API.
At the moment Nokia TAS hides the
container infrastructure into the VNF in
cloud environments.

18. 1 Go into production. This new TAS is not yet released. It is under testing in
customer labs at the moment. Obvious next step is to start using it with live traffic and
collect real production experiences..
2 More PaaS functions. More and more functions should move into the PaaS
domain and shared among the different applications running in the same location.
3 Abstraction of PaaS functions. To support different PaaS environments the
PaaS services should be abstracted from the application (eg.: use libkv instead of etcd of
Consul).

19. 1 Kubernetes Helm. Using Helm could open up options for bringing out some
capabilities of Homer (such as pluggable storage back ends) and ease customization of
deployments.
2 Service Discovery & Scaling. The current design is limited to a single Kamailio
(SIP proxy) instance where data is passed to Homer’s back-end, service discovery could
be used to have multiple scaling points where data is captured.
3 PaaS Integration. Homer has its own dashboard, but, possesses a pluggable
interfaces (e.g. for storage engines), and could be integrated with Cockpit, for example for
a front-end.

20. 1 VIM for containers. OpenRetriever works on the definition of a VIM for containers,
or a VIM for containers and VM-s. Is there a need for a common VIM for containers and
VM-s? If not is there a need to have a common networking solution between the
container and the VM VIM?
2 Container networking. Single network per container is a problem for some
telecom applications, usage of NAT is problematic for telecom applications, usage of
several overlays is problematic for some telecom applications. How about expanding
OPNFV scope to container related projects? Is there any formal list of OPNFV projects?

21. Thank you! Questions?
@dougbtv
@GergelyCsatari
@CsatariGergely