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
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.
7 thoughts on “Snowflake Networks”
Some really valid points there Daniel! I think “snowflakes” are kinda inevitable though TBH. While the fundamental networking principles will always be the same, no environment is ever a green field, so there is always a history to deal with, and that history inevitably begins at different points in time, and in different design eras for different customers. Whatever new design we come up with has to integrate with the existing and so in the real world we have little choice but to be pragmatic.
Like you, I think we need to set ourselves some guidance for how to approach a design, but execute it with compromise in mind, so that we are able to meet the customer’s expectation. For me, the best approach is to look at the overall architecture, create an overarching “perfect world” view to aspire to, then to look at the current network and build a roadmap to replacing/augmenting the environment to Utopia as possible.
As for community – there are awesome places like https://thenetworkcollective.com/ and https://learningnetwork.cisco.com/groups/ccde-study-group where some friendly, inspirational, helpful folk hang out. Great places to start!
And there are plenty of blogs too – I particularly like https://networkshokunin.blogspot.com/ where the author is gradually building out a set of Network Design Principles … 🙂
Fully agree, Daren. I’ve read your blog and it’s great. Keep it up!
I know some of the communities but feel like I’m preaching to the choir. Need to find a platform where more people can be reached. You gave me some food for thought. Will get back when I know how to get this moving forward 🙂
While I agree with what you say, I have something on my tongue and need to let it out 🙂
What are the boundaries of “snowflakes”? In plain English, what seems complex to somebody can be the most natural thing for somebody else. As Darren mention some network complexity is kind of expected because the demands are complex (and the business understand the complexity of their demand).
My practice is always to analyze the request (don’t assume), ask questions to clarify gray areas and implement the least complex solution possible without jeopardizing the support for business.
Now if the result is a “snowflake”, then is a “snowflake”. I usually don’t drop a design because somebody says is complex and provide no arguments (not feeling comfortable with is not an argument).
When I have a complex network, I’m trying to explain the best to my audience, fill them with information and share the reasons why is like this. The rest is up to everybody to raise the stake of understanding technology and the result of a complex request.
Just my 2c on 🙂
Actually we are in full agreement. My point with this post was to show that we are using this term to loosely. Every design is unique although a lot of the design my resemble another one. So I think we should only use the term snowflake when it’s motivated. Such as when a design is more complex and fancy than needed.
A design should be minimally complex based on the ingoing requirements. Sometimes we try to push back but in the end we need to deliver a design fulfilling the requirements.
It’s not possible to avoid all complexity and there are always tradeoffs. Just need to find them 🙂
And if you haven’t found the tradeoff, you’ve not looked hard enough!
Pingback:Snowflake Networks - Gestalt IT
Pingback:Link Propagation 127: Dealing With Snowflake Networks