Showing posts with label unikernel. Show all posts
Showing posts with label unikernel. Show all posts

Wednesday, April 27, 2016

NFV costs expectation gap

I am fresh off from an interesting week in sunny San Jose, at the NFV World Congress, where I chaired the operations stream on the first day.

As usual, it is a week where operators and vendors jostle to show off their progress since last year and highlight the challenges ahead. before I speak about the new and cool developments in terms of stateless VNFs, open source orchestration, containers, kubernetes and unikernels, I felt the need to share some observations regarding diverging expectations from traditional telecoms vendors, VNF vendors, systems integrators and operators.

While a large part of the presentations showed a renewed focus on operations in NFV, a picture started to emerge in my mind in terms of expectations between vendors, systems integrators and operators at the show.

Hardware
Essentially, everyone expects that the hardware bill for a virtualized network will reduce, due to the transition to x86 hardware. While this transition might mean less efficiency in the short term, all players seem to think that it will resolve itself over the next few years. In the meantime, DPDK and SR-IOV are used to address the performance gap between virtualization and traditional appliance, even at the cost of agility. By my estimate, the hardware cost reduction demonstrated by VNF vendors and systems integrators still falls short of operators expectations. Current figure places them around a 30% cost reduction vs. traditional model, whereas operators' expectations hover between 50 to 66%.

Software
This is an area where we see sharp expectations variations between all actors in the value chain.
VNF vendors expect to be able to somehow capture some of the hardware savings and translate them into additional license fees. This thinking is boosted by the need for internal business case to transition from appliance to software, to virtualized and eventually to orchestrated VNF. We are still very early in the market and software licensing models for VNFs are all over the place, in many case simply translated from the appliance model in other cases built from scratch but with little understanding of he value of specific functions in the overall service chain. Increased competition and market entering from non-traditional telco vendors will level the licensing structure over time.

Systems integrators are increasingly looking at VNFs as disposable. Operators tell them that they want to be able to have little dependency on vendors and to replace VNFs and vendors as needed, even running different vendors for the same function in different settings or slices. Systems integrator are buying into the rationale and are privileging their own VNFs, putting emphasis (and price premium) on their NFVI (infrastructure) and VNFM (management). Of course this leads also to the conclusion that while VNFs (and VNF vendors) should be interchangeable, the NFV MANO (management and orchestration) function will be very sticky and will likely stay a single vendor proposition in a given network. As a result, some are predicted the era of orchestrators war, which certainly feels timely, after the SDN management war (winner OpenStack), southbound interface war (winner OpenFlow), hypervisor war winner (KVM)...
I have spoken at length about the danger operators expose themselves if they vacate the orchestration field and leave systems integrators to rule it. It seems to have gained some traction with open source orchestration projects being pushed in standards. In any case, VNF vendors expect a growth in software licensing vs. appliance model, whereas integrators and operators expect a reduction.

Professional services
This is the area where everyone sees to agrees that an increase is inevitable. SDN and NFV provide layers upon layers of abstraction and while standards and open source are not fully defined, there is much integration and "enhancements" necessary to make a service on NFV work.
VNF vendors and operators who do not want to perform integration themselves usually expect a 50% increase vs. appliance projects, whereas integrators budget a robust 100% increase in average. This, of course, increases even further if the integrator is managing the infrastructure / service itself.

Maintenance and support
Vendors and integrators expect the ratio of these to be essentially comparable  to appliance models, whereas operators expect a sharp reduction, in light of all professional services being extended for integration and automation.

Total
VNF vendors behind closed doors will usually admit that, in the short term, the cost of rolling out a new VNF function /service might be a little higher than appliance, due to the performance gap and increase in professional services. There are sharp variations between traditional vendors that are porting their solutions to NFV and new vendors that cloud-native and have designed their solution for a software defined virtualized environment.
Systems integrator can show an overall cost reduction but usually because of proprietary "enhancements and optimization".
All are confident, though that automation and orchestration makes operation of existing services much cheaper and ramping up of new ones much faster. Expectations are that VNF architecture will be much more cost effective than appliance on a 3 to 5 years TCO model. Operators, on their end expect a NFV architecture to yield savings from day one, compared to appliance and to further increase this gap over a 3 years period.

Monday, October 19, 2015

SDN world 2015: unikernels, compromises and orchestrated obsolescence

Last week's Layer123 SDN and OpenFlow World Congress brought its usual slew of announcements and claims.

From my perspective, I have retained a contrasted experience from the show. 

On one hand, it is clear that SDN has now transitioned from proof of concept to commercial trial, if not full commercial deployment and operators are now increasingly understanding the limits of open source initiatives such as OpenStack for carrier-grade deployments. The telling sign is the increasing number of companies specialized in OpenFlow or other protocols high performance hardware based switches.

It feels that Open vSwitch has not hit its stride, notably in term of performance and operators are left with either going open source, cost efficient but not scalable nor performing or compromising with best of breed, hardware-based, hardened switches that offer high performance and scalability but not the agility of software-based implementation yet. What is new, however, is that operators seem ready to compromise for time to market, rather than wait for a possibly more open solution that could -  or not - deliver on its promises.

On the NFV front, I feel that many vendors have been forced to lower their silly claims in term of performance, agility and elasticity. It is quite clear that many of them have been called to prove themselves in operators' labs and have failed to deliver. In many cases, vendors are able to demonstrate agility, through VM porting / positioning using either their VNFM or an orchestrator's integration, they are even, in some cases, able to show some level of elasticity with auto-scaling powered by their own EMS, and many have put out press releases with Gbps or Tbps or millions of simultaneous sessions of capacity...
... but few are able to demonstrate all three at the same time, since their performance achievement has, in many cases been relying on SR-IOV to bypass the hypervisor layer, which ties the VM to the CPU in a manner that makes agility and elasticity extremely difficult to achieve.
Operators, here again, seem bound to compromise between performance or agility if they want to accelerate their time to market.

Operators themselves came in troves to show their progress on the subject, but I felt a distinct change in tone in term of their capacity to effectively get vendors deliver on the promises of the NFV successive white papers. One issue lies flatly on the operators' attitude themselves. Many MNO are displaying unrealistic and naive expectations. They say that they are investing in NFV as a means to attain vendor independence but they are unwilling to perform any integration themselves. It is very unlikely that large Telecom Equipment Manufacturer will willingly help deconstruct their value proposition by offering commoditized, plug-and-play, open interfaced virtualized functions.

SDN and NFV integration is still dirty work. Nothing really performs at line rate without optimization, no agility, flexibility, scalability is really attained without fine tuned integration. Operators won't realize the benefits of the technology if they don't get in on the integration work themselves.

At last, what is still missing from my perspective is a service creation strategy that would make use of a virtualized network. Most network operators still mention service agility and time to market as a key driver, but when asked what they would launch if their network was fully virtualized and elastic today, they quote disappointing early examples such as virtual (!?) VPN, security or broadband on demand... timid translations of existing "services" in a virtualized world. I am not sure most of the MNOs realize their competition is not each other but Google, Netflix, Uber, Facebook and others...
By the time they launch free and unlimited voice, data and messaging services underpinned by advertising or sponsored model, it will be quite late to think of new services, even if the network is fully virtualized. It feels like MNOs are orchestrating their own obsolescence.

At last, the latest buzzwords you must have in your presentation this quarter are:
The pet and cattle analogy, 
SD WAN,
5G

...and if you haven't yet formulated a strategy with respect to containers (Dockers, etc...) don't bother, they're dead and the next big thing are unikernels. This and more in my latest report and workshop on "SDN NFV in wireless networks 2015 / 2016".