Bridging the Cloud Native Gap
Cloud Native is the shiny new toy of the telecom industry. We have vested it with many magical qualities upon which the success of SDN, NFV, and related software modernization initiatives will be based. At least it seemed that way at the SDN-NFV World Congress in The Hague last week, where the term Cloud Native was sprinkled liberally throughout presentations and splashed across participants’ booths.
I had an opportunity to introduce a dose of reality in my own presentation, which in keeping with the theme was entitled a little tongue-in-cheek, Going (Cloud) Native to Revolutionize Telecom Services. I was addressing a room of people in the ‘Automation’ track, and started with this request, “If you are familiar with the term ‘cloud native’, please raise your hand.” Not surprisingly, everyone raised their hand. I then requested, “Keep your hand up only if you were already familiar with the term ‘cloud native’ five years ago.” And then only two people in the audience did so.
So what is Cloud Native? It is a methodology for delivering applications that take advantage of cloud computing architectures and software lifecycle techniques. The architecture uses layers that build on top of each other in a decoupled manner, so that applications (software-as-a-service), run on top of operating systems and middleware (platform-as-a-service), which run on top of computing, storage and networking resources (infrastructure-as-a-service). The applications themselves are composed of highly modular and interchangeable ‘microservices’, which are encapsulated in ‘containers’ to facilitate development, testing, deployment, and ongoing management across different run-time environments. The net result is an agile and efficient way to bring services value to end customers.
But is this true? On the plus side, there is no doubt that using ‘cloud native’ software lifecycle techniques will enable CSPs to develop service and network management applications more quickly. The challenges occur in that these applications are not being deployed in large, uniform, centralized data centers. Rather they need to work and live a highly distributed and differentiated telecommunications network. This requires augmenting the classic ‘cloud native’ approach in at least three ways for CSPs to fully reap the benefits.
1. Strong SDN-NFV Orchestration
Until recently, SDN and NFV have evolved as mostly independent orthogonal technologies, with SDN addressing connectivity in the lower layers of the OSI stack, and NFV providing virtualization for the higher layers. It is now clear that advanced services will need to build service chains that combine SDN connectivity with NFV virtualization. Moreover, this must be optimized over multiple network layers to make most efficient use of network resources.
Strong orchestration brings the connectivity and virtualization worlds together. In a sense it adds a layer above the classical SaaS that continues to allow independent evolution of SDN and NFV based technologies and applications, and brings them together as needed for higher level value.
2. Inter-Service Provider Interfaces
Incredibly, beyond basic voice services, it is still virtually impossible today to stitch together dynamically advanced services like VPNs that span multiple service provider domains. So even if CSPs come up with a state-of-the-art system for agile service delivery within their own domains, it does them no good for enterprises and businesses operating in our global economy which require services spanning multiple CSPs.
The solution must lie in ability for CSPs’ OSS and BSS to communicate with each other autonomously, to setup and mange global services. An important industry initiative aimed at defining and standardizing such interfaces is MEF’s Lifecycle Service orchestration (LSO). This can be conceived as tacking on a horizontal layer to the side of the SaaS, so that applications in different domains can communicate with each other. ECI has already demonstrated the feasibility of this approach working with three CSPs to create a sandbox for engineering multi-continent services.
3. Carrier Grade PaaS
The PaaS layer is exceptionally important sub-system in a cloud native approach, providing abstraction for developing and running applications. It allows developers to focus on value with the peace of mind that the runtime environments will take of themselves. As complex as it is to construct a PaaS for standard data center-based applications, multiple elements must be added to deal with a highly distributed network, with intelligence extending all the way to the network edge.
What is needed is a carrier-grade PaaS. This must build upon all the capabilities of a standard PaaS, such as for spinning applications up and down, with additional capabilities for:
- Scalability, to be deployed from a smart network edge to a SP data center
- Robustness, to deliver application availability/survivability in line with CSP service expectations
- Security, to gate access control and licensing
- Capacity, to be a workhorse to handle and preprocess large amounts of network generated data
In summary, cloud native is an exceptionally powerful approach to achieve service agility and operational efficiency. But CSPs must adopt cloud native with their eyes wide open, and add capabilities to make it work for their distributed network environment.