The Path to Cloud-Native Applications

The cloud-native approach describes a way of modernizing existing applications and building new applications based on cloud principles, using services and adopting processes optimized for the agility and automation of cloud computing. This e-book describes detailed steps as a part of a successful journey from where you are today to adopting a cloud-native application approach.

 

 

Nokia raises its OSS game

In the build up to MWC 2020 Nokia has got one of its announcements in early, in the form of the ‘cloud-native’ Network Operations Master software.

Turns out 5G is pretty complicated and at times there’s so much going on that you can’t possibly expect flawed, obsolete humans to stay on top of it. That’s why you need greater automation, we’re told, and that has to start with the network operations software, or OSS in old money. Nokia prides itself on its software, so the launch of a new OSS suite is presumably a fairly big deal for them.

“With 5G forcing traditional functions, like revenue management and customer care, to the cloud and helping drive software deeper into the network, communication service providers need a modern approach to performing network operations that is automated, more efficient and scalable,” said Ron Haberman, CTO at Nokia Software. “The Nokia Network Operations Master delivers these capabilities and allows our customers to perform lifecycle operations with ease, efficiency, and confidence.”

Network slicing will make automation and a much higher level of cloudy flexibility critical features of any network software. NOM also covers AI, machine learning, etc and is designed to just take care of all the plumbing, allowing network operations centres to focus on the stuff only people can manage, if such a thing still exists.

“5G networks will require significantly more operations automation than past networks in order to achieve promised levels of efficiency and new service support,” Nokia got Dana Cooperson, Research Director at Analysys Mason, to say. “Nokia’s Network Operations Master is a cloud-native network management system that is underpinned by machine learning and automated actions and provides the types of tools mobile network operations teams need now for 5G.”

Here are a couple of vids that may tell you more.

What we talk about when we talk about digital transformation

Digital transformation is one of the core buzzwords used in the telecoms industry and beyond, right up there with 5G, cloud computing, and artificial intelligence. What sets digital transformation apart from the others is the sheer number of different things it can stand for.

Here we are sharing the opening section of this Telecoms.com Intelligence special briefing to look into how the industry practitioners have undertaken the tasks of digitally transforming their businesses, what are the key success factors as well as the main obstacles to the success of these endeavours, and which approaches they prefer to adopt to tackle the challenges.

The full version of the report is available for free to download here.

In its broadest sense, digital transformation has been used in the socio-economic context by organisations like the United Nations. The 2019 Digital Strategy of United Nations Development Programme (“UNDP”) sees in digital transformation the pathways to the UN’s sustainable development goals. Although it heavily relies on the communications industry to help make the strategy happen, e.g. “digitally deliver policy and programme support”, UNDP’s strategy scope goes beyond that.

When it comes to the communications industry, digital transformation is often cited as an overarching theme to encapsulate all the telecom operators’ efforts to expand their role from mere connectivity provider to that of a digital service platform. However, there are so many components in such a context that one would likely get a different definition of digital transformation from every industry person one asked.

To start with, certain quarters of the industry, still occasionally conflate digitisation with digitalisation. It is therefore necessary to clarify the concept from outset. Digitisation refers to the change from analogue to digital. For example, the process can be called digitised when the application form to open a mobile account can be filled out on the computer instead of in paper form. Digitalisation refers to the change of processes, often focusing on automating previously manual processes, using digital technologies. In the example of opening a mobile account, the process can be viewed as digitalised when the whole application process is done online. Digitisation is therefore a prerequisite for digitalisation.

In the mobile telecoms world, digitisation was completed when 2G replaced (the retrospectively named) 1G networks. Digitalisation, on the other hand, is still an ongoing process and by all accounts will be with the industry for a long time, not the least because digital transformation is so much more complex than digitising the radio signal.

Despite that telecom operators may not agree with one another what digital transformation means to them individually, almost all of them agree collectively that they must undertake the transformation. This is both a strategic imperative and a competitive necessity. It is also widely agreed that the main objectives of digital transformation include:

  • To grow top line revenues as a way of sustaining the business, when the income growth from selling voice minutes, text messages, and data packages has stalled
  • To defend bottom line by improving operational efficiency
  • To develop technological and organisational capability to be more future ready

The following chapters of this report will look into the key steps the industry has taken and still needs to take, the major obstacles to overcome and the worst misunderstandings to dispel, to achieve digital transformation objectives. The discussion and analysis will draw heavily on the first-hand insight and experience from the practitioners.

Modernization of OSS/BSS with Open Source, Part 3: Integration

