Data Centre Networking - ‘Butterfly Effects’

If you’ve seen the Hollywood film ‘The Butterfly Effect’ you’ll perhaps recall that even the smallest of decisions made in the past can sometimes lead to unwanted consequences in the future.

Paying attention to decisions being made in the data centre network are more important now than at any time in perhaps the last 15 years.  For guys more concerned with applications and server platforms, the DC LAN has often been regarded as mere plumbing, and is usually someone else’s concern to make sure it’s working as needed, or else it’s just something that gets delivered with the rest of the package from your compute vendor.  Yet right now, networking in the data centre is going through a period of transformation, and any decisions being made today concerning the choice of DC LAN vendor, or architecture, could significantly impact the shape of your entire data centre for the next 10 years.

Network Virtualisation

Over the last few years we’ve seen the over-whelming case for virtualising compute platforms and storage, not only optimizing the usage of these expensive assets, but heralding a new age of automation and operational efficiencies. The process of deploying new applications and servers that used to take days, with the tools available to server administrators can now take just minutes or even seconds. Yet so far the network has been somewhat left behind in the dark ages, creating a bottleneck in this workflow.  Network admins still need to follow a largely manual process to provide access to the rest of the system, which can add days, or sometimes even weeks, before the new server can start to be utilised.  

Over the last year we’ve seen both software defined networking (SDN) and the virtualized (or ‘Overlay’) network arrive with promises to change this forever. Their promise is that once your network is virtualized and controlled by software, then all these network admin processes can also be automated and so also completed in seconds. That promise may well be true, but there are a few things that will need to work together first. 

Ask your vendor some challenging questions

Will your orchestration system work seamlessly with your network (SDN) controller?  What happens to all the systems that you can’t virtualize and will need to be kept running on bare metal servers? How will they talk to the systems on the newly virtualised network?  And please don’t forget that with all this talk about SDN and network abstraction you are still going to need a high performance hardware based network with connections in the physical world to connect between the physical compute platforms on which all this virtualization is taking place.  So how will you trouble shoot between the abstracted virtualized network world and the physical network it’s going to be running across? What happens if you want to run more than one virtualized environment how will they interconnect?    

This type of mix of challenging questions is not unusual as a new technology arrives, often creating more questions than it answers. Business pressures can need decisions to be made now, and you won’t get given the luxury of time to wait to see how this all plays out. Besides, by taking the right steps now, you can give your business an early advantage in today’s increasingly competitive market. One approach to moving forward that looks quite attractive on the surface, could be to simply place all your trust in a single vendor to build you a closed system and hope they can pull everything together. They’ll promise things like ‘extended standards’ or ‘protocols with modified schema’ to help them overcome the challenges in making everything work together. But make no mistake that approach creates a closed and proprietary system, and by taking it you may be locking your company tightly into that vendor’s products for many years to come.   Harder still will be what happens when your selected vendor doesn’t play well with your preferred choice of hypervisor or overlay network vendor – which one will you then compromise? 

Keep all your options OPEN

Fortunately it doesn’t have to be this way. After all, didn’t SDN also promise to herald in a new world of ‘open’ networking? Juniper’s Metafabric is based on three key pillars, simple, open, smart, of which perhaps the most important right now is being truly ‘open’.

In this new promised fully automated world, networking decisions can no longer be taken in isolation. Everything in the automated workflow will eventually need to work together.  Making the decision to keep as many technology platform options open to you as possible while the market matures is probably the one most important decision you can make for your data centre network today. 

If you’re making decisions in the data centre network today perhaps you should ask your vendor how will they address these difficult questions before it’s too late.  Making no decision at all is probably even worse, but please remember, unlike in the The Butterfly Effect, you won’t get the option to go back in time and put things straight.

View the original article here