Going cloud native
Address new demands with the power of scale, agility, efficiency, and automation
Communications technology is woven into the fabric of people’s lives and work all over the globe. This is creating enormous demand for connectivity based services. At the same time, customer’s expectations around speed, cost and value are putting unprecedented pressure on service providers’ businesses.
Cloud native is an approach to building and running cloud native applications that uses the advantages of cloud computing delivery. When companies build and operate applications using a cloud-native architecture, they can reduce time to market (TTM) market faster and respond sooner to customer demands.
For 5G in particular, 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.
Cloudification of telecom provider networks
Watch series of fireside chats between Nokia, Google Cloud and Vodafone experts on why and how telecom operators can cloudify their networks to improve operational efficiency and generate new business opportunities at faster speed. Hear from Dr. Lester Thomas form Vodafone, Max Kamenetsky and Ankur Jain from Google Cloud and our Jitin Bhandari as they discuss why the move to cloud native in telecoms needs to happen now.
What is cloud native?
Many people use “cloud native” as a catch-all term, but at Nokia, we define cloud native as these four aspects:
1. Small, stateless microservices architecture, running in containers, because compared to large monolithic applications, containers are faster to get deployed and upgraded. And containers use fewer cloud resources, because you deploy just what is needed, instead of the entire monolithic network function.
2. Open architecture and 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.
3. Cloud agnostic and infrastructure agnostic, so you can deploy anywhere. Because of abstraction, you eliminate the hardware dependencies.
4. 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.
Decomposed, stateless, elastic
- Loosly coupled stateless services
- Optimised inter-service communication
- Elastic, horizontal scaling
- Data is decoupled from application
- Abstracted infrastructure
- Streamed telemetry data
Containers, OpenStack, VMWare, AWS
- Secured application endpoints
- Services are accessed trough APIs
- User centric
Automation, collaboration, feedback
- Continous software development and delivery
- Automated Lifecycle Managent
- Resilient applications with rapid instantiation, recovery
What are the benefits of cloud native?
For 5G, service providers need more from the cloud. Cloud must be re-architected to cloud-native architecture so they can get breakthrough business agility in rapidly onboarding new apps and deploying and operating new services. The scale of 5G brings many more devices and a very diverse mix of services.
Legacy operations won’t be able to keep up. They need much more automation, especially for slicing. 5G also brings new performance demands, so the cloud needs to move towards the edge for the sake of low-latency, localized reliability, and traffic steering; for that, CSPs need cloud native’s efficiency.
- Higher utilization levels of assets, aggregation gains and simplified hardware inventories.
- High degree of automation and elasticity.
- Grow capacity as needed, move capacity from service to another based on demand.
- Pay as you grow.
- Automated software upgrades.
- Recover automatically from failures.
- OPEX improvements through reduced manual labor. Improved resiliency and better customer experience.
- Cloud platforms enabling new services creating new revenue streams, in a faster time to market.
Why you need to move from cloud to cloud native
Today, CSPs’ clouds are mostly private (they own it) and mostly central (in only a very few places).
The original goals for cloud were to decouple growth from cost, and rapidly deliver new services. They have done this in the 4G core, IMS/VoLTE, end-of-life replacement, and increasingly for Cloud RAN.
Clouds original goals
- Decouple growth from cost
- Rapidly deliver new services
How it's been used so far
- Core capacity for 5G EPC and IMS/VoLTE
- Legacy EoL replacement (3G, Fixed)
- Increasingly Cloud RAN
Legacy telco cloud isn't enough
- Large monolithic VNFs
- Too many manual operations
- Architecture overly complex
5G needs more than "just cloud"
- Breaktrough business agility
- Zero-touch lifecycle automation
- E2E distributed cloud
Solutions to date are far from open and vendor-neutral. The ability to monitor, optimize and modify systems are not ubiquitous. Performance has been acceptable, but nothing to write home about, and not yet proven at mass scale. Examples of truly innovative services built on telco cloud platforms are few and far between.
In addition, the initial telco cloud mostly ported big network elements into big virtualized network functions (VNF). These are too big, consume too many cloud infrastructure resources, and use legacy operations. They’re unwieldy to deploy, scale, upgrade and maintain.
Many of the legacy operations are manual. They simply aren’t fast enough to deal with the hundredfold increase in operational activities that come with cloud and 5G’s many devices, services, and slicing.
It’s complex cloud architecture to manage. After doing all that setup, actions such as integrating and upgrading simply take too much time and effort.
In addition, traditional VNF-based cloud architecture had no standard procedures to develop and benchmark VNFs, which led to a lack of architectural guidelines and no standard protocols or configuration policies for VNF across vendors. As a result, manual efforts are needed each time to configure, update and test VNFs. This is one of the roadblocks for service providers to realize the NFV implementation success.
There are additional challenges related to NVFs. Like consumption of hardware resources by VNF (to be highly available) is on the higher side, multi-tenancy is not supported, VNFs cannot be reused or shared, APIs are not provided for automating tasks like scaling, configuring, patching, and updating versions.
How to start the migration to cloud native
Implementing a cloud native architecture
Cloud-native migration is a journey, and like every journey, the most challenging part is always taking the first few steps. 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.
1. Cloud virtualization
The first step 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.
2. OpenStack cloud and cloud-native automation
The next step in the journey is the evolution towards automation and scale/elasticity (“cloudifying” the virtualized software). Cloud layer leverages 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.
3. Cloud architecture and cloud-native applications
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.
Our open cloud approach to cloud native
To turn disruption into opportunity, CSP reinvention is key.
We provide you with a cost-efficient and rapid way to run Nokia workloads regardless of where you are in your cloud journey.
This comes without lock-in on cloud platforms and with the ability to migrate workloads swiftly, across the entire cloud value chain including Software (SaaS) , Platform (PaaS) , Containers (CaaS) , Network (NaaS) and Infrastructure (IaaS) as a service.
Our complete cloud native architecture
Nokia’s solutions incorporate containers in a microservices architecture, with DevOps automation and open APIs which can be deployed according to your choice on any BareMetal, public, edge or private clouds.
Great technology is a start, but operators need more than that to deliver sustainable business value.
By balancing cutting-edge technology with our seasoned professionals' in-depth knowledge and expertise in networks and cloud-technologies, you can get it right from the start, accelerate your cloud migration and maximize your business results.
Multi-cloud and hybrid cloud environments
Nokia is actively partnering with third-party cloud vendors to help CSPs:
- Modernize network & core IT infrastructure across hybrid cloud and edge cloud environments;
- Maximize capital efficiency & simplify OPEX on network deployments through cloud native
- Unlock new, diversified cloud native revenue streams.
Cloud-native case studies, applications and examples
Our list of customers is ever-expanding. Nokia proudly celebrates that CSPs and enterprises all over the world are partnering with us to deliver the extraordinary. Examples of cloud-native applications for our customers include container-native, microservices-based applications and container-based.
Explore our related products and solutions
Learn more about cloud native
- Five essential principles to navigate disruption
- Cloud-native: The key to beating out the competition
- What is cloud native?
- Four reasons a cloud native IoT Network-as-a-Service will grow enterprise business
- How to start your cloud-native journey the right way
- A cloud-native vision for SBC
- Why telcos should move from ‘cloud’ to ‘cloud native’
- Why do you need a 5G cloud-native core?
- 5G journey with cloud-native and automation: foundation for killer apps
- Cloud-native makes good business sense
- Containers and the evolving 5G cloud-native journey
- Implementing microservices and containers in a cloud-native core
- How cloud native can help CSPs survive digital darwinism
- Starting Your Transition to Cloud Native on the Right Foot