This is the third article of a four-part series, companions to a set of four webinars[1]. In the first article, we describe how open-source software can speed the evolution of OSS and BSS to a modern cloud-native microservices-based architecture. In the second article we explain how open source can be used to automate business, network and IT to provide initial quick hits that rapidly bring value to a CSP and, eventually, lead to fully automated operations. In this article, and in the corresponding webinar, we describe how open-source integration tools and frameworks can be used to integrate existing and new systems for near-term benefits and pave the way to implementing the cloud-native architecture of the future.

Introduction

To realize the agility and velocity that have become imperatives in the market environment today, communications service providers (CSPs) must transform their service delivery and management infrastructure. This means that the systems that underpin their network and service operations must evolve. These are the operations support systems (OSS) that enable the operator to manage the network and the business support systems (BSS) that facilitate the management of the customer and overall business operations.

The modernization of the OSSs and BSSs is based on three pillars:

Figure 1. Pillars of OSS and BSS Modernization

The importance of integration in OSS and BSS modernization

The CSPs’ software infrastructure has typically evolved over many years, with new systems added to support each new service or technology as needed. The result is that even a small Tier 3 CSP may have hundreds of systems while a Tier 1 CSP can have as many as 1,500 different systems (often with multiple instances of each). Attempts to replace these systems with an end-to-end pre-integrated infrastructure all at once in the past have failed and have often led to business disruption. Therefore, it is recommended that operators proceed in incremental steps, with smaller, department-sized transformations, implemented in multi-phase projects. This iterative process, while optimal, has the inherent requirement to reintegrate systems as they are updated or replaced into the evolving OSS/BSS environment. This constant integration requirement highlights the need for a strong integration architecture that is cloud-native, distributed, microservices-based and containerized.

Modernizing OSS/BSS Integration Architectures

The traditional centralized enterprise service bus (ESB) architecture, on which CSPs relied for integrating systems until recently, is ill-suited to the dynamic integration environment that is essential in the market. Therefore, operators need to move to a modern, cloud-native one, based on a distributed architecture with open Application Programming Interfaces (API) and agile teams using new DevOps development methodologies.

Figure 2. Modern Agile Integration vs. Traditional Approach (Source: Red Hat)

Traditional architectures have centralized integrations into one large platform where integrations are controlled by the team that owns the ESB platform and that has the specialized expertise to operate it. Developing new applications against the platform typically required several attempts to get everything right. The entire integration platform had to be functional for anything to work, and failures of individual components could affect totally unrelated applications. This has resulted in very long cycles to introduce or modify services.

On the other hand, cloud and container-based architectures are developed completely differently. Monolithic applications are broken up into services designed to be small, reusable and loosely coupled to refactor the original application. A container runs one and only one service usually, allowing flexibility in deployment and scalability. Integration between services and applications is distributed among the exact elements where it is needed, no more but no less than is required. Applications and services interact with APIs and expect the services implementing each API to behave as documented without needing to know the implementation detail. Service developers implement their code using whichever language and framework that make sense (and comply with corporate standards). The technical requirements are simple: the service implements the API, no more and no less than documented, allowing the services to be developed and evolved separately with little to no overall system regression testing. This enables the organization to respond more quickly to changing business requirements and priorities and to implement innovative ideas more quickly and efficiently.

The distributed nature of the architecture in Figure 2 describes not only how a cloud native application can be architected, but also how multiple old and new systems can be integrated together in a modern architecture. The distributed services can be microservices or can be wrapped, containerized legacy systems integrated with the new microservices in an overall framework. The right side of Figure 2 shows the containerized elements of an application built with a cloud-native architecture. These services within the application can be newer microservices or legacy ones wrapped with APIs for integration into the overall framework.

Tools for Integrating Systems for OSS/BSS Modernization

CSPs can implement a modern integration architecture using the following set of open-source tools and platforms for the underlying technology:

Integrating microservices inside a new system: New, cloud-native software applications built on containerized microservices require an integration platform to provide the internal communications among microservices, data sources and network elements, whether virtual or physical. Excellent examples of a distributed, cloud-native integration platform are Red Hat Fuse, part of Red Hat Integration, and OpenShift Service Mesh for inter-microservices communication.

Integrating new systems into the existing OSS/BSS complex: To interface the new cloud-native systems with the existing systems, an API management platform is needed. Red Hat 3scale API Management and Red Hat OpenShift Service Mesh are examples of integration frameworks that underpin an API first approach. They provide API visibility and control, security, rate limits, analytics, API keys and a developer portal, allowing the overall management of internal and external APIs.

