Prepping for the CCDE: The Scalability and Flexibility Domains

18 July 2012 by 4 Comments

What comes to mind when you hear the word “scalability?” If you’re an old timer, like me, you might think about several hundred neighbors on a hub and spoke frame relay network… Like I said, if you’re an old timer. For newbies, thoughts might turn to a data center with 100,000 servers. Either way, scale turns our thoughts to “big,” as in a lot of devices, a lot of users, a lot of links, a lot of interfaces… For the CCDE, that’s just what we want to avoid, because scale isn’t just about thinking big, it’s also about thinking small.

Scaling isn’t about how to make the network big, it’s about how to right size the network to solve the problem at hand. It’s about choosing the right amount of equipment, the right technologies, and the right configuration to build the most compact network that will solve the business problem. In the language of modern data centers supporting cloud, “build it just good enough, and no better.”

Scaling, of course, goes hand in hand with flexibility. Flexibility can simply be defined as the ability to rapidly scale a network to fit the business requirements.

Maybe an example would help. Suppose you’re designing a data center (does anyone actually build anything other than data centers any longer?) to support 100,000 servers. The first thing you should probably ask is: does the business requirement indicate 100,000 physical servers, or 100,000 servers? Are they thinking processing horsepower, or simply having that many devices available for processes to run on? The difference could be huge, of course, but a lot of the business folks don’t understand the difference between the two concepts.

In the process of asking questions, you discover the business problem can be solved using 100,000 virtual machines, and the horsepower requirements really only indicate about 10,000 physical servers. You’ve gone behind the “on the surface” requirements to figure out what the real business requirements are, giving you a better idea of how to scale.

But the next question you should ask is: how quickly will these business requirements change? Is it possible for processing load to double on short notice? Is it possible for it to halve? How will the answers to these questions impact your design? Consider this interesting correlation: is layer 2 to the edge more flexible than layer 3 to the edge? Or the other way around? What about how you plan the core of the data center? Is it designed just for connecting to users, or have you thought about where you might attach DC interconnections to handle future growth? Should there be a “backend” connection to allow cloud services to be integrated, so users don’t have to interact with those services directly?

All of this thinking is either explicit or implicit in each CCDE design scenario. Don’t just read the surface requirements and jump to a conclusion; every business requirement must be taken into consideration, every avenue explored.

Scaling isn’t just big, it’s right, and it’s flexible.

Filed Under: Blogs, Certification Tagged With: , , ,
About Russ White

Russ White is a Network Architect who's currently looking for a new challenge. He's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. If you want letters, well... BSIT/MSIT (Capella University), CCIE #2635, CCDE 2007:001, CCAr. So there.

  • http://twitter.com/icemarkom Marko Milivojevic

    Fantastic article, Russ. People sometimes forget what “scalable” should mean!

    Unfortunately, the first to forget the meaning of the word are the vendors, who spend way too much emphasis on “large” versus “right”.

  • ktokash

    By the end of the second paragraph the words, “shifting sands of requirements” popped unbidden to my furrowed brow. Glad you covered it, as well as the fact that the network designer needs to pepper everyone with questions to dig out the requirements, though in my experience half the time the answer ranges from a wild guess to an explicit admission of ignorance. I suspect it’s a quiet maxim to overbuild, supported implicitly by upstream purse string holders who don’t want the build to fail and have it trace back to their not having spec’d it large enough.

    • riw777

      I think you’ve hit one of the biggest problems with IT in general –the shifting sands of requirements. The problem is that we seem to get into this whole mode of “isn’t this all virtual stuff?” and forget there actually have to be cables and boxes and people and…

      I suspect you’re right about one reason why people overbuild –it’s better to be quietly wrong on the overbuilt side than spectacularly wrong on the underbuilt side. But this brings up another reason –for all the hype, network vendors just don’t build equipment that’s truly flexible on the field side of things. We’re been trying for years –stackables, variously sized chassis, etc.– but it just doesn’t seem like we’ve found a solution to that problem yet on the hardware side of things.

  • http://www.facebook.com/profile.php?id=1308904376 Mustafa Bayramov

    and at the you are alone with assumption :)