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.

 

 

Modernization of OSS/BSS with Open Source, Part 4: Transforming OSS/BSS from Monoliths to Cloud-Native Applications

This article is sponsored by Red Hat

This is the final article of a four-part series, summarizing 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 the third article, we describe how open-source integration tools and frameworks can be used to integrate existing and new systems for quick-hit benefits and serve as a basis of the cloud-native architecture of the future. In this article, we share with the developers of OSS/BSS systems, CSPs, ISVs, and SIs how they can move their current monolithic software systems toward modern, containerized cloud-native architectures and automate their overall IT operations.

Introduction

Communications service providers (CSPs) today are transforming into the digital service providers (DSPs) by digitizing their networks, operations and services (see Figure 1). Although these transformations are often parallel efforts, they should align around common business imperatives and should be tightly integrated. Open source is the proven underlying technology that can generate synergies across those transformation efforts.

Figure 1. Open Source Enables Digital Transformation

Becoming a DSP requires modernizing operations support systems (OSS) and business support systems (BSS). CSPs must work closely with independent software vendors (ISVs) and systems integrators (SIs) to move current OSS/BSS solutions to the cloud-native, common, open-software technology base of the future.

Cloud-Native OSS and BSS is the future

CSPs usually have hundreds, if not thousands, of OSS and BSS. Modernizing those systems should proceed in steps to mitigate business disruption and generate quick wins. ISVs and SIs must keep in lockstep with CSPs to provide the solutions and support they require. It is realistic to expect that some systems will be retired, some will continue in their monolithic form, and others will in some cases evolve to keep up with business imperatives. Still other systems will evolve along a stepwise trajectory and will ultimately become cloud based, or at least synergistic with a cloud-based environment. Figure 2 shows the alternatives for OSS and BSS evolution.

Figure 2. Transitioning to a Cloud-Based OSS and BSS

This transformation will likely be several years in the making. ACG projects that by 2025, approximately 10% of the systems will remain monolithic, while about 60% will be cloud-native based, with the remainder 30% being partially refactored.

OSS/BSS Modernization Strategies

CSPs that develop their own systems and ISVs and SIs that sell these systems to CSPs have a number of strategies to consider for modernizing them. Each approach has business and operational considerations and tradeoffs. Although these options are not unique to OSS and BSS, the level of complexity is compounded for them by the sheer number of such systems (which can reach into the thousands) interwoven at most CSPs.

Figure 3. OSS and BSS Modernization Alternatives

  • Rehost: Also referred to as lift and shift, involves repackaging the existing system and porting it to a new environment, typically a container, with minimal changes. Although this approach is the lowest risk, lowest cost option, it comes up short in delivering the true promise of a cloud-native system in terms of service velocity and elasticity.
  • Replatform: Also known as tinker and shift, requires a larger effort because it may necessitate software modifications to adapt to the operating system, to a portion of or the entirety of the application to optimize it before moving it to the cloud. Although this approach can be more costly and typically requires more time and effort, some cloud optimization can deliver meaningful benefits without the cost and risk of a full repurchase approach. Furthermore, by enabling the reuse of some of the existing resources, replatforming requires less retraining and fewer changes to methods and procedures.
  • Refactor: This approach entails making more significant changes to the application, but provides the most significant benefits, making it the preferred path in many cases. The degree of changes to the application code necessitates that the CSP ensures that this upgrade does not result in business disruption. But it also provides a good opportunity to modernize the existing operational framework, which may necessitate possible changes to the methods and procedures, as well as retraining. This approach can result in the application delivering the true benefits of a cloud-based environment in flexibility, velocity and elasticity. Re-factoring can also be taken in steps or can be done partially.

Given the significant benefits of fully cloud-native software combined with the agility and velocity derived from DevOps for operations and CI/CD, most applications should be refactored over time to reap those full benefits.

OSS/BSS Modernization and Overall Digital Transformation

The strategies recommended for modernizing the OSS and the BSS can also be used to modernize the other pillars of digital transformation: network resources and digital services. Modernizing all software infrastructure using the same underlying technologies and methodologies allows CSPs to migrate to cloud-based architectures and to enable consistent DevOps processes and CI/CD delivery methodologies across the CSP, maximizing their benefits and smoothing the way to digital transformation. The following are some examples of how these enable network and service modernization.

Modernizing network resource provisioning and automation