If the existing systems do not provide RESTful APIs in a service-oriented architecture, they need to be wrapped to provide the APIs. Red Hat AMQ, part of Red Hat Integration, is an Apache Kafka-based platform, providing messaging-as-a service and streams operators, as well as an HTTP bridge. It supports microservice applications, provides an efficient bridge to legacy systems, and enables large-scale solutions.

Integrating and federating legacy systems: Many legacy systems duplicate functions for different work groups and systems in the various organizations, geographies, business areas or network technologies. This often requires manual intervention during provisioning, trouble management or network management processes, resulting in delays and potential errors. Quick-hit integration and federation projects using event and message-based integration technologies bring near-term benefits. A good example is the federation of multiple inventory systems, which leads to reducing database discrepancies and to mitigating the need to access multiple systems. As another example, the synchronization of trouble ticketing systems allows the free flow of information and status among them and obviates the need for manual intervention, thus reducing costs and potential errors and improving customer satisfaction.

The computing infrastructure platform supports the software/container platform with OS, compute and storage resources, creating the right containers for the software with the right computing resources at the right location. It also manages the environment for the container creation and for the management of the API wrapped legacy systems and the new microservices. Red Hat OpenShift is a popular example of such an infrastructure platform.

Conclusion

CSPs’ need for agility and velocity to compete creates requirements for constant integration as the overall OSS/BSS environment evolves piece by piece, leading vendors, systems integrators, and CSPs themselves to adopt new open-source solutions for agile integration. Adopting API led design with new software development methodologies benefits developers with shorter development times and less testing, users with faster implementation of new features and functionality, and business owners with increased business agility. Adopting standard open-source platforms across the business provides a homogeneous technology base, allowing for faster, more reliable feature development at scale. Red Hat Integration and Red Hat OpenShift solutions are ideally suited to the iterative modernization journey for OSS and BSS.

[1] For the webinars, see:
Introduction to modernizing OSS/BSS with microservices-based, cloud-native architectures,
Automate OSS/BSS to drive innovation and reduce operating costs,
Agile integration for OSS/BSS flexibility, reusability and scale,
Transforming OSS/BSS from monoliths to cloud-native applications.

Increase OSS and BSS efficiency with Red Hat agile integration

Disparate operations support systems (OSS) and business support systems (BSS) lack scalability and limit the value of network and application data. IT teams need federated access to legacy systems and data, while developers and partners need secure, easy access to systems.

An application programming interface (API)-centric approach to integration, secured via API management, addresses these issues for modern, containerized technology and application adoption. Exposing data and functionality using APIs supports reuse and modernization of legacy applications and systems, increases agility and scalability of internal and partner OSS and BSS systems, and reduces maintenance costs.

Red Hat’s API-centric agile integration solution for OSS and BSS processes and systems combines multivendor products with customer-owned systems. This Red Hat solution provides a single security framework that also supports TM Forum API specification standards and an automated, service-oriented approach.

Microservices-Based Cloud Native Modernization of OSS/BSS with Open Source

This article is sponsored by Red Hat

Market forces and changes in subscriber needs and expectations are leading Communications Service Providers (CSPs) to transform their entire service delivery and management infrastructure. At the forefront of this transformation is the modernization of the systems that enable the management of network services, the operations support systems (OSS) and systems for managing the customer and the overall business operations, the business support systems (BSS). Current systems were built for a business paradigm that is increasingly outdated; they are rigid, siloed, rely on extensive human involvement and often require esoteric skills. Modernization of these systems enables CSPs to address requirements for becoming the Digital Service Providers (DSPs) of the future: business agility, elastic scale and capacity, service velocity and the ability to continuously reinvent themselves.

CSPs can build a foundation for successful modernization by standardizing on managed open source because it provides tools and services optimal for continuous integration and automation, critical to future-proof the complex digital business transformation.

THE OSS AND BSS MODERNIZATION IMPERATIVES

The modernization of the OSS and BSS systems has three main requirements:

 


Figure 1 OSS/BSS modernization imperatives

In this article, we focus on the evolution to cloud-native containerized microservices, powered by managed open source software.

THE OSS AND BSS MODERNIZATION VISION

CSPs need to drive significantly lower costs and a commensurate increase in agility in their business and operations to survive in today’s competitive environment, Their legacy OSS and BSS systems were designed primarily to support the people who operate the workflows (hence, the names Operations and Business Support Systems). These systems need automation and orchestration to evolve toward operating the business, autonomously, under the control and oversight of people.

The new environment will be microservices based. OSS and BSS functions will be instantiated as containerized microservices interconnected via a service mesh, guided by business policies and governance rules, and ultimately overseen by people. This architecture will eliminate silos and provide the underpinnings for continuous integration and continuous development (CI/CD).


