Freedom to

Pardon me if I go a little bit on the philosophical side of life as a network engineer this week, but we need to have a little talk about freedom. This last week, Ethan wrote a post on his new criteria for network design and architecture. While I agree with the points Ethan makes in his post, there was one thing that put me sideways. In fact, this one thing has always put me sideways to our modern world.

Freedom.

Ethan gives what is a pretty standard (Lockian) definition of the idea when he says, “Freedom is the power or right to act, speak or think as one wants without hindrance or restraint.”

But, harking back to the story of Ishmael and Isaac, we need to remember there is a real difference between freedom from and freedom to. Freedom from constraint might feel like real freedom, but it’s the freedom of the wilderness. Freedom to create might feel like slavery with its self-discipline and bounds, but it’s the freedom to build — to create.

Let’s turn to one of Ethan’s examples here — open standards, and vendors sticking to them, to bring the point to the world of network engineering.

Open standards are great — we couldn’t live without them in the networking world. But open standards are built on a platform of volunteers, and they only work if we, individual network engineers, have the discipline to insist our vendors stick to them and to participate in the process. Further, open standards require that we, as network engineers, learn how to make things work, rather than how to configure a specific vendor’s command line. Open standards, in other words, aren’t “magic.” They won’t work without you and I — without us making conscious choices about what we do and how we do it.

As another example, let’s look at this in terms of choosing to push your processing to the cloud or keeping your processing in house. There is a range of choices here, but let’s focus on three just for the sake of argument.

• Push your data to the cloud and let someone else deal with the complexity.
• Keep your data in house, but rely on vendor based solutions to provide the infrastructure.
• Keep your data in house, and focus on open solutions, putting the pieces together yourself to make it all work.

The truth is the first might feel the most “free,” because you’re doing the least thinking, the least worrying, the least work with the technology itself. Without getting into the reality that the demons of complexity just can’t be defeated that easily (read my next book if you want to find out more on this point), we need to be careful not to run from the responsibility — the self discipline — of learning and managing the decision, the data, and the process.

In the real world, there might be different solutions for different problems — I’m not claiming here that cloud is a bad choice because it’s lazy, or reduces thinking, or whatever else. What I am saying is we need to stop being afraid of the discipline it takes to choose door number three — and we need to make certain we’re not choosing the easy path just because it seems, well, so free.

Again, the self-discipline it takes to be really free doesn’t often feel very “free.” But we really aren’t choosing to be free or not, we’re simply choosing which type of freedom we want to have. The freedom from constraint, or the freedom to build great things.

Which freedom will you choose today?