Cloud native is a ‘must-do’ for telcos
"Cloud native" is a hot topic, but what does it really mean? And why do folks like Marcus Brunner, Swisscom’s Head of Standardization, Open Source and Ecosystem Development, believe it’s a “must-do” for CSPs?
Dawn Bushaus09 Jan 2020
Cloud native is a ‘must-do’ for telcos
Visit any telecom news site today and I guarantee you’ll see the words “cloud native” in a headline. But what does it really mean? And why do folks like Marcus Brunner, Swisscom’s Head of Standardization, Open Source and Ecosystem Development, believe cloud native is a “must-do” for communications service providers (CSPs)?
In telecom, the term “cloud native” is used most often to describe network functions that have been developed from the outset as software to run on servers hosted in a cloud environment. This could be a public cloud environment like Amazon Web Services, Google Cloud or Microsoft Azure; a private cloud environment; or a hybrid cloud environment, which is a mix of public and private.
Companies like Cisco make a clear distinction between cloud-native network functions (CNFs) and their predecessors, virtual network functions (VNFs). “Virtualization and VNFs helped us in getting started in moving toward cloud-native applications,” the company states, adding that the problem with VNFs is that upgrades are slow and scaling difficult because the applications are typically ported into cloud environments using a “lift-and-shift” approach. Cloud-native applications address these limitations using a microservices architecture that supports dynamic elasticity and scalability.
“For me, it’s very clearly a must-do,” Swisscom’s Brunner told Telecom TV in an interview filmed at The Great Telco Debate in December when he was asked whether embracing cloud-native technology is essential or merely desirable (you can watch the full interview below).
Brunner’s comments were in reference to network functions, but there are many other elements of a CSP’s environment that can be cloud native, such as network management and back-office operational and business support applications. And to muddy the waters even more, cloud native is sometimes used (wrongly) to describe the type of cloud environment or platform (that is, public, private or hybrid).
Our latest report Public cloud: An essential but not singular solution for CSPs, written by TM Forum Senior Analyst Tim McElligott, does an excellent job of sorting through the terminology – and the hype – and explains how operators can begin adopting cloud native technology and taking advantage of public cloud options.
Importantly, the research shows that CSPs have a long way to go in embracing cloud in any form but that doing so is, as Brunner concludes, necessary to remain competitive.
In telecom, the term “cloud native” is used most often to describe network functions that have been developed from the outset as software to run on servers hosted in a cloud environment. This could be a public cloud environment like Amazon Web Services, Google Cloud or Microsoft Azure; a private cloud environment; or a hybrid cloud environment, which is a mix of public and private.
Companies like Cisco make a clear distinction between cloud-native network functions (CNFs) and their predecessors, virtual network functions (VNFs). “Virtualization and VNFs helped us in getting started in moving toward cloud-native applications,” the company states, adding that the problem with VNFs is that upgrades are slow and scaling difficult because the applications are typically ported into cloud environments using a “lift-and-shift” approach. Cloud-native applications address these limitations using a microservices architecture that supports dynamic elasticity and scalability.
No choice
“For me, it’s very clearly a must-do,” Swisscom’s Brunner told Telecom TV in an interview filmed at The Great Telco Debate in December when he was asked whether embracing cloud-native technology is essential or merely desirable (you can watch the full interview below).
“It's clear that the cloud native way of doing things is sort of the current best practice in all other industries, and so we need to adopt it,” Brunner added. “I don't see how we cannot do it.”
Sorting it all out
Brunner’s comments were in reference to network functions, but there are many other elements of a CSP’s environment that can be cloud native, such as network management and back-office operational and business support applications. And to muddy the waters even more, cloud native is sometimes used (wrongly) to describe the type of cloud environment or platform (that is, public, private or hybrid).
Our latest report Public cloud: An essential but not singular solution for CSPs, written by TM Forum Senior Analyst Tim McElligott, does an excellent job of sorting through the terminology – and the hype – and explains how operators can begin adopting cloud native technology and taking advantage of public cloud options.
Importantly, the research shows that CSPs have a long way to go in embracing cloud in any form but that doing so is, as Brunner concludes, necessary to remain competitive.
McElligott urges CSPs to take the plunge to not only adopt cloud-native technology, but also embrace public cloud.
McElligott will discuss the report’s findings with senior executives from the companies sponsoring it, MYCOM OSI and Optiva, during a live webinar next week. You can listen in and ask questions by registering at the link below.
“CSPs largely have resisted partnering with public cloud providers because of questions about reliability and security, but they should take the lead of companies like AT&T, Vodafone and Verizon and embrace it for at least some workloads,” he writes. “Not only do the economics and the complex demands of consumers and enterprises demand it, but the cloud is ready.”
McElligott will discuss the report’s findings with senior executives from the companies sponsoring it, MYCOM OSI and Optiva, during a live webinar next week. You can listen in and ask questions by registering at the link below.
Register for the webinar
Download the report