Until recently, network infrastructure was built using proprietary solutions that had software running on specialized hardware. This infrastructure needed to be created, managed, scaled, and decommissioned as the needs of the business changed. Because of its hardware foundation, it was subject to limitations similar to those we described for OSS and BSS, such as rigidity, long development cycles, and high cost. Today, Network Functions Virtualization network infrastructure is becoming software-based running on off-the-shelf hardware and becoming increasingly agnostic to the particular VMs and containers deployed. Since these virtualized network resources will be managed by the modernized, flexible OSS and BSS, it is essential that they too be implemented, scaled, and continuously audited for compliance with standard implementations using open source tools. They also should be automated for optimal allocation of network resources. Some of the tools that are best for these capabilities:

  • Red Hat OpenShift Container Platform for container selection, instantiation, and implementation of the necessary software for OSS, BSS and network resources.
  • Red Hat Ansible Automation Platform for automating the system configuration and the regular system compliance checks against corporate standards.
  • Red Hat Process Automation Manager, Red Hat Decision Manager and Red Hat Ansible Automation Platform, for task and process automation.
  • Red Hat Integration for a flexible, distributed approach to integrationand process automation.

Delivering digital services

The services of the future will be software-based. Virtual network functions, delivering software-based enterprise solutions, such as firewall and WAN optimization, are forecast to generate about $7 billion for service providers in 2023, and IoT services will serve both the consumer and business markets. These services require the agility and flexibility that only a software-based infrastructure can deliver. Because these services will be delivered and managed by the same infrastructures (OSS and BSS), it behooves the service provider to use the same underlying technologies and solutions to develop these services or to source them from vendors that have adopted open source as the foundational technology in their solutions.

Conclusion

The transformation of CSPs into DSPs requires multiple, coordinated transformations of the network (from hardware based to cloud-native software based), the operations (from people-based operations supported by OSS and BSS to automated operations using a containerized cloud native software platform), and digital services (provided by a cloud-native microservices-based architecture). Delivering all of these using modern DevOps and CI/CD processes helps achieve the business agility and cost structure critical to competing in the transformed environment. Although, in some cases, it is advantageous to start afresh with the new software architectures and development and delivery processes, it is not necessary. Multiple paths for moving from monolithic systems to cloud-native systems, based on open source, have been proven.

This transformation requires that the network, digital services, and operations processes be automated to the greatest extent possible. Current open-source software tools and platforms, again, have proven to match exactly what is required for this transformation.

The future of networks is open source.

