A GUI and a Wizard
One of the brilliant things about conferences like Interop is the hallways (and if you’re not going to Interop, this is why you should be!). It’s not that I don’t enjoy the sessions, but—like the IETF—I often get much more out of the conversations with folks who know networking, and yet have a completely different view of the problems we face in the networking industry, and hence completely different ideas about the way forward in resolving those problems. One of my major problems in life is I often can’t think of a solid answer when I’m sitting there in the conversation itself (one of the reasons I always converted TAC cases to email, rather than sitting on the phone with a customer).
One such conversation (with @cigoodwi) brought out a phrase I thought I’d never hear in the networking world—”a GUI and a wizard.” The context was this: what most x% (your beliefs about the percentage may vary) companies need is a network they can run with a GUI and a wizard. It’s a startling statement, of course, but—in reality—true in many respects. Given this is our goal, the question is: how do we get there?
There are (at least) two different ways forward. The first is to depend on “the vendors”(cue unicorns here) to solve this problem. For instance, one of the “best of show” winners at Interop this year is the Alcatel Enterprise fabric. It’s pretty impressive, actually—you plug up a port, and the new device largely configures itself. For a network with a small to moderate number of routers and a fairly straightforward set of services, this is a major leap forward in deploying network gear—pretty close, in fact, to a GUI and a wizard. Of course, you must live in an Alcatel centric world to use this feature. So let’s assume this illustrates this “GUI/wizard based” network without programmability, just for the sake of argument. This leaves us tied to a particular hardware vendor, and leaves us with a nice painted picture on top of a really ugly mess underneath. Anyone who’s tried to troubleshoot an ugly mess when it doesn’t work knows where this particular path heads — forget the 5:30 quitting time, or the straight sleep through the night.
What is our other option? Let’s go back to the PC market as an imperfect example (because we know the PC market and networking markets are not complete analogs). MS Windows (the OS everyone loves to hate — after all, every universe needs Darth Vader, doesn’t it?), LINUX, and OS/X have, over the years, become much closer to the “GUI and a wizard” standard we’re looking for. The hardware that underlies these operating systems has also, largely, become pretty simple to put together. I well remember the days of yore, when I would stand up twenty or thirty systems on a bench to build—it wasn’t an easy process. I could spend a week standing 30 servers up pretty easily, from the physical build to the software installation.
By contrast, the last system I built took just an hour or so in hardware, and the last laptop migration I did costs me about three hours total. I just bought three tiny servers for a lab; I estimate putting them together will take me on the order of an afternoon, if not shorter. Things have clearly changed in the personal computer world, no matter how much we might whine.
But — why? How has this situation come about in the PC market? I would argue it is specifically because the hardware has been separated from the software. A number of operating systems can run on a number of different CPUs, so the hardware folks and the software folks are, within certain bounds, “set free” to pursue a GUI and a wizard in their own realms. The competition software against software tends to produce software that’s easier to use, and runs on a wider array of hardware devices — software “ecosystems.” The competition between hardware platforms tends to produce hardware that will run a wide array of software, because that’s a primary way to gain a broad base of sales. Given this, I’m going to wax bold and say something that isn’t likely to make my cisco friends happy (and my Juniper, Arista, and other friends…).
Given the way networks work—that they are actually a system of systems distributed across time and space — there is only one way we’re really going to reach the nirvana of a GUI and a wizard. That one path is through figuring out how to separate the hardware from the software. And the only way to truly separate software from hardware in the networking world—given the nature of networks—is through network programmability. Note that I didn’t say the hardware must be reduced to “commodity,” as I don’t think that’s even necessarily a desirable outcome. I also didn’t say all software should or can be open source, as I don’t think that’s true, either.
But if you really want a GUI and a wizard, the path to that destination is by developing and using a single set of standard APIs between the hardware and the software—in other words, vendor neutral network programmability. At least that’s the way I see it.