imelamory - Fotolia

Get started Bring yourself up to speed with our introductory content.

Minecraft paves the way to grow enterprise SDN, seriously

Insight from the Minecraft video game points to how enterprise SDN adoption could grow faster with a single interface for monitoring, confirmation and troubleshooting.

So, my kid is into Minecraft now, and since she's six, that means I'm into Minecraft now. And if I'm into Minecraft, that means I'm compelled to hack it.

Using Forge to expose event hooks, I built a stupid-simple poller that bangs on my network monitoring system via REST and JSON. Now, while my daughter and I build houses together in-game, I can keep my eye on my core router's CPU utilization with a variable-width lava flow. Because, geek.

The more time I spend with the game mechanics, the more I think about non-traditional system control, especially in the Age of DevOps.

The line between configuration and programming is quickly disappearing, especially with software-defined networking and software-defined storage. One minute you're establishing the minimum access requirements for an application, and the next you're dealing with a failed security audit or, worse, an active intrusion.

To accelerate enterprise SDN adoption, we'll need a level of integration never previously achieved by IT tools.

In Minecraft, these are not three separate consoles. Monitoring (situational awareness), configuration (building) and troubleshooting (survival) co-exist simultaneously in the same interface. So, to accelerate enterprise SDN adoption, we'll need a level of integration never previously achieved by IT tools.

String + Redstone = Firewall block

As administrators, we spend the vast majority of our time building and monitoring our networks. Take class‑based quality of service (QoS), for example. In the morning, you might have an inspiration for a new traffic policy you're certain will harmonize jitter and drop intolerant HD telepresence with best effort HTTP traffic. You happily craft a policy map of peerless perfection and apply it to your routers. You stand back, watching your traffic reports for glory, and … it's only marginally improved.

What happens next is DevOps. In three different windows, you watch real-time traffic changes on your network, update your class-based QoS policy, and lastly, you Google "class rule spell examples." Lather. Rinse. Alt-Tab. Repeat. Eventually, it works as envisioned, but if you compare the resulting policy with your clean-sheet design, they're unlikely to be similar. Effectiveness came not from perfect packet precognition, but from iterative development with live feedback. Compare those three disparate windows with the Minecraft UI, where awareness, change management and troubleshooting are seamlessly integrated.

I don't believe we'll be Lawnmower Men, flying through virtual network worlds wearing Oculus Rifts while fighting motion sickness with a vNose. But by the same token, today's advanced persistent threats are effectively security monster spawners. The days of assuring threats will always enter from the outside are long gone, and we should accept that creepers are constantly popping out of the ether inside our defenses. They're mobile and some will kill your network if the wrong person looks at (or clicks on) them.

But what we are enabling with enterprise SDN is an environment where we can hear a threat approaching from behind while we're heads-down, chipping away at a service delivery issue. If we can spin around and dispatch them reflexively with the same pickaxe we're using to configure permissions on a VM, then we can quickly return to the task at hand.

An SDN gun that draws configs, right?

Minecraft's real appeal to my demographic (OK, just me) may be that for all practical purposes, it's a giant gun that shoots virtual 2x2 LEGOs considerably faster than fingers can locate, align and place physical parts. With software-defined everything, we're building a ubiquitous activation framework that any controller application can use to expose hardware to efficient game mechanics. Think of it, an SDN gun that draws configs from appropriate pallets, shoots them and then intelligently aligns them into the environment. Who wouldn't want that? Other than Endermen, of course.

Next Steps

Find out what combining SDN and DevOps tools will mean for the network

A DevOps primer: How DevOps affects networking pros

How SDN apps can enable more granular traffic management

Check out the key benefits of SDN northbound APIs

This was last published in April 2015

Dig Deeper on Northbound applications and interface

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Do you believe the line between configuration and programming will disappear?
Cancel
No.  There will always be a need for programming.  Even in the most advanced systems I can imagine, programming of some form is being conducted based on some kind of commands or interfaces.
Cancel
Weird discussion title and article title, but I guess I get the point. I suspect that what you're getting at is that the way people "configure" things will evolve to be more like programming that it is today, where it's more line-by-line (fixed) configs. 

We definitely see the need for programming skills increasing as more of what used to be infrastructure moves to software and people are dealing with the tools of programmers (version-control, GitHub, config-mgm't tools, APIs, etc.)
Cancel
I don't believe so. I think there will still be a need for programmers well into the future, or at least till I retire. In the last 30 year I have seen a lot of changes in all aspect of the IT industry. I can only imagine where the next 30 will take us. Maybe something better will come along like AI writing it's own code....
Cancel
I think I may misunderstand this question. Won't we always need someone to program those configurable tools? At some level it always boils down to programming, doesn't it? I think it may be easier to argue that at some point, the number of people configuring will be greater than the number of people programming, although that's already true, because there are more users than programmers and they are configuring constantly. So, I'm not super sure where this question is going.
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close