The Upside Of The Software-Defined Datacenter

  • Rating: 
    0 votes
    Vote up!
    Vote down!

Ivan Pepelnjak explains one of the benefits of a well crafted datacenter network.


Who cares?

This is a pretty bold observation from Ivan -- you need to be awfully confident in your design to stop worrying about how it's performing. Raise your hand if you can say that you don't care how the workloads in your data center network perform. Bueller...Bueller?

Bold Statement

Wow. That's a pretty bold statement, but I think it makes sense. Bascially, Ivan is saying that if you do everything right with your software defined datacenter design, you have nothing to worry about. I'm not so sure about that. There's always something to worry about.

And, the hardware?

Ivan. Obviously the software is the key, but to strike this type of balance with every node getting the same performance, how much work has to be done on the hardware side to lay the foundation?

Re: And, the hardware?

Good questions @James, infact there is curiosity between management segement people to understand SDN decoupling hardware from software.

Wait, What?

So yes, but this isn't just an upside of SDDC, although it's an easy to do when the bulk of your traffic is handily IP encapsulated in an overlay protocol.

Leaf/Spine as an architecture running, say, TRILL (FabricPath for you Cisco fans out there) or Shortest Path Bridging (SPB) also supports regular non-overlay networking for the exact same reasons that Ivan lays out - multiple, equidistant paths between every node, at layer 2. 

In other words, I agree that if you are running overlays, there's a lot of sense in building a highly scalable L3 fabric (like L/S). On the other hand, if you aren't running overlays, or you have a lot of traffic that isn't encapsulated, you can still benefit in a non-SDDC by running a smarter fabric protocol that does (please forgive me) layer 2 routing.



Re: Wait, What?

Absolutely agree with you, but I'd still go with overlay virtual networks - they reduce the size of the failure- and flooding domain, number of moving parts, and offer nice isolation between physical and virtual worlds.

Re: Wait, What?

One application of SDN is the IaaS, but how do we see SDN is managed network services.

Yes, but where's the complexity in that approach?

Dare I say it, but it looks as though Juniper got it right the first time with QFabric, only gawd knows what Cisco were playing at first with FabricPath, then DFA and now ACI.

Re: Yes, but where's the complexity in that approach?


Cisco are certainly testing out a number of different solutions before, presumably, iterating their way to the one true way, aren't they?

As for Juniper getting it right with QFabric, the only thing they really got wrong in some respects was announcing it so very far in advance of having a deployable solution. That wasn't so much a shot in the foot as an axe blow at the top of the leg. How do you recover from that? Oh, I also suspect that trying to present it like it's magic, and not giving an explanation up front on how it achieved what it achieved was also a bad idea. Geeks don't like magic black boxes that do stuff through mystery methods.


Re: Yes, but where's the complexity in that approach?

We have similar kind of approach in new security environment that SDSec, any reviews on same.

Re: Yes, but where's the complexity in that approach?

We've heard them all the last 18 months, the facts are which ever way you look at it, it's all defined in software one way or the other, the Cloud Security Alliance are referring to it as the Software Defined Perimeter.

Re: Yes, but where's the complexity in that approach?

First of all, I'd like to hand out a software defined slap to the CSA for creating yet another SDA (Software Defined Acronym).

That aside, the CSA's SDP proposal seems to address one very specific - if useful - scenario. From the document you linked (and thank you, it was an interesting read):

SDPs require endpoints to authenticate and be authorized first before obtaining network access to protected servers, and then, encrypted connections are created in real time between requesting systems and application infrastructure.


That's not quite the same as generic edge security to me. If I undersand correctly, SDP would not address anything other than a subset of connectivity between known hosts that are privileged / pre-authorized. It would probably do that very well, but whether it's any use will depend heavily on the usage patterns for a given data center.

And yes, as you suggest, it's all software one way or another, and has been for a long time :) 


Re: Yes, but where's the complexity in that approach?

"Sofware-defined slap" -- priceless! I agree, there are way too many software-defined acronyms. When a security vendor touted "software-defined protection" earlier this year, I really lost patience.

Re: Yes, but where's the complexity in that approach?

Heh. The danger is that the words "Software Defined" - if they have not already - become completely meaningless. SD-Washing is already joining the ranks of Cloud-washing and similar because the marketing wonks think they need the sticker on the box...