Currently in Migration - Jason Edelman's Old Blog
  • Home
  • About
  • Contact

Connecting the Dots - Network APIs, Abstractions, and Consumption Models

3/18/2013

0 Comments

 
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?
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?” 
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

0 Comments



Leave a Reply.

    Author

    Jason Edelman, Founder of Network to Code, focused on training and services for emerging network technologies. CCIE 15394.  VCDX-NV 167.


    Enter your email address:

    Delivered by FeedBurner


    Top Posts

    The Future of Networking and the Network Engineer

    OpenFlow, vPath, and SDN

    Network Virtualization vs. SDN

    Nexus 7000 FAQ

    Possibilities of OpenFlow/SDN Applications 

    Loved, Hated, but Never Ignored #OpenFlow #SDN

    Software Defined Networking: Cisco Domination to Market Education

    OpenFlow, SDN, and Meraki

    CAPWAP and OpenFlow - thinking outside the box

    Introduction to OpenFlow...for Network Engineers


    Categories

    All
    1cloudroad
    2011
    2960
    40gbe
    7000
    Arista
    Aruba
    Big Switch
    Brocade
    Capwap
    Christmas
    Cisco
    Controller
    Data Center
    Dell Force10
    Embrane
    Extreme
    Fex
    Hadoop
    Hp
    Ibm
    Isr G2
    Juniper
    Limited Lifetime Warranty
    Meraki
    Multicast
    N7k
    Nexus
    Nicira
    Ons
    Opendaylight
    Openflow
    Openstack
    Presidio
    Qsfp
    Quick Facts
    Routeflow
    Sdn
    Sdn Ecosystem
    Security
    Ucs


    Archives

    May 2015
    April 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    June 2014
    May 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011


    RSS Feed


    View my profile on LinkedIn
Photo used under Creative Commons from NASA Goddard Photo and Video