What’s the Right Unit of Network Abstraction?

Do you recall a lot of talk a year or two ago about SDN or perhaps OpenFlow and finding the right level of abstraction? What ever happened to that? Did we all conclude that flows were it? Because if so, I’m left a bit puzzled. There’s an awful lot of flows in a datacenter. Is abstraction about more detail? I suppose it is in the sense of small atomic components. What I’m puzzled about is, I thought abstraction would be a larger entity (e.g. server as a VM), hiding a lot of the detail.

I’m not knocking where OpenFlow has been exploring, I think there’s some nifty ideas hatching there. It’s just going to take time for them to come to fruition. Among other things, time to develop good GUI plus hardware products with right price point, before becoming mainstream. See my freshly posted blog, at A Radical Take on SDN. I’m assuming good GUI will happen faster than developing critical mass of programmers with Puppet + networking skills. But in the meantime, the goalposts are going to move. (Compressed theme for a future blog idea there?)

Maybe its me. I see the enemy as Too Much Detail. Too much detail I don’t care about. I want to assign properties, like a Nexus port profile. I don’t really care what the VLAN number is. In fact, I’d prefer to deal with ports as little as possible. When your shop has 10-20 thousand active ports, you can chew up a lot of time doing things one port at a time! Port profiles provide a little abstraction, which helps. A VMware dvSwitch is similar in a templating sense: it lets you apply consistent settings across hypervisor hosts.

Now here’s the curveball. What if I tell you that I think VMware and Cisco have both been exploring a different abstraction, maybe not in so many words?

VMware

With VMware vShield Edge as I understand it, you can define and in effect clone a group of VMs with edge firewall, NAT, IPsec, server load balancer. VMware has been further exploiting that capability with vCloud Suite and vSphere Orchestrator.

Here are some relevant links (of various ages):

The key thing to note here is the level of abstraction: datacenter, compute, network, storage. And the marketing: “easy!” (Cf. “easy” in my prior blog, and above).

I’ll give VMware credit for noticing that if I have an abstract group of VMs networked together, the only thing that has external impact is the public-facing address(es) of the services offered. This has been true for a while for those using Server Load Balancers, it’s just we didn’t have an easy way to clone physical hardware, so we never noticed what that did for us.

So to me, that’s successful abstraction. Since I don’t care about the VLAN tags behind a router, and I don’t even care about the private IP addresses behind a NAT point (firewall or Server Load Balancer), those become details I don’t have to sweat (in principle). And that’s what I’m using as a measure of a successful abstraction.

Cisco

Think about vBlock, or FlexPod, or you can do the same sort of thing with Nimble Storage now too. It’s a predefined topology. It means I don’t get to design a customer datacenter, which is my idea of fun (darn)! But it saves customers the cost of me doing that. And it standardizes things, making support and validation a lot easier. I get it. Good stuff.

Is vBlock (etc.) the physical analog of a vApp pod built using vShield Edge / vCloud Director? Let’s pursue that thought a little…

The acquisition Cloupia was just renamed Cisco UCS Director. Which seems like a bit too much emphasis on UCS in the name. It provides orchestration for vBlock, FlexPod, and VSPEX.

See also http://www.cisco.com/en/US/prod/collateral/ps10265/ps13050/ciscocloupia_so.pdf

It reportedly provides automated configuration of … a physical instance of a datacenter. I haven’t driven it so I can’t comment on whether one has to specify VLANs, subnets, and all the details.

Where I take this is that it sounds like a step in the right direction, larger units of abstraction. The other take-away for me is pre-defined architecture, something you also see Cisco doing with the DFA announcements recently. Spine and leaf, automate. What I like about that is that those who talk about arbitrary topologies are biting off a complex problem, which may consume a lot of programming resources and create internal complexity. Sticking to a pre-defined physical topology might eventually constrain sales (at least, to those who don’t see which way the wind is blowing and build it their own way). But it may also free the programmers to focus more on what matters, automation and abstraction and simplicity for the customer.

Dynamic Fabric Automation: http://www.cisco.com/en/US/solutions/ns340/ns517/ns224/ns945/dynamic_fabric_automation.html

Other Levels of Abstraction

I used to be a top-down bottom-up programmer. The bottom-up part: I aggregated functionality (abstracting if you will) from the bottom up when there was code doing similar things with differing parameters. The top-down part was more dividing the problem into manageable chunks. Usually the two met in the middle somewhat.

Maybe the same applies here. Maybe we need to abstract various kinds of server / application pods. As in “N servers (or VMs) light on resources, server load balancer and firewall in front”. Maybe items like the VLAN numbers to use are in effect parameters with default values. Maybe a more finely grained abstraction level there is the notion of a “server, light”, also SLB, also firewall, and the network abstraction aggregates them. This is starting to sound a bit like OpenStack to me. Compute, network, storage resources, oh my! So maybe I’m not onto anything new, just stuff  nobody’s talking about much. Concept internalized, move on.

Come to think of it, Cisco UCS abstracts a physical server, and that’s one of the components handled in an aggregated way with vBlock, etc.

Conclusion

And now we’ve come back full circle, to my prior blog. GUI, simple, automated, etc.

Is this an elephant in the room that everyone’s been ignoring? Or have we all been taking it for granted? Am I onto something here, or making a big fuss about nothing? Belaboring the obvious?

Your comments would be appreciated! Just be polite.

Life Log

I haven’t been appointed apologist for Cisco. I do get the impression the press has been missing some aspects of things that might explain why Cisco is approaching SDN etc. the way it  is. So I’m throwing this out there to see what you all think.

Disclosure

The vendors for Network Field Day 5 (#NFD5) paid for my travel expenses and perhaps small items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention!

Stay tuned!

Twitter: @pjwelcher