Figure 2. OSS/BSS Modernization Vision

EVOLVING TO A MICROSERVICES ARCHITECTURE

The modernization of the OSS and BSS systems should proceed in steps. Undertaking a massive transformation of OSS and BSS systems could result in business disruption and would likely not succeed. Instead, the service provider should start by identifying discrete tasks and well-defined business processes to automate. This enables the organization to reap quick optimization results with minimal disruption, to prove the new technology, and to give employees the opportunity to work in a microservices-based environment. At the same time, the telco can containerize and enhance old systems with API management wrappers. This will require minimal development and disruption, but will improve the reliability, scalability, and IT operations costs.

As new capabilities are added, they should be added as containerized microservices in a cloud native architecture. Once the operator has a substantial set of microservices, it can proceed to redefine the management domains, collapsing the separate domains into a rationalized cross-domain architecture that is optimized for automated operations, not duplicating the organizational structure of the CSP.


Figure 3. OSS/BSS Modernization Journey

As for “monolithic” legacy systems, they will be re-platformed (“lifted and shifted” into containers for more efficient IT operations) and refactored over time into smaller pieces, which may eventually be further refactored into sets of microservices. This may happen all at once, or in stages, balancing the refactoring of the legacy monolith with building new (and refactored) features and functions on the new cloud native architecture.

ENABLING MICROSERVICES ACROSS THE ORGANIZATION

The migration to microservices should be accompanied by important changes across the organization. In the words of Jez Humble, “Reminder: If you’re building microservices, you’re building a distributed system.” Therefore, along with the modernization journey described above, the operator should carefully introduce organizational changes. For example, to maximize the benefits of the distributed microservices environment, the operator should incentivize collaboration, adopt DevOps principles, and introduce the right organizational capabilities for continuous development, continuous testing and continuous delivery. Only when the service provider has taken this comprehensive approach to modernization will it fully realize its goal to become a digital service provider.

CONCLUSION

The modernization journey will be a long process, but one whose benefits match the continuing investment required. A “big bang” investment would likely only deliver benefits in the outer years and may lead to business disruption. However, this transformation process means that the operator will be operating in a hybrid environment, gradually migrating functionality to the cloud. This ongoing transformation with continuous development and integration can best be achieved by using open source technology to ensure that there is no “lock in” to proprietary or obsolete technologies. The open source community is now large enough that technologies that are superseded drive conversion tools available to the next technology. Thus, open source-based transformation future proofs the systems.

Telecoms industry set to reveal its hopes and fears

It’s that time of the year when Telecoms.com once again conducts the signature Annual Industry Survey. Answering it will not only let us know what you think, but will benefit the telecoms industry as a whole, and in turn, yourselves too.

The 2019 Annual Industry Survey (AIS) has just gone live. True to its mission, this survey is designed to take the pulse of the telecoms industry, in particular of those topics most pertinent to operators, suppliers, technology vendors, analysts, consultants, and everyone else with a stake in the telecoms ecosystem. It’s my job to write collate the responses and present them to you.

This year’s survey covers many of the core technology topics the telecoms decision-makers are most interested in reading about, including Industry Landscape, 5G, Digital Transformation, IoT, and BSS/OSS. Undoubtedly the readers of this story, you, are in the best position to tell us, and the industry, how you see the current status of the industry and where you see it heading for. So, please, click here to answer it.

I was thinking about giving this story a title like “Your Industry Needs You”, but that would be too Kitchener-esque, plus I don’t have the beard to go with it. Instead, I’ll go full Churchillian: I have nothing to offer but a high-quality survey report for free, a sense of contribution, and the chance to win a new Apple Watch.

If this is your first experience with our AIS, or if you’re simply interested in finding out how correct (or incorrect) we have been with our understanding and predictions, feel free to check out last year’s results.

Vodafone Australia admits to misleading carrier billing service

After an Australian Competition and Consumer Commission (ACCC) investigation, Vodafone Australia has admitted misleading consumers through its third-party Direct Carrier Billing (DCB) service.

The investigation looked into transactions made between 1 January 2013 to 1 March 2018, though it is most likely Vodafone broke the rules upon the introduction of an Australian Securities and Investments Commission Act in 2015.

“Through this service, thousands of Vodafone customers ended up being charged for content that they did not want or need, and were completely unaware that they had purchased,” said ACCC Chair Rod Sims. “Other companies should note, money made by misleading consumers will need to be repaid.”

The service was first introduced in January 2013 allowing customers to purchase digital content from third party developers such as games, ringtones and apps, with charges being applied to pre-paid and post-paid accounts.

