How cloud native is enabling STL to ‘build once and run anywhere’ to supply telecom operators worldwide
Challenge
Sterlite Technologies Ltd. (STL) builds and delivers operations support systems (OSS), business support systems (BSS), digital commerce, wifi, and other network software for telecom operators across the globe. Products have to be customized and configured according to customer needs and deployed on customer infrastructure, which range from bare metal and VMs to private and public clouds. This resulted in a delivery cycle of 15-18 months and deployment time of 3-5 days. “We wanted to pursue a ‘build once and run anywhere’ theme, with no dependency of underlying infrastructure, to achieve web scale and cloud native capabilities and reach outcomes faster,” says Ajay Iyer, VP – Platform R&D at STL.
Solution
STL was already using Docker containers, and after evaluating multiple platforms, decided to go with Kubernetes for orchestration, “primarily for its impeccable community support,” says Iyer. The platform team started transforming standard web applications to cloud native and network grade applications to CNFs (cloud native network functions) on Kubernetes in mid-2018. The following year, an organization-wide program was rolled out to modernize all products with web-scale and cloud native principals and onboard them on the Kubernetes platform.
Impact
Kubernetes helped thoroughly modernize STL’s products portfolio. “We are able to make overall deliveries faster by 70%, reduce deployment times from 2-4 days to a couple of hours, depending on the size of the production environment, with complete automation,” says Iyer. “The development teams working on these modern technologies are now really enthusiastic to take it to the next levels of microservices and CNFs.”
By the numbers
Delivery cycle
Went from 18 months to 6 months
Deployment time
Decreased from 3-5 days to a couple of hours
Overall deliveries
Now 70% faster
Based in India, Sterlite Technologies Ltd. (STL) builds and delivers operations support systems (OSS), business support systems (BSS), digital commerce, wifi, and other software for telecom operators across the globe.
With customers in more than 150 countries, “our products are customized and configured according to customer needs and deployed on customer infrastructure, which range from bare metal, hypervisor-based virtualization, and OpenStack private cloud to the increased adoption of public cloud platforms in recent times,” says Ajay Iyer, VP – Platform R&D at STL. “This meant a delivery cycle in the range of 15-18 months and deployment time of 3-5 days.”
And for STL, that wasn’t nearly good enough. Says Iyer: “We wanted to pursue a ‘build once and run anywhere’ theme, with no dependency of underlying infrastructure, to achieve web scale and cloud native capabilities and reach outcomes faster. Today, the demand for and adoption of cloud native solutions is increasing exponentially globally in the telecom industry, so we wanted to cater to this demand and stay competitive.”
The team believed that with features such as autoscaling, self-healing, and automated rollouts and rollbacks, Kubernetes orchestration could achieve that for STL. The company was already using Docker containers, and after evaluating multiple platforms, decided to go with Kubernetes, “primarily for its impeccable community support,” says Iyer.
The platform team started transforming standard telecom enterprise applications to cloud native and network grade applications to CNFs (cloud native network functions) on Kubernetes in mid-2018. STL’s cloud native stack also includes ELK; Ambassador API gateway; Prometheus and Grafana, which are used as the default monitoring system for capturing application KPIs, underlying system, and OS monitoring and usage detail tracking; Envoy and Jaeger as a service proxy layer for the company’s microservices-based solutions; and Helm, which is STL’s de-facto package manager for all application deliverables including new version releases and patch releases.
In 2019, an organization-wide program was rolled out to modernize all products with web-scale and cloud native principals and onboard them on the Kubernetes platform.
For good reason. Kubernetes helped thoroughly modernize STL’s products portfolio, says Iyer: “With web-scale and cloud native capabilities, clear segregation of infrastructure and application layer, auto-scaling, self-healing and automated single-touch application version, and patch rollouts and rollbacks, we are able to make overall deliveries faster by 70%, reduce deployment times from 3-5 days to a couple of hours, depending on the size of the production environment, with complete automation.” The delivery cycle has now been decreased to 6 months.
“With Kubernetes adoption, the number of issues has reduced significantly, errors are now caught in early phases of testing, and there is no need for conducting different testing cycles for different infrastructure environments, which ultimately made the time to market much faster.”
— AJAY IYER, VP – PLATFORM R&D AT STL
Additionally, Kubernetes helped STL meet one of its major operational goals: to ensure applications availability for telecom customers, for whom the norm is to have 99.999 uptime, whether there’s a sudden surge in incoming traffic due to the launch of a new plan, the monthly bill generation cycle that requires high compute resources, or a new patch or a full version rollout.
Multitenancy and a clear segregation in deployment of applications, Iyer notes, have also made it easier to operate each application separately, thus increasing operations efficiency many times over. “Our long-term operational goal is to increase the efficiency level from the existing multiple engineers managing one production environment to one engineer managing multiple production environments, and Kubernetes will be the center of it,” he adds.
Perhaps most importantly, STL has been able to achieve its goal of portability. “Containerization and Kubernetes orchestration enabled infrastructure-agnostic applications that are built once and can be deployed on any kind of underlying infrastructure—be it bare metal, virtualized infrastructure, private cloud or public clouds—and all this without having to worry about code changes,” says Iyer. “The application is delivered along with all other dependencies and configurations, as part of one pre-packaged certified image.”
“With its exponential adoption rate and rapid development and integration with other projects, Kubernetes has the full potential to become the new Linux and a de-facto platform for running all kinds of workloads, applications, databases, and network and storage layers.”
— AJAY IYER, VP – PLATFORM R&D AT STL
The team has found that with Kubernetes adoption, the number of issues has reduced significantly. “Errors are now caught in early phases of testing, and there is no need for conducting different testing cycles for different infrastructure environments, which ultimately made the time to market much faster,” says Iyer. Not surprisingly, “the development teams working on these modern technologies are now really enthusiastic to take it to the next levels of microservices and CNFs.”
Ultimately, cloud native plays a large role in STL’s overall strategy of future-proofing its technology stack. “The most significant aspect of adopting the Kubernetes ecosystem is ensuring future readiness, be it becoming cloud native, enhancing existing DevOps capabilities, adopting microservice architecture, rolling out CNFs, and becoming ready for the 5G era and edge computing,” says Iyer.
And there’s more to come. For example, the team is currently evaluating KubeVirt and KubeEdge. “With KubeVirt, we plan to replace the entire virtualization layer and underlying infrastructure and making Kubernetes the single cloud platform for running containerized and VM-based workloads,” says Iyer. “With its exponential adoption rate and rapid development and integration with other projects, Kubernetes has the full potential to become the new Linux and a de-facto platform for running all kinds of workloads, applications, databases, and network and storage layers.”