I wanted to do a post on different tools used to automate physical and virtual networks. They were going to include BMC Blade Logic Network Automation (BBNA), Cisco Network Services Manager (NSM), and vCloud Director. OpenStack may have found its way in there too. Note: Cisco NSM is the product of the LineSider acquisition.
The post was going to compare what each product calls its network construct. For example, in NSM network containers are defined, but in vCloud, External, Organization, and vApp networks are defined. Other tools refer to networks as domains and PODs. Trying to decipher what the next tool is going to call a basic Layer 2 segment will likely take even more time. Imagine trying to remember all of this?
The post was going to compare what each product calls its network construct. For example, in NSM network containers are defined, but in vCloud, External, Organization, and vApp networks are defined. Other tools refer to networks as domains and PODs. Trying to decipher what the next tool is going to call a basic Layer 2 segment will likely take even more time. Imagine trying to remember all of this?
I found myself wondering, could there be a better way to simplify what we call network constructs and how we define them? Wouldn't that make analyzing and using these tools a bit easier? You can call this DOT 1.
What’s the “dot 1” all about? Rather than focus on comparing various tools, I thought I’d connect the dots that made things click for me around standard northbound APIs, network abstractions, and network consumption models.
Now onto more dots…
DOT 2
Numerous articles on Northbound APIs have been written over the past year or so. I’ve read many and most of them argue why a northbound API is needed in the network industry mainly stating to integrate to applications that reside on top of a controller. Since many don’t think we even need a controller in networking, the point is often missed, but for those who do --- well, what “apps” can you write on top of the network controller? That’s for a different day, but the point is, how do we make the need for a standard API practical and not relate to pie-in-the-sky “apps?”
What’s the “dot 1” all about? Rather than focus on comparing various tools, I thought I’d connect the dots that made things click for me around standard northbound APIs, network abstractions, and network consumption models.
Now onto more dots…
DOT 2
Numerous articles on Northbound APIs have been written over the past year or so. I’ve read many and most of them argue why a northbound API is needed in the network industry mainly stating to integrate to applications that reside on top of a controller. Since many don’t think we even need a controller in networking, the point is often missed, but for those who do --- well, what “apps” can you write on top of the network controller? That’s for a different day, but the point is, how do we make the need for a standard API practical and not relate to pie-in-the-sky “apps?”
BTW, I don’t think they are pie-in-the-sky examples. Just that they are harder to relate to!
DOT 3
A few days ago, Greg Ferro published an article just after the NSX launch. Referring to VMware, Greg writes, “If VMware wants to win network engineers to its side, it might want to try a change in tone.” This has been in my head ever since and I talk to a lot of folks that don’t even know VMware offers network solutions. Is that good or bad? Adding on to Greg’s point, I think vendors selling network automation tools need to do the same thing actually --- change the tone (and message) and empower automation, not the CLI. Network Automation tools should be the norm, not the exception.
DOT 4
Finally, I read an article a few weeks ago by PlumGRID on their blog that talked about how it took consumption models like IaaS, Saas, and PaaS to really bring clarity around what Cloud is. They stated, “Once IaaS, PaaS, SaaS consumption models were well understood, users of infrastructure found a vocabulary; to relate to the concept of cloud; and to describe their needs and solutions within this new paradigm. Consumption models are absent in SDN conversations.” That really got me thinking.
DOT 5
I didn’t want to focus too much on Quantum because it’s not as well known in the Enterprise; so if you aren’t aware, it’s a networking API for OpenStack. This could end up being the foundation of what is needed in the network space. It seems to be on the right path for OpenStack deployments, but we need it to bleed over into the Enterprise market segment.
What do I think?
We have network automation tools and SDN controllers that exist today. Cisco NSM even has what looks like a controller in its overall architecture (this is positive!). This means anything that offers a unified point of integration, if it’s a network domain manager like NSM for automating traditional/legacy network or an SDN controller that already offers its own network abstractions, could essentially be using the same naming conventions for defining network resources. Wouldn't that be sweet? I’m trying to keep things simple, but device level APIs (without a controller) can do the same thing. However, you’ll still end up with a central device managing those API calls, i.e. controller.
We need to define a basic vocabulary for the industry. Who defines that may be PLUMgrid at this point, but we’ll see over time. See their newer posts as they could be trying to set the stage already.
The vocabulary shouldn’t reflect the technology being used like “VLAN,” but rather a virtual network segment. What becomes more difficult are more complex network topologies that include multiple segments, firewalls, and load balancers, right? Maybe, maybe not. Here we need to abstract FWs and Load Balancers into just “network services.” Then we are only dealing with network segments and network services. This post isn’t meant to have the answers on abstractions, but just give an easy example :-). This vocabulary should directly relate to how network resources will be consumed in data center environments.
Once we have a clear understanding of a new vocabulary that can be used to allow us to better leverage network automation tools, SDN controllers, etc. then I think the vendors can begin to standardize on the Northbound API. Most seem to think that standardizing on the NB API could make sense, but how do you standardize until you have clear definitions and clear levels of abstraction?
To keep things simple, how about standardizing on vocabulary before APIs?
I’m not sure why, but connecting those 5 dots made this click a little more for me. Hope it does the same for you.
Thanks,
Jason
Follow me on Twitter: @jedelman8
A few days ago, Greg Ferro published an article just after the NSX launch. Referring to VMware, Greg writes, “If VMware wants to win network engineers to its side, it might want to try a change in tone.” This has been in my head ever since and I talk to a lot of folks that don’t even know VMware offers network solutions. Is that good or bad? Adding on to Greg’s point, I think vendors selling network automation tools need to do the same thing actually --- change the tone (and message) and empower automation, not the CLI. Network Automation tools should be the norm, not the exception.
DOT 4
Finally, I read an article a few weeks ago by PlumGRID on their blog that talked about how it took consumption models like IaaS, Saas, and PaaS to really bring clarity around what Cloud is. They stated, “Once IaaS, PaaS, SaaS consumption models were well understood, users of infrastructure found a vocabulary; to relate to the concept of cloud; and to describe their needs and solutions within this new paradigm. Consumption models are absent in SDN conversations.” That really got me thinking.
DOT 5
I didn’t want to focus too much on Quantum because it’s not as well known in the Enterprise; so if you aren’t aware, it’s a networking API for OpenStack. This could end up being the foundation of what is needed in the network space. It seems to be on the right path for OpenStack deployments, but we need it to bleed over into the Enterprise market segment.
What do I think?
We have network automation tools and SDN controllers that exist today. Cisco NSM even has what looks like a controller in its overall architecture (this is positive!). This means anything that offers a unified point of integration, if it’s a network domain manager like NSM for automating traditional/legacy network or an SDN controller that already offers its own network abstractions, could essentially be using the same naming conventions for defining network resources. Wouldn't that be sweet? I’m trying to keep things simple, but device level APIs (without a controller) can do the same thing. However, you’ll still end up with a central device managing those API calls, i.e. controller.
We need to define a basic vocabulary for the industry. Who defines that may be PLUMgrid at this point, but we’ll see over time. See their newer posts as they could be trying to set the stage already.
The vocabulary shouldn’t reflect the technology being used like “VLAN,” but rather a virtual network segment. What becomes more difficult are more complex network topologies that include multiple segments, firewalls, and load balancers, right? Maybe, maybe not. Here we need to abstract FWs and Load Balancers into just “network services.” Then we are only dealing with network segments and network services. This post isn’t meant to have the answers on abstractions, but just give an easy example :-). This vocabulary should directly relate to how network resources will be consumed in data center environments.
Once we have a clear understanding of a new vocabulary that can be used to allow us to better leverage network automation tools, SDN controllers, etc. then I think the vendors can begin to standardize on the Northbound API. Most seem to think that standardizing on the NB API could make sense, but how do you standardize until you have clear definitions and clear levels of abstraction?
To keep things simple, how about standardizing on vocabulary before APIs?
I’m not sure why, but connecting those 5 dots made this click a little more for me. Hope it does the same for you.
Thanks,
Jason
Follow me on Twitter: @jedelman8
RSS Feed
