THE HAGUE, Netherlands — A BT researcher who has been toying with containers for network functions virtualization (NFV) is finding the technology works as advertised.

"What we've seen so far are very positive results in terms of resource use, in terms of fast spinup times, and in terms of portability," said Louise Krug, a BT senior researcher for network infrastructure and innovation, in a session yesterday at the SDN World Congress.

She described two real-world NFV examples she's been studying. One was very specific, involving a large customer with branches all over the UK and a physical router in each branch. Because the routers are consistently underutilized, it's tempting to replace them with virtual routers, but that wouldn't be practical, Krug said.

"We found that to run this service on virtual routers in the cloud would take a terabyte of RAM to support 500 virtual routers," she said. It wouldn't be cheap. Containers, which could be created at the moment they're needed, could be an alternative.

The other scenario she discussed was an Internet of Things (IoT) gateway, where one container could send data to the cloud for analysis (think temperature or humidity kinds of data), while another container could be used as a firewall.

One question here is what happens when another edge device starts hogging bandwidth. Theoretically, containers should be isolated enough to not directly affect one another, and it should be possible to introduce a traffic-cop container to control the situation. Krug's dabbling so far has shown that memory and CPU performance can remain stable in these cases.

One potential drawback to containers is their networking, which is based on overlays.

"If we have overlays on overlays on overlays, we get inefficient use of bandwidth. That might not be a problem in the data center, but it certainly could be a problem in the wide-area network," Krug said.

Krug also warned about containers losing their "resource advantage." If you insist on guaranteeing a certain level of performance between containers, and if you build all containers to handle the maximum possible load, "suddenly the containers can end up taking as much resource as the virtual machine did," she said.

A microservices approach would help with resource utilization, since it would break applications down into smaller containers. But microservices could also cause a bit of angst.

"The vendors get scared we're just going to cherry-pick and buy one or two bits; the operators get scared there's going to be so much interprocess communication that everything's going to fall down," she said.