Key findings from the webinar on “Getting Your Business Support System (BSS)-on-Cloud Strategy Right”.

The speakers of the webinar: Mr. Ravi Shankar, Head of Product, Network Software at STL, and Mr. Ajay Iyer, Vice President of Platforms R&D at STL.

With technologies like 5G, IoT, WiFi6 and the like, the future of BSS is on the cloud whether it is public, private or hybrid. Putting BSS on the cloud can help in realising a lot of value. This shouldn’t be considered as a migration but as a shift that is going to benefit customers in terms of Total Cost of Ownership (TCO) savings and accelerated time to market.

Knowing the future of technologies is one thing, but getting the strategy right to be prepared for the same is an important aspect to focus on. Customers are at different stages of their cloud journey. It is interesting to note that 35% of those are still at the preliminary stage of analysis, 25% are using public/private cloud deployment and the remaining are in the advanced stage of analysis or using hybrid/ multi-cloud/ multi-edge deployment.

Also, the key challenges faced by each of them in their cloud journey are different. For instance, 44.4% are facing issues with respect to addressing budget vs cost vs technical aspects, 33.3% pointed that dealing with people, platform & process aspects is a challenge, and the remaining faced challenges in choosing the right operating model for excellence and selecting the cloud solution provider and vendor.

Considering the challenges faced by customers, it becomes extremely critical to get the cloud strategy right. A lift-and-shift approach compromises the cloud transformation.

The different aspects that make it necessary to plan the entire transformation are:

1. Teams are not accustomed to behaviour changes to have expertise on a new model
2. Delivery model is not designed for cloud infrastructure
3. The platform’s managed services are not utilised by many applications and hence, development costs and times are high
4. Deployment strategy is not tuned for optimal cloud resource utilisations and hence, results in very high TCOs because of over-provisioning.
5. Troubleshooting becomes difficult when standard practices for logging and monitoring for the cloud are not implemented.

The above factors make it essential to get the entire thought process right. “CSPs have to get only 10% wrong to be 100% lost.”

What is STL’s approach for the right strategy for BSS on cloud?

STL’s approach is broken down into 5 steps:

Set clear expectations

First and foremost, define what success will be – which starts with setting clear expectations. This includes defining exactly what the BSS composition should look like and what products should run in a public cloud or private cloud or a hybrid kind of setup.

Define clear KPIs for the BSS on the cloud

The base of the application is the KPIs. STL uses KPIs across different aspects to ensure seamless delivery of services.

Select the right cloud provider and mode ratio

The next step in BSS on cloud strategy is to select the right cloud provider. When devising this part of the strategy we need to look at our application type to make sure that the service time, end customer experience is guaranteed.

Private clouds are better suited for applications requiring:

• Critical real time sessions (Packet Gateway)
• Low Latency transactions (Online charging)

Public clouds are better suited for applications requiring:

• Opex based investment
• Facing high demand fluctuation
• Redundancy for critical services (DRM)
• Optimised storage footprint for higher economic benefits
• Trials/ Pre-production, UAT environments

Hybrid clouds are better suited for applications:

• That can run stable on private clouds and need scaling only on special occasions. For example: promotions, back up, DR

Edge clouds are better suited for applications:

• That require ultra low latency connectivity needs proximity to the customer is super critical

Next part is about platform selection. These days a cloud native software can go on any of the cloud platforms. But when engineering it properly, we are actually selecting some part of the  platform services from our own stack and some from the public cloud as well. 

Define the architecture with the right vendor

Architecture should be right to enable consistent user experience across configuration, provisioning, operations, administration and management. It is important to keep in mind the operational users of the system that are the daily users of the system.

Principles to follow:

The architecture should be such that it helps in taking advantage of platform built on the public cloud and is continuously updated to exploit innovations. Also, the BSS should support regionalisation in terms of taxation laws, languages, etc.

Devise the right operating model

An operating model is a single glass pane of control. Applications run on the virtualised environment as well as the public cloud the operating model should allow to monitor, manage and operate them seamlessly.

How did STL do this?

STL achieved this by following a CNCF trail map adoption. The 10 points developed were:

1. Containerization – It was the starting point. Docker was taken completely.
2. CI/CD – Initially the CI/CD pipeline was in VNF then it was moved to Kubernetes.
3. Orchestration & Application Definition
   a. Kubernetes
   b. Helm – Moved from Helm V2 to V3.
4. Observability & Analysis – ELK
   a. Prometheus & Grafana – Initially for the OS capabilities but then slowly moved to the application layer as well.
   b. Jaeger & Kiali – For microservices to see complete traceability.
5. Service Proxy, Discovery & Mesh – There for the microservices.
6. Networking & Policy (Advance Use Cases)
7. Distributed Database & Storage- Cloud native databases are made a part.
8. Streaming & Messaging- Choosing based on the load of messaging.
9. Container Registry & Runtime – There are alot of containers aspects so an own cloud native registry was set up.
10. Software Distribution

Way Forward

• Cloud-native storage integrated with applications using ROBIN.io
• Cloud-native networking integrated with applications using FD.io
• Cloud-native runtime security integrated application using FALCON
• Implementing federation of clusters using KubeFed
• Deploying application on Edge using Kube Edge
• Deploying application automation using GitOps with serverless architecture
• Cloud-native AI ML- Deploying machine learning workflow on the cloud using Kube Flow
• Multi Data Centre Automation – using ROBIN.io
• Automated cloud infrastructure management – using ROBIN.io

Conclusion

Shifting BSS on the cloud requires a clear thought process. The strategy deployed should cover training and certification needs of people, management and deployment of open source platforms and at the same time, address the vulnerabilities. Checkpoints should be integrated in the pipeline to ensure every line of code and even the external libraries are free from vulnerabilities. Thus, the success of the transition depends on the infrastructure and monetisation capabilities which will help realise the true value of cloud BSS.

FAQs

Q. What is the expected TCO reduction?

TCO reduction can be expected by going on the cloud in the range 30-50%. But depends on certain factors like:

1. How many workloads you are deploying
2. Whether hybrid or entire public cloud strategy
3. Whether you are going to have a disaster recovery
4. What kind of retention cycles you are looking at
5. What kind of components in your BSS support auto-scaling and auto-healing

Overall depends on which kind of applications you are putting on the public cloud.

Q. How important is it to have a standardised portfolio when you move to the cloud?

Fundamentally this is the most critical aspect when we talk about public cloud because in public cloud, it is about having the same software base and continuously updating it as and when it is coming from the vendor. The standardisation allows us to do multiple things:

1. Faster integration
2. Faster updates
3. Faster value creation

For TCO and faster time to market aspects the core needs to be standardised and the rest of the aspects need to be API driven.