We are in the middle of an industry-wide shift from self-hosted OSS/BSS to cloud-native services. The main driving force behind this change is the need for agility and innovation, with cost considerations as a strong second reason. This is more than a change of hosting. Cloud-native OSS/BSS will come with a breakdown of the monolithic applications that have been used in the past. In their place will come independent components and microservices, which are more easily updated and augmented.
Goals of the cloud shift
In upgrading to cloud-native OSS/BSS, CSPs expect to accomplish a number of goals:
- More cost-effective use of computing resources.
- Increased automation of service operations.
- Bringing the latest IT practices to network operations.
- Reducing the need for custom code.
- Vendor-neutral service management.
- Adoption of standards in APIs and software architecture.
Staying on legacy systems is no longer a viable option, and cloud software is the best way to achieve these ends.
The transition process
A telecom’s self-hosted OSS and BSS are massive bodies of software, tailored to the company’s particular needs. This is at once the reason why they are increasingly inadequate and why they are difficult to escape from. They are essential for the day-to-day operation and require specialized skills. Disruptions in service aren’t acceptable.
Intermediate steps can facilitate the transition. The first step is often to create a wrapper for existing components, using a standardized API and clean separation of functionality. This makes it easier to replace components at a later date, either with an improved version of the same software or something completely new.
Using these components requires refactoring the existing software so that parts of it can be broken out. It’s too common in legacy code for everything to depend on everything else, so nothing can safely be changed in isolation. A code clean-up is often a necessary prelude to the transition, and it can be a massive project.
While everyone recognizes the value and even the necessity of moving to cloud services, the details remain difficult. A CSP can’t risk interruptions in service while upgrading. The upgrade process has to include a rollback capability so that the previous state can be immediately restored if anything breaks.
Cloud-native software takes advantage of a technique called containerization. A container is an environment for software that provides for all its dependencies and can be replicated without limit. When there is a spike in demand, the operating environment creates more containers. They can be deployed on one machine or as many machines as are available. When usage drops off, the excess containers are terminated. This is a cost-effective way to provide elasticity. The computing equipment for a physical data center has a certain capacity; when it gets too many requests at once, its performance falls off, sometimes drastically. Acquiring more hardware to meet peak requirements is expensive, and the capacity is unused most of the time. Containerized cloud-native services handle spikes in demand more gracefully.
The Symphonica approach
With the coming of 5G and the growing range of available services, a prime area for cloud upgrading is service activation, provisioning, and management. Symphonica provides the features that make a transition to cloud-native service activation easier. It’s not a legacy port; it’s designed from the ground up to follow the principles of cloud architecture. Symphonica uses TM Forum APIs to allow straightforward integration. It can work with virtually any service from any vendor.
Symphonica’s features include service inventory management, closed-loop automation for quickly addressing service issues, and a no-code platform for developing orchestration processes.
Contact us to schedule a Symphonica demo.