A Day in the Life of a Telecom BSS Engineer: Public Cloud, are you there yet?
System Manager, Digital BSS Product Development
System Manager, Digital BSS Product Development
System Manager, Digital BSS Product Development
The benefits of public cloud are well-known and include lower cost, included maintenance, fast deployment, almost unlimited scaling and pay as you go pricing models. This means you can focus on your business and leave the infrastructure management to the professionals. Sounds exciting? Yes, indeed. Running applications and services on public clouds is becoming mainstream and service providers are no exception. Ericsson is transitioning its BSS portfolio to support cloud choices for all its products. As a result, it changes the way we understand and define “Cloud native” criteria for our products and impacts how we design our applications and services, especially how we deliver and deploy them on public clouds. Let’s look at some things you need to consider when moving forward with public cloud.
In public cloud environments the cost of hardware resources, infrastructure components, and maintenance effort are divided between many tenants. Reducing Total Cost of Ownership (TCO) is a major motivation for small and medium size companies to move to cloud. Promising great savings, cloud providers are attracting companies to move toward their cloud services.
In reality, different BSS applications have different requirements in terms of infrastructure resources, distributed architecture, latencies, etc. These must be taken into account along with costs when choosing between public cloud, private cloud, non-cloud (virtualized vs. bare metal) options. And let’s not forget that there are actual costs of running a BSS application on the public cloud and these should be compared to non-cloud variants deployed at customer premises, sooner rather than later, to ensure the promise of savings will be realized. Additional cost may come for many reasons, let’s examine a few of them in more detail.
Cloud infrastructure overhead comprises many parts
Cloud native deployment variants of BSS applications use Kubernetes as the container orchestration platform to deploy and run microservices
All major cloud providers offer Kubernetes-as-a-service, examples are Elastic Kubernetes Service (EKS) on AWS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE). All those services come with their own overhead and maintenance cost.
Choosing a cloud platform and a service provider that is “just right” for your business is one of the most important decisions CSPs must make when starting their cloud journey. You might decide on gradual transformation to public cloud. It is a journey and will not happen at once. You might also decide which applications will be running in cloud and which will stay on-premises/private cloud.
When making the decision Total Cost of Ownership (TCO) is the major consideration, and there are other determining factors too - such as application needs, the range of services supported by the cloud platform, security features, the cost of integration to existing systems that may require hybrid deployments when applications spread across premises and cloud environments.
Cloud tenants retain responsibility for supporting applications
An important point to note is that while cloud providers take full care of infrastructure maintenance, the application services maintenance remains the tenant’s responsibility once the applications reside on public cloud platforms.
With cloud applications, it is essential to build an ecosystem of supporting operation and maintenance (O&M) services to:
- Manage and monitor application workloads, life cycle, security, and data storage
- Detect and resist external attacks
- Collect statistics and run reports.
In traditional non-cloud deployments, the responsibility for deploying and maintaining O&M services is completely on your shoulders. This approach remains the same for private cloud deployments, where BSS solutions now bring their own cloud native variation of O&M services to deploy them on Kubernetes.
In public cloud deployments, many O&M services already available as managed services, pre-integrated with cloud infrastructure and ready for tenants to “pick and mix”.
These supporting services can be deployed at your discretion and according to your specific requirements. You can start with a bare minimum of services needed for the application deployment and then add more services to enhance the infrastructure later.
In this situation, the main challenge for software engineers like us is to analyze how we could leverage public cloud services for our applications, how BSS O&M services would be deployed and interact with the cloud infrastructure and then support such flexible deployments to our customers.
This ecosystem of supporting services is visible in the diagram below.
Figure: Comparing traditional and cloud native BSS deployments
Networking and security tools are readily available
Creating a secured, robust, and highly available cloud environment demands rigor, pragmatism and a balanced approach. And there are many tools that can be used when creating cloud infrastructure to ensure the right levels of security and stability are applied. Load balancers and network policies, built-in geo redundancy and autoscaling of Kubernetes platform, role-based access and VPNs, you name it, cloud providers have all the tools and features (as a service), tenants just need to select and configure them – while ensuring applications support them too.
Security and reliability are two things that BSS engineers take extremely seriously. So even before starting our cloud journey, a group of Ericsson security experts ran multiple studies to ensure Telco industry hardening standards (used to set baselines of system requirements) can be met in cloud environments. The studies resulted in a set of mandatory design rules each Ericsson Digital BSS application must comply with.
My day to day work is as an Ericsson Digital BSS engineer where we follow these rules strictly by:
- Hardening the container images
- Supporting encryption and protection of sensitive data
- Enabling fine-grained access management
- Implementing auditing of user actions and tracing capabilities
- Providing guidance to service delivery teams around how to secure cloud environments for production environments.
“Cloud-ready” is not the same as “cloud-optimized”
Deploying a BSS application on public cloud requires thorough planning and cost calculation, starting with choosing the cloud platform and the cloud services to build the ecosystem, then optimizing compute resources used by the application.
For instance, organizations may achieve initial cost reductions by just moving their applications to cloud, but to optimize the cost to the next level they need to change their applications to follow cloud-native design principles.
Public cloud customers can “pick and mix” the services they need. For more information on cloud choices, decomposition, resiliency, state optimization, openness, orchestration and automation. See blog on The journey to a cloud BSS.
There are four major principles BSS engineers follow to achieve speed and flexibility:
- Splitting monolithic applications into loosely coupled microservices, to deploy, scale and operate them independently
- Packaging microservices as container images and using tools agnostic to the underlying platforms
- Automating deployment and CI/CD pipelines integrations
- Keeping deployments of BSS O&M services (delivered by most BSS applications) flexible to be able to integrate to the cloud infrastructure, defining a rigid set of services might prevent you getting benefits further down the road.
The scalability of cloud reduces resource redundancy
Traditionally, applications on premises must reserve the full hardware capacity to survive peak load. This means that 90% of the time the resources might be underused. Cloud platforms allow for the addition and release of capacity - dynamically, only when you need it, and on a “pay as you go” basis.
In order to take advantage of this cloud capability, when engineering Ericsson Digital BSS products, we ensure that our microservices can scale in and out both vertically (by adjusting size of a single service instance) and horizontally (by starting more service instances during peak load).
Since our first release with cloud support, our development unit works closely with customer projects and service delivery teams to help them dimension and optimize cloud deployments based on the customer traffic model and workload and also to get early feedback on how we can optimize our applications further. Coming back to cost optimization for a moment, cost calculators are useful tools, commonly available as a web service, with a simple interface to estimate probable cost of cloud deployments.
In the next blog post I will cover more specific experiences and learnings from deploying Ericsson Digital BSS applications Catalog Manager and Order Care on AWS public cloud.
Want to know more?
Want to know more about the Charging Function? Download the Ericsson eBrief.
5G charging, cloud and the edge conundrum