Summary Bullets:
-
David Snow – Principal Analyst, IP Services Infrastructure ‘Stateless operation’ is the result of taking all the state (or session) data out of an application and relocating it into some form of ‘shared data entity’ to enable easier VNF scaling, failover, upgrade and so on.
- With at least three different approaches emerging, VNF data management may prove as much of a hindrance to NFV rollout as NFV MANO.
In a previous Network Matter blog post, we identified how ‘cloud native’ terminology is now being used to highlight the differences between simply converting existing physical network function-based software into VNFs and creating VNFs ‘designed for the cloud’ from the start. In “Microservices: How ‘Cloud Native’ Are Network Vendors Today?”, we looked at some of the unanswered questions around microservices. This blog takes the cloud native discussion a little further by discussing the issues around ‘stateless operation.’
Stateless operation is usually described as the result of taking all the state (or session) data out of an application and relocating it into some form of ‘shared data entity’ to enable easier VNF scaling, failover, upgrade and so on. That idea isn’t new and has been a feature of high-availability software architectures for many years. What is new is that this shared data entity is taking on a far greater responsibility than its forebears, including all mission-critical data that a VNF needs to preserve in a highly dynamic NFV environment. The shared data entity must constantly guarantee the read/write access times and the integrity of every instance of every VNF’s data, wherever that instance is spun up or terminated, such as in a centralized or distributed data center or both.
That’s a very tall order, and it gets even taller when the stringent latency requirements of 5G are applied.
So, it’s not surprising that there’s a debate going on as to the way in which the new shared data entity will be implemented. From a Current Analysis perspective, we see at least three emerging vendor approaches:
- Major telecommunications equipment manufacturers, like Nokia and Huawei, see the shared data entity as an evolution of their subscriber data management technology.
- Cloud management platform players, such as RIFT.io and Red Hat, expect their virtual infrastructure manager (VIM) offerings to provide distributed data management support for their hosted VNFs.
- IT companies, particularly those coming from a service-oriented architecture (SOA) background, don’t necessarily buy into the shared data entity concept at all. Oracle, for example, sees each microservice as containing, and responsible for, its own individual data store.
As usual, each vendor’s approach reflects its own market origins, and with NFV being a confluence of all three streams, that is to be expected. Nevertheless, from the perspective of a forward-looking independent VNF vendor, harmonization will be required to avoid the need for developing multiple VNF variants. Where will this harmonization come from? In the past, it has been standardization bodies such as 3GPP and ETSI, but in the new world of NFV, it may be operator and open source communities as in the NFV management and network orchestration (MANO) domain. In fact, while MANO is often cited as today’s multi-vendor NFV roadblock, it could well be masking the challenge of multi-vendor VNF data management. It would certainly be good for the whole NFV ecosystem if both issues were addressed and settled together.