Snowflake Networks

Snowflake networks, sounds like a good name for a network design company, but this is not what this post is about. Are you familiar with the concept of a snowflake network? This terminology comes from the notion that each snowflake is unique at a molecular level. In networking, many networks don’t look the same, so the term snowflake networks was coined.

Lately there’s been a lot of discussions on networks being snowflakes. Especially on some of the podcasts (you know which ones). What is being discussed is that we need to move away from designing networks that are complex, networks that are snowflakes. Every network is 95% the same and only the last 5% is unique. First, let me agree that snowflakes are bad. Personally I believe we should adhere to the following design tenets if possible:

Don’t use more complexity than needed
Use as much L3 as possible
No stretching of L2
Don’t use more protocols than needed
Don’t change default setting unless needed
Don’t “gold plate” the design
Don’t use “nerd knobs”

I think most of us, if not all, can agree that these tenets make sense when designing a network. So why do networks end up being complex snow flakes? Some of the reasons I can think of:

Unexperienced Network Architect
Not utilizing a proper design process
Lack of vision from the business
Too low technical skills in the business
Business requirements are complex

So a network can end up being complex for the right or for the wrong reasons. So let’s have a look at some of the reasons above and what we can or can’t do about them.

Unexperienced Network Architect – It takes time to become a good Network Architect. Some of the things we can do to help accelerate this process is:

Push network design in blog posts, talking to people etc
Encourage people to go after design certs such as CCDE, VCDX etc
Provide mentoring to up and coming Network Architects
Build a community around network design

Not utilizing a proper design process – Many people design networks ad hoc. They don’t gather the business requirements. They don’t analyze the current network design. They don’t understand the business. This WILL lead to a poor design, or at least a worse design than would have been possible if a proper design process was being utilized.

Lack of vision from the business – This can be challenging. Some business don’t have a clue where they are going. It’s your job as a Network Architect to help the business form this vision. To make sure the vision aligns with the business and that they don’t go down the wrong path.

Too low technical skills in the business – The E level people should not have to be technology experts, but if they lack even fundamental knowledge, then it will be difficult to get them aligned with your vision and understanding why and how they need to go down a certain path. You may need to hold workshops explaining technologies and concepts to them until they can properly understand where your design is going.

Business requirements are complex – This is the main reason, from my experience, why networks end up being complex and snow flakes. Most of us architects don’t want to build complex networks. Why?

After designing a network I want to move on
I don’t want to get calls in the middle of the night
I want operations to understand the design
If only I understand it, then I’ll end up answering questions for the lifetime of the design

So let’s agree that’s in its everyone’s interest to not build complex networks. Yet they often end up being so. So tell me how you build a simple network for:

National air traffic control network with multicast requiring convergence within 2 seconds across the entire network, including WAN providers

Service provider network offering both L2, L3, unicast and multicast services

Networks like these are going to end up being complex. Why? Because the requirements are so difficult to fullfill so you can’t do it without using complex technologies like multicast, BGP, BFD, VPLS, EVPN and so on. Yes, there are things you can do long term like changing your applications but in the short term the business needs to stay in business.

Here are some things I do when discussing complex designs with customers:

Explain the consequence of doing it one way or the other
Explaining the operational impact of doing something
Strongly recommending the less complex solution
Offering advice on how to simplify the design
Telling them what they need to do to make it possible to go to a simpler design

So let’s say I refuse to design a network for the customer because I feel it will be a complex, snow flake network, and very brittle. Why would this be wrong?

It’s not very professional to behave this way
Customer will go somewhere else
Likely to a less experienced architect
They will end up with a worse design
They will end up with operational problems

So what is my point about all this? Yes, I agree that we don’t want snow flakes but the discussions lately make it sound like it’s something that can be entirely avoided, which is not true, at all. So instead of just complaining about snow flakes, here are some of the things we can do:

Teach colleagues (especially developers) about networks and design
Go with systems and applications that don’t have broken networking requirements
Build a network design community
Offer mentoring
Push back on bad designs but realize that sometimes you have to do the best with the worst
Bring the discussion to a higher level and understanding the reasons why networks become complex

What are the reasons you see networks ending up being complex? What are you doing to avoid it? What should we as a community do? Bring in the feedback.