The telecom network is modernizing with containers, cloud-native
A consensus has developed among telecom operators and their vendor ecosystem that the future of telecom network design and development will be built on the modern programming techniques known as cloud-native.
The older approach of hardware appliances implementing broad telecom functions cannot scale sufficiently, and the promised cloud approach of network function virtualization (NFV) has proved more difficult to implement than all had hoped.
A panel discussion at the SDN NFV World Congress in October last year gives a good sense of the state of telecom and the challenges of cloud-native. We are only now on the doorstep of full 5G networks running on true cloud-native infrastructure.
Traditional telecom networks
Telecom networks are very different from the computer networks IT professionals are familiar with.
These networks use the same OSI 7-layer model as enterprise networks, but the network architecture is complicated and specific to telecom. This shouldn't be surprising, as their physical architecture and applications are so different. The standards body that defines the architecture of 4G and 5G is the 3GPP (3rd Generation Partnership Project; 3rd because the organization was formed to define the 3G architecture known as GSM).
The network functions are defined precisely by the 3GPP in part so that network operators can buy products from different vendors and have them interact properly. In this way, telecom network operators work more like systems integrators than conventional cloud service providers.
The number of such vendors has historically been small, and the huge investments involved in building and buying the complex devices has discouraged new entrants to the market.
A very high premium on reliability leads telecom operators to employ conservative, time-consuming procedures before they make any change to the network. Even small projects often take months.
With existing networks, the capacity and characteristics of the network are static. Ramping up temporary capacity for a special event, like holiday shopping or a sports event, is complicated and expensive.
The needs of 5G
5G networks have requirements that are impractical to meet using legacy network models. Previous networks were built in a hierarchy where the core held most of the compute and storage resources. A 5G network is flattened with compute and storage pushed as close to the service delivery point as possible. 5G spans core to edge.
These networks need to maintain high bandwidth and low latency while having the ability to scale up and down quickly to meet changing needs and should integrate with enterprise Wi-Fi networks. The industry has understood the limitations of its current approach and for almost 10 years has been working to address them.
The plan has been to move networks to a cloud architecture, with the network functions implemented in software using NFV. Because virtual network functions are just software running on conventional servers, allocating a new virtual machine in the cloud to run another instance of the VNF is cheap and quick, compared to working with hardware appliances. The cloud model also allows the operator to allocate new capacity for network communications and applications, both in the network core and at the edge.
In the early part of the last decade, most observers would have assumed that many major networks would be running an all-NFV model by now, but it hasn't worked out that way. The process has been slow, difficult, and expensive.
Part of the problem with the NFV approach is that virtual machines turn out to be relatively expensive as a unit of scale, so planning for capacity can still be tricky. They are relatively slow to instantiate, and it is difficult to keep them fully occupied—not to mention they lack flexibility when it comes to delivering a wide range of services to the enterprise edge.
A new programming model sweeping the cloud development world appears to be a better approach for telecom. Containers are a special kind of lightweight environment that has a namespace and process list isolated from all others. Almost all container development and operations are on Linux, where the base features on which containers are built first appeared. A container consumes far less CPU and memory overhead than a full virtual machine and can be instantiated and deallocated more quickly. Containers can communicate with each other only through well-defined mechanisms.
The industry has learned a lot by trying to implement NFV. Even though NFV can function correctly, in practice, it has proved difficult to achieve the scalability, economic, and agility goals of the model. Containers appear to be a better way to achieve those goals, and their ability to do so is demonstrated in the large Internet clouds.
The isolation of containers from one another has another advantage: Popular programming environments and support libraries sometimes conflict when running on the same operating system instance, but containers prevent this problem. The same is true of VMs, but at a much greater cost in overhead. The classic example is the ability to run different versions of Python or some other programming environment. Therefore, applications that require different Python versions may be run in containers on the same system without the problems that plague many a non-container environment.
As a corollary, developers can tune the container to include only the software it requires. Full VMs inevitably include a great deal of software that performs no service for the application.
Containers encourage software designers to create functions that are simple and stateless. We call these functions microservices, and they are especially well suited to a cloud architecture. This design philosophy tends to make the software more portable and reliable, as well as scalable.
Statelessness is the lack of persistent local data; the container has interfaces that can be called from outside and which may return a result but then exit and stop running. Stateless programs are easier to debug and consume fewer resources. They often have to work with data, though, and the interface of containers with persistent data stores is a complex issue.
One of the big advantages of a stateless app is the data is in a separate place, such as Hewlett Packard Enterprise's Shared Data Environment. So, if you need to change the network function at some point, you don't have to worry about untangling all the subscriber data from a proprietary database—you just swap out the old network function for a new one (or a new version) and point it back to the previous data.
Containers are just one of a group of developments in software and OS design from the past decade, which we can designate as cloud-native. Containers are likely the most consequential of these developments, the "killer app" for all the others.
The components and characteristics of a microservices-based cloud-native architecture include:
- Declarative, generally RESTful APIs, which are used to invoke programs anywhere on the Internet through standard Internet protocols.
- Organization of programming features into well-defined microservices implemented in containers.
- DevOps, which is an approach to software development that integrates programming, testing, delivery, and deployment into a continuous process. Other terms used in this area are continuous development, agile development, continuous integration, and continuous deployment. These methods involve a far greater level of automation than was possible with older technologies. The collective impact of these concepts is that software changes can be written, tested, and deployed quickly. The planning and deployment of a new physical network element at a telco, or even the upgrade of an old one, could easily take nine months or more. With continuous development, testing, and deployment, the telco is able to implement new features and fixes on a frequent basis.
- The benefits of a cloud-native approach do not come directly from using an open source software stack, but it is clear that the use of open source for its major ingredients makes cloud-native more attractive to developers. So cloud-native is, at least, open source-adjacent.
- Orchestration and other methods of automating systems and managing resources are a pervasive characteristic of cloud-native implementations and facilitate the integration of the telco core and enterprise edge.
- Nearly all cloud-native solutions leverage common software components that are in mass deployment, such as:
- Linux, as the operating system
- Docker, for the basic container management
- Kubernetes, for container orchestration
- GitHub, for development and deployment
- With the shift of infrastructure from expensive, niche hardware to the cloud-native architecture and tools being used by developers writing for Amazon's, Microsoft's, and Google's clouds all over the world, telcos will gain access to a large pool of talent.
The Cloud Native Computing Foundation (CNCF) was created by the nonprofit Linux Foundation "to make cloud-native computing ubiquitous." Cloud-native isn't a standard as such, at least not yet, but the CNCF has assumed a coordinating role in the promotion of the development of cloud-native technologies and their use in applications. Many large companies in the industry, including HPE, participate actively in the CNCF.
A more agile network
The 5G network will be based on a service-based architecture (SBA), consisting of software services that advertise themselves and can subscribe to other services. Another goal of 5G is to move from telco-style protocol connections between the network functions to REST APIs and other standard Internet methods. Specific interfaces, defined rigidly in the specification, will no longer constrain network designers. They can connect to new network functions using software methods and tools that are common in cloud development. One example is the replacement of the SS7 (Signaling System 7) and Diameter protocols for call setup and other functions with the Internet HTTP2 standard.
When a part of the network has moved from hardware to cloud-native software, the new flexibility in the system will enable new features in the network functions. Network slicing, for example, allows the telco to create virtual copies of the network with different characteristics. One might, for example, build a different network to deal with the needs of smart meters vs. autonomous driving, given the greatly different needs for bandwidth and latency.
A network with less cost and risk
A software-based telco network, built with cloud-native architecture, has many cost and risk advantages over older designs. The ability to run standard server and network hardware is an obvious one that lowers both development and maintenance costs. The shift from specialized tools and expertise to industry-standard tools and techniques, proved at Internet scale over the course of the past decade, is another.
The nature of the SBA also serves to decrease risk by allowing for fixes and upgrades at a very low level, rather than having to affect critical, very expensive hardware. Because of the flexibility of the network and the use of industry-standard hardware, testing of changes to the network can be done on a continuous basis with automated tools, rather than through advance scheduling of scarce resources.
When will the future be here?
Cloud-native architectures will certainly improve the agility of telecom networks and the user experience at the enterprise edge, but getting there won't be a quick process. The development, and even the implementation of the container telecom network and enterprise orchestration, has already begun. There's a lot of work left to do, but telcos can already begin to deploy "islands" of cloud-native 5G in their networks, in pilot programs for particular cities or enterprises.
The accomplishments of mobile carriers are impressive, and we all rely on them heavily. But their existing methods cannot serve the needs of the future, and everyone knows it. Cloud-native technologies, including DevOps and containers, are the way for telecoms to achieve the agility and scalability that the cloud revolution has brought to IT.
Telecom, containers, cloud-native: Lessons for leaders
- Revolutionary changes in technology are increasingly coming from smarter software.
- Decisions about when to move to new technologies are critical. It is essential to keep evaluating them in terms of your own needs.
- Cloud architectures lend themselves to more efficient methods of computing.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.