The issue which Vodafone seems to be facing is the service was automatically applied to customer accounts, with purchases being made with one or two clicks. As the customer was not suitably informed, the service has been deemed to be misleading.

Vodafone has already begun the process of contacting impacted customers and will be offering refunds where appropriate. The telco has phased out the majority of the service already, owing to an increasing number of complaints during 2014 and 2015.

While a final judgment has not been released just yet, a confirmation and fine will likely follow in the next couple of weeks, other Australian telcos have been found guilty of the same offence. Both Telstra and Optus have been fined AUS$10 million for their own misleading carrier billing services.

Although it is hardly rare for a telco to be found on the wrong side of right, especially in Australia where the ACCC seems to be incredibly proactive, such instances will create a negative perception at the worst time for the telcos.

In an era when the telcos are searching for additional revenues, carrier billing initiatives are an excellent option. Assuming of course the telcos don’t mess it up.

The digital economy is becoming increasingly embedded in today’s society though there are still many consumers who will begrudgingly hand over credit card details to companies with whom they are not familiar. This mistrust with digital transactions could potentially harm SMEs while providing more profit for the larger players who have established reputations on the web.

In this void of trust and credibility, the telcos have an opportunity to step in and play the intermediately as a trusted organization; how many people have an issue with handing credit card information over to a telco?

There are plenty of examples of this theory in practice; Amazon or eBay are the most obvious and most successful. These are online market places which allow the flow of goods and cash between two parties who may not have had a prior relationship. The consumer might have an issue paying Joe Bloggs Ltd. as there is little credibility, though many trust the likes of Amazon and eBay, allowing the third party to manage the transaction and take a small slice of the pie.

Carrier billing can be an excellent opportunity to add value to a growing digital ecosystem, using the consumer trust in the telcos to drive opportunities for those businesses which want to grow online. However, should there be a perception that the telcos do not act responsibly with a customers’ bill, this opportunity will dry out very quickly.

Aside from costing Vodafone a couple of million dollars, this also dents the credibility of the telco (and overall industry by association). This example suggests it is just as risky purchasing goods through the telco as it is an unknown supplier online.

CMA backs super complaint against loyalty penalties

The Competition and Markets Authority (CMA) has backed a ‘super complaint’ raised by Citizens Advice which suggests UK consumers are being ripped off by loyalty penalties on services such as broadband.

The super complaint was raised by in September by Citizens Advice, asking the CMA to investigate whether customers were effectively being punished by service providers, so called stealth price rises for example. The areas being called into question were cash savings, mortgages, household insurance, mobile phone contracts and broadband.

The CMA agrees with the points raised by Citizens Advice, suggesting the segments in question gain £4 billion a year through ripping off loyal customers.

“Our work has uncovered a range of problems which leave people feeling ripped off, let down and frustrated,” said Andrea Coscelli, CEO of the CMA. “They shouldn’t have to be constantly ‘on guard’, spending hours searching for or negotiating a good deal, to avoid being trapped into bad value contracts or falling victim to stealth price rises.”

Looking specifically at the telcos, this is a frustrating point for many consumers. UK telcos show very little desire to reward customers, setting in processes and systems which make it impossible to leave. Many will give up on trying to navigate the red-tape maze as the poor experience proves to be favourable to the frustrations of trying to leave. By making this process as difficult as possible, the telcos don’t have to worry that much about retention and can instead focus on luring new customers.

The CMA has pointed this out during its own investigation, ensuring that one of the recommendations made to government and regulators will be to simplify the exiting process. This will intend to tackle the process, systems and the fees which customers face when attempting to secure a better deal.

It appears the telcos are much better at scaring customers away from exiting than enticing them to stay with positive customer service. Your correspondent can confirm this is the case after trying to end a Vodafone contract last year. It took a ridiculous amount of time, engagement with several staff who had no idea what they were doing (or was this trained in to make the process as painful as possible?) but the mission was stubbornly completed.

“We know that the better deals are often found by switching provider,” said Richard Neudegg, Head of Regulation at uSwitch.com. “But many companies make this more difficult by not being transparent enough about the options available or how to take your custom elsewhere. We are pleased to see the CMA identify this as an area for improvement, to ensure the power to get better deals is placed firmly in the hands of consumers.”

One specific complaints which has been firmly aimed at the telcos concerns subsidized handsets. The CMA highlights telcos should not be allowed to charge the same amount per month once the handset has been fully paid for. This will be a frustration from the consumer, but like the ridiculous nature of roaming fees, because the industry has stuck together little progress has been made.

Above all else, the CMA opinion adds to the already well-known position that telcos are not at all customer-centric organizations and have a lot to do if they want to be considered relevant for the digital economy.