[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.

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.

Modernization of OSS/BSS with Open Source: Part 2: Automation

This article is sponsored by Red Hat

This is the second article of a four-part series. In the first, we described how open-source software can speed the evolution of the OSSs and BSSs to a modern cloud-native containerized microservices-based architecture. In this paper and in the companion webinar, we describe 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.

INTRODUCTION

Communications Service Providers (CSPs) must transform their service delivery and management infrastructure to remain competitive. 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 the systems for managing the customer and the overall business operations, the business support systems (BSS). Modernization of these systems is essential for business imperatives today: agility, elastic capacity scaling, and service velocity.

The modernization of the OSS and BSS has three main imperatives:

  • Cloud-native platform for both development and operations
  • Integration architecture to coordinate disparate systems and hybrid environments, thus enabling iterative transformation
  • Automation of the business, network and IT

THE IMPORTANCE OF AUTOMATION IN OSS AND BSS MODERNIZATION

Legacy OSS and BSS are inadequate for the needs of the modern CSP because they were primarily designed to assist the humans in executing the processes that ran the business. To support the modern CSP, these systems need automation and orchestration to operate the business quickly and autonomously under the control and oversight of people. This requires the CSP to define a roadmap to ultimately automate all the processes that run the business and manage the network.

Automation is not new; it has been around since computers were brought into the CSPs’ operations in the 1950s. What is new is the need to automate all the processes end-to-end and to enrich the automation of changes in the systems themselves as they evolve to meet new business needs.

Automating business processes to drive business agility

Basic consumer business operations, where transaction volumes are large and the tasks relatively simple, have already been automated to a great extent. Today, customers expect self-service and a great overall digital experience. To meet these demands, CSPs are introducing and modifying services and operations at an unprecedented speed. Supporting this new normal necessitates increased automation in product life-cycle management and a fundamental redesign of the BSS that manages services and customer experience.

Automating processes for business services is inherently complex because they require human involvement in analyzing needs, mapping to available services, quoting the services during the sales process (taking into account what the business customer already has or will have), and installing, configuring and supporting the services on an ongoing basis. Thus, there is much opportunity for reducing cost, friction, and time in this area.

Automating network management processes to increase agility and reduce cost

Network management processes are very labor intensive. Specialized technicians are needed to plan and order a wide variety of equipment, install it, configure it. They must configure services on the equipment (driven by service orders) and ensure that the configuration information is up to date on an ongoing basis. Technicians usually accomplish this with command line interfaces (CLI), supported by spreadsheets, configuration playbooks, and some automation and orchestration tools either from vendors or purpose-built by the CSP. These processes must be streamlined and eventually replaced by fully automated, intelligent and self-managed processes under the oversight of humans.

Network and OSS/BSS modernization also requires a new type of automation

As digital transformation changes how CSPs deploy and manage network functions and how they deliver services, automation has a new requirement: to automate (or orchestrate) the instantiation of the right software in the right container on the right computing and storage infrastructure at the right time, dynamically connected with other software systems. As software-based functions and services become more ubiquitous, more automation and overall orchestration is needed to control operational costs and to deliver the speed that is essential for the CSP operations.

Journey to a closed-loop automated environment

Re-engineering processes is a long-term journey and must be undertaken in steps to reap short-term benefits but done in the context of a well-defined, adequately thought-out long-term architecture. This iterative process is essential to minimizing business impact and to ensuring that the transformation is adaptable to changing business needs and technology evolution. Furthermore, the automation journey should proceed in steps of increasing complexity, starting with automation at the isolated task level, then at the domain level, and finally, when all domains have been automated, simplifying the domain structure itself. This process, depicted in Figure 1, has been proven most effective.

 

 

 

 

 

 

 

 

 

 

Figure 1. OSS/BSS Automation Journey

Step 1: Tactical Task Automation

The first step is to find tasks to automate that can bring immediate benefit. Some of these are in the business area (BSS), but many more are in the network management area (OSS). In task automation, existing checklists of manual processes are automated using Robotic Process Automation techniques. Simply put, these are sets of processes with minimal branching and looping that perform repetitive tasks. Red Hat Ansible[1] Automation is an open-source solution that has been shown to be particularly effective in doing this. Examples of quick-hit task automation are shown in Table 1.

Step 2: End-to-End Domain Process AutomationTable 1. Sample Task Automation Use Cases

Once the individual tasks have been automated, CSPs can automate more sophisticated processes end-to-end. This requires automation software that uses business process model and notation, decision model and notation, a complex event processing engine and a constraint-based optimization engine. These can be found in open-source solutions such as the Red Hat Process Automation Manager[2] and the Red Hat Decision Manager[3].

For BSSs, the domains can be customer types, for example, consumer and business. Further breakdowns into service types are customary: for consumers domains can be voice, video, and data and for businesses they can be segment-targeted services, such as SD-WAN for enterprise.

For OSSs, the domains follow technology lines, such as optical transport, radio networks, IP transport, SD-WAN, IP-VPNs, and IoT end-point devices, and sometimes these domains are further broken down into islands for each vendor.[4]

Typical automation use cases at the domain level are shown in Table 2.

 

 

 

 

 

 

 

 

Step 3: Domain Simplification and OptimizationTable 2. Example Process Automation Use Cases

After the major processes have been automated within their domains, CSPs should introduce cross-domain orchestration to coordinate across the boundaries of the domains. When sufficiently in place, the orchestration system can replace the underlying domain management systems, simplifying the operations architecture and reducing the number of systems supported.

CONCLUSION

OSS/BSS modernization is a journey whose benefits make it worth taking. To reap short-term benefits while balancing the overall needs of the business, the CSP should start with quick-hit task automation and ultimately migrate to end-to-end process automation. This enables the CSP to optimize the development costs and benefits on an ongoing basis. This approach has been proven to work better than a big-bang investment with its likely delayed benefits and potential business disruption. This transformation with continuously evolving automation 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 the availability of conversion tools to the next new technology. Thus, open source-based transformation future-proofs the systems.

[1] See https://www.redhat.com/en/technologies/management/ansible.

[2] See https://www.redhat.com/en/technologies/jboss-middleware/process-automation-manager.

[3] See https://developers.redhat.com/products/red-hat-decision-manager/overview.

[4] The domain management is usually accomplished with a mixture of vendor-specific domain managers (the next generation of EMS/NMS systems) and multivendor cross-vendor and cross-domain orchestration systems.

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.

Open Source for Modernizing Telecoms OSS/BSS

The future of telecommunications operations and business support systems (OSS/BSS) is automated. To meet this challenge, communications service providers (CSPs) are modernizing their OSS/BSS architecture and transforming into digital service providers (DSPs). ACG Research identifies the steps for implementation and recommends an agile, cloud native, microservices-based environment powered by managed open source software with advanced tools for automation and integration.

In this paper, you will discover the drivers for modernization, along with:

  • A vision for the evolution of OSS/BSS systems
  • A road map for achieving modernization
  • Key open source software to power the journey
  • Sample use cases and technology recommendations

Nvidia takes 5G to the edge with help from Ericsson and Red Hat

Graphics chip maker Nvidia has unveiled its EGX Edge Supercomputing Platform that is designed to boost 5G, IoT and AI processing at the edge of the network

Nvidia has long been the market leader in GPUs (graphics processing units), which has enabled it to get a strong position in supercomputing, where the parallel processing qualities of GPUs come in especially handy. This EGX initiative seems to be Nvidia’s attempt to translate that position from datacentres to the edge computing.

“We’ve entered a new era, where billions of always-on IoT sensors will be connected by 5G and processed by AI,” said Jensen Huang, Nvidia CEO. “Its foundation requires a new class of highly secure, networked computers operated with ease from far away. We’ve created the Nvidia EGX Edge Supercomputing Platform for this world, where computing moves beyond personal and beyond the cloud to operate at planetary scale.”

There seems to be a fair bit of support for this new platform, with a bunch of companies and even a couple of US cities saying they’re already involved. “Samsung has been an early adopter of both GPU computing and AI from the beginning,” said Charlie Bae, EVP of foundry sales and marketing at Samsung Electronics. “NVIDIA’s EGX platform helps us to extend these manufacturing and design applications smoothly onto our factory floors.”

“At Walmart, we’re using AI to define the future of retail and re-think how technology can further enhance how we operate our stores,” said Mike Hanrahan, CEO of Walmart Intelligent Retail Lab. “With NVIDIA’s EGX edge computing platform, Walmart’s Intelligent Retail Lab is able to bring real-time AI compute to our store, automate processes and free up our associates to create a better and more convenient shopping experience for our customers.”

On the mobile side Ericsson is getting involved to build virtualized 5G RANs on EGX. As you would expect the reason is all about being able to introduce new functions and services more easily and flexibly. More specifically Ericsson hopes the platform will make virtualizing the complete RAN solution cheaper and easier.

“5G is set to turbocharge the intelligent edge revolution,” said Huang. “Fusing 5G, supercomputing, and AI has enabled us to create a revolutionary communications platform supporting, someday, trillions of always-on, AI-enabled smart devices. Combining our world-leading capabilities, Nvidia and Ericsson are helping to invent this exciting future.”

On the software side a key partner for all this virtualized 5G fun will be Red Hat, which is getting its OpenShift Kubernetes container platform involved. It will combine with Nvidia’s own Aerial software developer kit to help operators to make the kind of software-defined RAN tech that can run on EGX.

“The industry is ramping 5G and the ‘smart everything’ revolution is beginning,” said Huang. “Billions of sensors and devices will be sprinkled all over the world enabling new applications and services. We’re working with Red Hat to build a cloud-native, massively scalable, high-performance GPU computing infrastructure for this new 5G world. Powered by the Nvidia EGX Edge Supercomputing Platform, a new wave of applications will emerge, just as with the smartphone revolution.”

Things seemed to have gone a bit quiet on the virtualization front, with NFV, SDN, etc having apparently entered the trough of disillusionment. Nvidia is a substantial cloud player these days, however, and judging by the level of support this new initiative has, EGX could a key factor in moving the telecoms cloud onto the slope of enlightenment.

IBM and Red Hat seal the deal

The $34 billion acquisition of opensource enterprise software vendor Red Hat by venerable tech giant IBM has finally been completed.

The mega M&A was first announced last October and, given the size of it, seems to have gone through relatively quickly. Now begins the significant undertaking of integrating two such massive organisations that may well have quite distinct cultures.

IBM was founded in 1911 and has undergone several transformations to become the enterprise software and services company it is today. Red Hat only came into existence in 1993 and has always focused on the decidedly un-corporate open-source software community. IBM will be hoping some of its youthful vigour and flexibility will rub off, but that remains to be seen.

The official line is that the acquisition makes IBM one of the leading hybrid cloud providers as well as augmenting its software offering. There’s much talk Red Hat’s independence being preserved but, of course, it will now be taking orders from IBM.

“Businesses are starting the next chapter of their digital reinventions, modernizing infrastructure and moving mission-critical workloads across private clouds and multiple clouds from multiple vendors,” said Ginni Rometty, IBM chairman, president and CEO. “They need open, flexible technology to manage these hybrid multicloud environments. And they need partners they can trust to manage and secure these systems.”

“When we talk to customers, their challenges are clear: They need to move faster and differentiate through technology,” said Jim Whitehurst, president and CEO of Red Hat (what’s the difference?). “They want to build more collaborative cultures, and they need solutions that give them the flexibility to build and deploy any app or workload, anywhere.

“We think open source has become the de facto standard in technology because it enables these solutions. Joining forces with IBM gives Red Hat the opportunity to bring more open source innovation to an even broader range of organizations and will enable us to scale to meet the need for hybrid cloud solutions that deliver true choice and agility.”

That’s it really. There’s lots aspirational talk and general banging on in the press release, but you get the gist of it. Whitehurst will join the senior management team and report into Rometty, who seems to possess every senior management position worth having. IBM has been steadily increasing cloud as a proportion of total revenues and the pressure is now on to take that growth to the next level.

It’s Red Hat, but not as we know it

Software vendor Red Hat is celebrating the launch of Enterprise Linux 8 and the approval of its acquisition by IBM with a change of wardrobe.

As arguably the best known company to be named after an item of clothing, the hat itself is central to Red Hat’s brand and image, so any decision to muck about with it, therefore, is not to be taken lightly. But when incoming CMO Tim Yeaton chatted to people about the logo he was distressed to hear they found the dude wearing the hat to be sinister and even evil.

Showing some of the qualities that presumably lead to his promotion Yeaton quickly concluded that having an ‘evil’ logo was a potential marketing liability and dedicated the next year and a half to resolving the matter in an appropriately open source way. This exhaustive process apparently came to a simple conclusion: ditch the dude, resulting in the dude-less logo you see above.

The evolution of the Red Hat logo coincides with a couple of other pretty significant milestones for the company. Tech giant IBM was recently advised that the US Department of Justice has concluded its review of the Red Hat acquisition and said it’s got no problem with it and as far as the US is concerned this is an unconditional green light. IBM apparently reckons the whole thing will be wrapped up later this year.

Lastly Red Hat recently announced the first major new version of its Enterprise Linux platform – RHEL 8. As a platform designed with datacenters in mind, RHEL is of increasing relevance to telcos as they move ever more of their stuff into the cloud and the edge. Red Hat is positioning RHEL 8 as the platform for the hybrid cloud era and name-dropped lots of other associated buzzwords like containers and devops. We wouldn’t even know which end of the box to open with this stuff, so hopefully this vid as well as some canned quotes will help you understand what the big deal is.

 

Stefanie Chiras, vice president and general manager, Red Hat Enterprise Linux, Red Hat

“Red Hat Enterprise Linux 8 embraces the role of Linux as IT’s innovation engine, crystallizing it into an accessible, trusted and more secure platform. Spanning the entirety of the hybrid cloud, the world’s leading enterprise Linux platform provides a catalyst for IT organizations to do more than simply meet today’s challenges; it gives them the foundation and tools to launch their own future, wherever they want it to be.”

Tibor Incze, technical lead, Red Hat Enterprise Linux, Datacom Systems

“The capacity for Red Hat Enterprise Linux 8 to not only run multiple versions of the same application or database on a specific operating system but to also have a clear and efficient way to manage them is a significant benefit to Datacom and our customers. As we continue to execute on our internal DevOps strategy, we’re also pleased to see improved container capabilities in the operating system and extensive automation, all factors that will help us bring differentiated services to our end users.”

John Gossman, distinguished engineer, Microsoft Azure

“We have seen growth in applications being deployed using Red Hat Enterprise Linux on Azure, including Microsoft SQL Server, for cloud-native, hybrid, and cloud migration scenarios. We’re excited to see what customers will create with Red Hat Enterprise Linux 8 on Azure with continued integrated support from Microsoft and Red Hat, as well as the operating system’s new capabilities to build applications for workloads like AI.”

Arlen Shenkman, executive vice president, Global Business Development and Ecosystems, SAP

“Red Hat Enterprise Linux 8 for SAP Solutions offers high availability capabilities, which are important for SAP workloads, and downtime is unacceptable for business critical applications such as S/4HANA. For more than two decades, we’ve worked with Red Hat on maintaining a stable, open foundation for SAP applications, helping our customers make smarter decisions, faster, across the hybrid cloud.”