In practice, this means that those applications—and the data they create—have to run across multiple locations, while still providing availability in the event that something fails. Any deployment will have to span those locations. For some CSPs, this will involve implementing their applications across multiple data centers that they own and run and make them available as a private cloud deployment. For others, this will involve using public cloud services with applications deployed across multiple availability zones. For other CSPs, this will be a mix of both private and public cloud. Whichever approach the CSP chooses to take, the data for this service still has to function as a single logical unit.

Like all applications, microservices designs create data that must be stored. This includes requests from customers and responses from the application, log data on activity, and the application data itself. Each microservice will create data for storing, and this data will have to be managed over time. The ideal approach for this is to use the same architecture as the applications themselves—so, as you move to cloud-native systems for your applications, you will also have to look at cloud-native data, too.

Cloud-native and open-source approaches

As part of the move to cloud-native, CSPs also have to consider their use of open source. Previously, open source would have made its way into telecom infrastructure to support specific functions. Operating systems like Linux would be used to run applications, but each implementation would be standalone and focused on low-value cost reduction. As OpenRAN gains in importance for building and supporting 5G networks, other open-source tools and platforms are gaining ground, too.

Cloud-native deployments rely on open source to function. Cloud computing services rely on open source for their functionality, while the container orchestration platform Kubernetes, originally developed at Google before it was contributed to the community, is also gaining in importance for CSPs. Companies have the option to deploy the same container images across any location, from edge deployments through to cloud infrastructure, and they will run in the same way.

Kubernetes manages the application infrastructure running and can respond based on conditions. For example, if an individual container stops working, Kubernetes can detect the issue and automatically restart an image. For CSPs, Kubernetes can manage this at scale, so availability is not an issue.

This also makes migration easier and supports the potential demand for edge computing applications over time. Services from AWS like Outposts and Google Cloud Anthos make it simple to deploy cloud services into telecom data center environments based on Kubernetes. With Kubernetes in place, the container images can run wherever the CSP needs them to.

While this takes care of the application side, however, it does not handle the data side. This must be handled using the same model, with data managed alongside the applications that create it. Software containers were originally designed as stateless instances that could be created and then destroyed when they were no longer needed. Data, on the other hand, has to be stateful, as it has to exist over time.

Running data in containers involves managing those stateful images over time. This issue has now been solved using Kubernetes Operators to manage those container images and persist them over time. These stateful containers can then be managed in the same way as the application containers.

This will involve looking at data across multiple potential locations, from edge computing deployments to centralized applications and from single data center locations through to hybrid and multi-cloud approaches. Whatever approach the CSP takes, they must be consistent in how they manage their data over time, and they will have to look at typical concerns like availability and reliability at the scale that they run at.

For CSPs, open-source projects will play a fundamental role in how they design and build their strategies for the future. As telecom companies move to cloud and look at scale, they also want to break up their applications and be independent of any one provider. As CSPs look to cloud-native to refactor their applications, and support their aims for a digital future, they will also increase their reliance on joined-up open-source strategies, particularly around data. Open source can help in this process, from the infrastructure that will host these new digital services and transformation projects through to the supporting elements like databases and data-streaming components.