Get startedBring 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.
Download this free guide
SD-WAN Buyer's Guide: What to Know Before You Buy
In this two-part guide, analyst Lee Doyle reveals the top 7 SD-WAN trends to watch for this year, and our editors compare 13 leading SD-WAN products in one handy infographic to help guide your purchasing decision.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.
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.
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.
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.)
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....
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.
Join the conversation
5 comments