James Crawshaw, Principal Analyst for Telco IT & Operations at OmdiaJames Crawshaw is Principal Analyst for Telco IT & Operations at Omdia, where he specializes in managed services and operations support systems. These include service and network management systems such as service assurance, orchestration/fulfillment, order management, inventory management, SON, network security, etc.

In the past, public cloud wasn’t considered suitable to meet the stringent performance, security, and data governance requirements of the telecom industry. This was particularly true for Operational Support Systems (OSS) like service assurance, fulfillment, and orchestration. These were regarded as too critical to host on someone else’s infrastructure or so tangled up in a mess of interdependencies that moving them would be a nightmare. Public cloud was seen as suitable for hosting websites, maybe some customer-facing portals – but not OSS.

Slowly that perception has changed. Operators are now looking to host OSS on public cloud – both new off-the-shelf applications that are helping them to automate their network services and the so-called legacy applications that form the core of their IT stack.

Getting comfortable with cloud

Kailem Anderson, VP of Software at Blue Planet, a division of Ciena, notes that as telcos get more comfortable with the concept, more and more operators are asking for network and service automation solutions deployed in the public cloud. Operators are using the public cloud as a complement to their existing private clouds, to better handle demand spikes and ensure continuity. Anderson sees it as part of a bigger transformation to make network operations more software-centric and to move away from highly customized OSS solutions.

This cloud adoption isn’t confined to small, regional telcos, as some might think. Blue Planet is also seeing very large tier-one global operators implementing automation solutions in the public cloud, with one such operator headquartered in Europe aiming to get all their OSS and BSS workloads in the public cloud by 2025.

Kailem Anderson discusses service provider priorities related to migrating B/OSS workloads and automation solutions to the public cloud.

Don’t just lift and shift

Service providers are taking a variety of approaches as they migrate their operations software to the public cloud. Some are simply ‘lifting and shifting’ existing workloads from their own datacenters. This approach, also known as re-hosting, runs the application in virtual servers as part of an Infrastructure-as-a-Service (IaaS) offering. If the service provider has developed the application itself, it might consider re-platforming, also known as “lift, tinker, and shift”, which involves minor changes such as migrating to the public cloud provider’s native database services – part of a Platform-as-a-Service (PaaS) offering. Alternatively, they might refactor the application entirely using cloud-native principles. However, for commercial OSS acquired from third parties, the operator is dependent on the vendor to make its applications more cloud friendly.

Greenfield operators have the luxury of purchasing new, cloud-native applications and choosing to run them in public cloud from the outset. According to Rick Lievano, CTO Worldwide Telecom Industry at Microsoft, brownfield operators are more likely to take a ‘lift and optimize’ approach. Lievano describes this as an inventory check and right-sizing of the application estate before the move to public cloud. Often, operators will find applications that can be retired as their functionality is better carried out by other systems within the estate.

To right-size, operators need to understand the requirements of each application. Microsoft’s Cloud Adoption Framework enables measurement of the CPU, memory, and storage requirements of applications in the on-prem environment. Typically, applications are only using a fraction of the resources that have been allocated to them on premise.

Cloud native, open and programmable

Many vendors describe their solutions as cloud native these days because they are based on a service-oriented architecture and can integrate with other applications via APIs. But to be truly cloud native they must also be microservices-oriented, container packaged, and dynamically managed. The preferred container management system, Kubernetes, gives developers the flexibility to deploy their software on a public cloud IaaS as easily as a private data center.

This flexibility to deploy on public or private cloud without restrictions is one of the key attributes of cloud native, according to Blue Planet’s Anderson. He also notes the dynamic scalability that the Kubernetes orchestrator brings. In tandem with the move to cloud native, Anderson notes that telcos want open and programmable solutions - the system needs to integrate seamlessly with other OSS/BSS as part of an ecosystem of applications. This requires the support of open APIs that have been standardized by organizations such as TM Forum and MEF.

Greater interoperability is key to avoiding vendor lock-in, one of the key concerns of telecom operators today. As service providers refresh their OSS estate, they no longer want to be held hostage by vendors for every move, add, change, or delete request, feature enhancement, or to add support for new network vendors. Nor do they want to be locked into a managed service contract because the OSS application is so complex their own teams can’t support it themselves. Operators want solutions that are easily configurable and do not need customized, proprietary implementations.

Kailem Anderson outlines what cloud native really means, and why it’s important.

From IaaS to PaaS to SaaS

Simply hosting your applications in someone else’s servers can only take you so far. To reap the full benefit of public cloud, software developers use a wide variety of development, database, and analytics tools collectively referred to as PaaS. According to Lievano, PaaS concepts such as serverless computing and database-as-a-service not only make the software developer’s life easier but allow the applications to run more efficiently which benefits the telecom operator that uses the application. However, given that each public cloud operator has its own PaaS tools, the developer must maintain a separate version of their application for each public cloud operator on which they want their software to be available. That duplication of effort might lead the developer to decide to focus on a single public cloud. But what if some customers prefer to use an alternative public cloud provider? The answer is to take the whole software hosting issue out of the customer’s hands and deliver them in a Software-as-a-Service SaaS model.

Blue Planet’s Anderson says SaaS adoption is happening in OSS as telcos overcome their initial reservations. He sees benefits all around from SaaS – it saves the telco the hassle of hosting and managing the applications themselves and it saves developers time porting applications to different cloud environments. In fact, telcos can deploy Blue Planet solutions an order of magnitude faster with SaaS than with traditional software. They can also experiment more easily with SaaS applications, testing new services and doing small-scale trials before deciding whether to proceed. As SaaS is a ‘pay as you grow’ model the operator does not face an upfront capex burden. Consumption is flexible – their usage (and hence what they pay) can be scaled up or down, as required. With fickle consumer and enterprise demand, such flexibility is invaluable.

Microsoft’s Lievano sees the moves to SaaS happening more widely across the OSS ecosystem, just as it has in areas such as email and CRM in the past. Multi-tenant SaaS solutions hosted on public cloud resources can meet the security and privacy needs of telecom operators, and OSS-specific challenges, such as latency, are being addressed. In the end, the superior economics and convenience of SaaS will win out. The journey might start with IaaS and then PaaS but Lievano sees SaaS as the ultimate destination.

Rick Lievano considers service provider readiness to move B/OSS workloads to the public cloud and SaaS consumption models.

Shift happens

We at Omdia believe that, if they haven’t done so already, telecom operators should begin using public cloud for OSS as a complement to their existing private cloud infrastructure. They should experiment by placing some workloads on public cloud to handle capacity spikes and to support new lines of business, such as private mobile networks. Operators should avoid the temptation to simply “lift and shift” legacy OSS to public cloud. Hosting an outdated application on someone else’s server will not improve its functionality. Instead, operators should try to leverage the PaaS capabilities of the public cloud providers either by refactoring their own applications or asking their OSS vendors to do the same. The logical next step beyond migrating OSS to public cloud is for operators to consume it on a SaaS basis. Operators are at different stages of this journey – the important thing is to not get left behind.

Kailem Anderson highlights M1’s implementation of cloud-based 5G services.