NFVaaS - while it sounds like a joke about mixing acronyms between cloud ('x' as a Service) and SDN, NFV is already a serious mix of the two technologies - and I think there's a lot of promise in taking this joke a lot farther.
SDN provides centrally controlled packet steering - a planned path, through specified forwarding engines, between endpoints. Cloud provides orchestrated 'service' deployment, automating the setup of VMs/containers/whatever. NFV mixes the two concepts, to use cloud orchestration to deploy middleboxes into the SDN packet path, so it's possible to steer connections through firewalls, NAT, IDS, DLP, load balancers, caching engines, etc. The key point is that the services are consumed not by users, but by packets/sessions, thus making NFV both into "cloud for networking" and "networking for cloud". For the rest of this post, I'm going to simplify NFV into the concept of "orchestrating network middleboxes".
So how is NFVaaS different from just NFV? The XaaS term implies wrapping something up in a turn-key way so that it's easy to consume. DBaaS gives me an interface to a running database onto which I can apply schema and do some SCRUD, instead of setting up a server and installing software. IaaS gives me virtual bare metal. NFVaaS therefore goes beyond applying middleboxes as part of delivering or munging sessions for some other application - the whole point of NFVaaS is that I want middleboxes through which to push my own packets. If I have a network that needs a firewall, what I have is a problem that could be solved by NFVaaS, deploying a firewall through which I can push my packets.
To put this another way, if my network use is primarily as a client (rather than running a web site, etc.) then the primary service I consume is "access". To add value to that service, I want to add middleboxes, but I want it "cloud-style": usable in minutes, with costs relating to my use rather than acquisition and maintenance. NFV provides the ability for someone to deliver that service to me.
Some technically-minded readers may be asking, "how do you insert something into the packet path?" There are a few different ways, but what I personally prefer is using a VPN. Right now I'm renting a VPS which I use as a VPN concentrator and cloud storage server, with the intention of adding IP blocking based on an open theat intelligence feed. At some point I might add Squid as a transparent proxy running ClamAV. There's a lot I can do to create my own "clean pipe" service, and the value to me greatly exceeds the VPS cost. However, it took me a while to set up what I have, and will take a lot more time to add (and tune) the additional capabilities. If I could get all of this as a service for a reasonable cost, I'd recommend it to all of my non-technical friends and family.
NFV gets a lot of attention in big networks like Service Providers, Data Centers, and Large Enterprise - in short, anyone running their own private clouds - but just because it runs in a cloud doesn't mean that it doesn't have value to everyone else. I'm definitely looking forward to renting time on a IDS.
Friday, November 6, 2015
Thursday, April 2, 2015
Who will own the virtual network?
There are two network virtualization products being pushed by heavyweight vendors. In this corner: VMware NSX. In that corner: Cisco ACI.
The debate is ongoing how to add agility to networking. The overlay model, like NSX, says that the network can be simple as long as the apps are smart. The controller model, like ACI, says that the network should be aware of the apps.
On the overlay side, the strength is in its deployment simplicity: end nodes communicate with each other, but the network itself (the "underlay") doesn't require any adjustment. Its weakness is the flip side: there's no way to tune the underlay, so there's no way around bottlenecks and other potential artifacts of the architecture.
On the controller side, the strength is the potential of the network to adjust to support whatever flow patterns the app requires. There are two weaknesses: first, if the app doesn't integrate with the controller API, then the controller has to interpret the data it's carrying and make a best guess on optimal configuration; second, the "smart" abilities generally require new hardware, which greatly slows down the rate of adoption.
In the short term (1.5-3 years), it's likely that NSX will be deployed much more than ACI. NSX doesn't "technically" require the server team to involve the network team in the roll-out, and the agility that's grown from virtualization into modern devops will lead both to an increased tolerance for risk and a demand for better network delivery. (As a network guy, I'm used to hearing the network always getting blamed for any problem.) The fertile ground will be large applications hosted either classically or in private cloud, especially where the app is multi-tiered (with lots of local east-west traffic), but may grow as NSX support increases across data centers.
The question is whether ACI will take hold, and where. The fertile ground will likely be single-owner data centers with monetized services, where ACI will be seen as an investment to increase capacity, and API integration can be pushed top-down into the hosted systems. However, the Internet Giants (Google, Facebook, etc.) have demonstrated that they're willing to create their own network technology rather than purchase big-ticket vendor products, and analysts and pundits are declaring that everyone else will move to cloud hosting. Even though that prediction is hyperbole, it does put downward pressure on the ACI target markets.
Keep in mind that 3 years ago, the "future of networks" was OpenFlow, so any future predictions that aren't wildly inaccurate will likely be due to blind luck. :-)
What do you think? That's what the comments are for down below.
The debate is ongoing how to add agility to networking. The overlay model, like NSX, says that the network can be simple as long as the apps are smart. The controller model, like ACI, says that the network should be aware of the apps.
On the overlay side, the strength is in its deployment simplicity: end nodes communicate with each other, but the network itself (the "underlay") doesn't require any adjustment. Its weakness is the flip side: there's no way to tune the underlay, so there's no way around bottlenecks and other potential artifacts of the architecture.
On the controller side, the strength is the potential of the network to adjust to support whatever flow patterns the app requires. There are two weaknesses: first, if the app doesn't integrate with the controller API, then the controller has to interpret the data it's carrying and make a best guess on optimal configuration; second, the "smart" abilities generally require new hardware, which greatly slows down the rate of adoption.
In the short term (1.5-3 years), it's likely that NSX will be deployed much more than ACI. NSX doesn't "technically" require the server team to involve the network team in the roll-out, and the agility that's grown from virtualization into modern devops will lead both to an increased tolerance for risk and a demand for better network delivery. (As a network guy, I'm used to hearing the network always getting blamed for any problem.) The fertile ground will be large applications hosted either classically or in private cloud, especially where the app is multi-tiered (with lots of local east-west traffic), but may grow as NSX support increases across data centers.
The question is whether ACI will take hold, and where. The fertile ground will likely be single-owner data centers with monetized services, where ACI will be seen as an investment to increase capacity, and API integration can be pushed top-down into the hosted systems. However, the Internet Giants (Google, Facebook, etc.) have demonstrated that they're willing to create their own network technology rather than purchase big-ticket vendor products, and analysts and pundits are declaring that everyone else will move to cloud hosting. Even though that prediction is hyperbole, it does put downward pressure on the ACI target markets.
Keep in mind that 3 years ago, the "future of networks" was OpenFlow, so any future predictions that aren't wildly inaccurate will likely be due to blind luck. :-)
What do you think? That's what the comments are for down below.
Subscribe to:
Posts (Atom)