Every business – no matter how large or small– has a certain set of goals it hopes to achieve in its journey to cloud.
In my previous blog, I discussed the benefits of a CNF (Cloud Network Function) over VNF (Virtual Network Functions), and how unlocking the full potential of the cloud can only be done with cloud-native architecture.  

Telco cloud, which we define as deployment of virtualized and programmable telecoms infrastructure (NFV, SDN, AI, automation, distributed computing, and more) is starting to be adopted by telecoms operators across the world, primarily driven by the move to virtualize mobile core networks in response to data traffic growth, and in preparation for roll-out of 5G networks.

For 5G, service providers need more from cloud. Cloud must be re-architected to cloud-native so that they can get breakthrough business agility in rapidly onboarding new apps and deploying & operating new services. for that CSP need cloud-native’s efficiency.

Lots of people simply say cloud-native. Let’s get specific. At Nokia, we define cloud-native as these four aspects:

• Small, stateless microservices, running in containers, because compared to large things, small things are faster to get deployed and upgraded. And small things use fewer cloud resources, because you deploy just what is needed, instead of the entire network function.
• DevOps for automation and fast TTM. And when you deploy an upgrade, use canary deployment to test it with a smaller group, then extend it out to everyone.
• Open architecture & APIs so you can continually onboard innovation. For example, 5G’s core uses a service based architecture, with well-defined APIs for network functions to offer services or call on each other. This, along with the cloud-native service mesh, enables rapid manipulation of your 5G core, whether for integrating new network functions, or rapidly scaling & deploying per-enterprise slices.
• Cloud agnostic, so you can deploy anywhere. Because of abstraction, you eliminate the hardware dependencies.

I believe that cloud-native migration is a journey, and like every journey, the most challenging part is always taking the first few steps.

Now, let’s dive into how to get there.

“So be sure when you step, Step with care and great tact. And remember that life's A Great Balancing Act. And will you succeed? Yes! You will, indeed! (98 and ¾ percent guaranteed)” Dr. Seuss, Oh, The Places You'll Go!

The evolution toward cloud-native

In the past each network element was tied to specific hardware and the products were dependent on the hardware. For example, CSPs had (have) thousands of different hardware components (SKUs, stock keeping units) in their inventories, and complex per application management. While some vendors had internal hardware consolidation, basically every vendor had multiple, different and totally incompatible hardware platforms.

The steppingstone towards ‘cloudification’ is virtualization.

Virtualization enables hardware consolidation by making it possible to run applications on generic hardware (and to run old single-threaded applications in a more efficient way). This was the first step towards cloudification but was not yet true cloudification. The VNFs are still siloed, effectively rendering the benefits of cloud less relevant, as there is no pooling of hardware resources across the different applications. Many CSPs are still at this stage of the journey.

The next step in the journey is the evolution towards automation and scale/elasticity (“cloudifying” the virtualized software). Cloud layer leveraged OpenStack technology, making it possible to automate deployment of applications into the data centers running generic hardware, and (depending on application capabilities) elasticity may be supported e.g. through VNF managers. Unlike virtualization, there is automation in place, and it is possible to run many different applications with the same tools. While able to run the applications in the cloud infrastructures, the applications may still have certain requirements to underlying cloud stacks and/or to the hardware layer.

The final step (or destination) is to evolve application architecture towards cloud-native applications. This includes de-composing the network functions into microservices and makes it possible to run the applications as “infrastructure independent” - for example directly on hardware, or on virtual machines, or in containers. It also enables for example VNFC (Virtualized Network Function Components) approach for sharing/re-using multi-vendor components across multiple applications (such as session database or load balancing entity). In addition to infrastructure independence, a key quality is programmability, i.e. providing well documented APIs both inside and outside of the applications. This is important to enable DevOps principles also in the telco cloud.

Nokia recognizes that not only are our customers at different phases on this journey, but they also face an inherent challenge as pockets of their own network may be in different phases of this journey. They seek a cohesive solution, which embraces all these steps.

Open is the new cloud model

The Nokia cloud portfolio takes account of the way that cloud technology is evolving and had its first commercial cloudified products in 2015 (Cloud Application Manager providing lifecycle management and elasticity) and even the first commercial cloud-native VNFs came from Nokia in 2017.
The way in which applications, networks and services will be built in the future is changing rapidly. The new era of the cloud is built on openness in which we work with third parties yet take full responsibility for the end-to-end solutions we deliver. Collaboration is the most effective way to accelerate innovation. Trying to lock customers into vertically integrated solutions is not the way forward, but rather integrating them into products and customizing them for CSPs. Open source is one important part of the openness, but there’s more to it. Standardization remains important for our industry as means to secure interoperability between different functions and implementations (i.e. a key enabler for multi-vendor environments).
 
In addition to open source software there is also open hardware and reference architectures that are becoming important. A key example from those is Facebook’s initiated Open Compute Project (OCP) from which Nokia is leveraging open hardware specifications and driving efficiency, operability and scale in data centers and telecom and enterprise business verticals. In return, Nokia also contributes to OCP designs with telecom features and solutions designed to meet requirements related, for example, to high availability.

For more information on Nokia cloud native technology check out our website.