I recently wrote an article for searchSDN at TechTarget on the subject of choice in the SDN markets. The gist of the article was that from a marketing perspective one of the most effective strategies in a cluttered market is to reduce the consumer’s perceived choice to a binary state. It happens all the time, and I used the example of Coke vs. Pepsi to illustrate this. My recent travels and vendor meetings as a delegate to Networking Field Day 7 only served to solidify my thinking in this area, with so many cutting edge and established vendors alike pushing oft competing visions for the future of networking. I’ll be writing more about Brocade, Plexxi, Avaya, and Pluribus Networks in specificity soon, but for now check out my thoughts on the illusion of choice and let me know what you think.
On Buggy Whips and Restlessness
Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,
And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.
“The Road Not Taken” –Robert Frost
It is an interesting observation that when most early English or Literature majors first read that famous poem by Robert Frost, they analyze the choice the protagonist makes as a positive one. In fact, the ramifications of the choice are never alluded to or mentioned. It is simply that there was a choice to be made, and while many people chose one path, the protagonist took a different one—for better or for worse—and that affected the outcome of his or her life. Recently, I made such a choice myself.
I have written, at times over the years, about the perils of IT Management. I have also written about the various bureaucratic idiosyncrasies of working in the enterprise space, especially at a multinational defense contractor. And most recently, I have written about my overall dissatisfaction with the whole lot of it. Now I am doing something about it.
Yesterday, I resigned my position as IT Director of the company I have worked at for nearly eight years and accepted an offer to get back out into the world and change my view for a while. Beginning March 17th, I’ll be a part of the team at World Wide Technology (WWT) in a consulting engineering role. It’s been a tough decision in a lot of ways, but I think it’s the right one for a couple of reasons.
The world of IT is changing on all fronts, it’s changing rapidly, and I need to be a part of that change. My recent trip to San Jose for Network Field Day 7 (a part of the broader Tech Field Day organization, and something I’ll be writing about more soon) really burned that into my mind, but I’d been restless for a while. Rapid change is something that you have to be in a position to harness and to benefit from, and the fact is that despite my title and accolades, I haven’t been where I need to be for long time.
Sure, I have had incredible opportunities in the last few years, personally knocking off a list of accomplishments that I can be proud of: moving to a fully dual-stacked IPv4/v6 environment; learning and performing a full scale FlexPod build-out; restructuring the entire world-wide routing and switching infrastructure in a large environment; being at the forefront of adopting full-scale virtualization beginning back in 2005; and building up a complete IT team from scratch. But now that we’re there, and most things are fixed and running smoothly, we’re in a maintenance mode—there’s no more challenge to be had, nothing on the horizon, and I’m not a patient person.
The reality is, if you’re not at a company where IT is core to the business model, a lot of the technology out in the world is simply not something you’ll get to see, touch, or know about barring the standard thing all of us in the industry do, which is to read and study on our own time. And if you’re in an industry based around technology that hasn’t changed appreciably in over 60 years, it can feel at times like working for the proverbial buggy-whip manufacturer and watching the new horseless carriages rolling by your window.
At the end of the day, I don’t need to have a team to be happy. I don’t have to have a title to feed my ego. What I really need is to be involved. I need to be involved in shaping the future, in changing the status quo, in moving the ball forward against a wall of stagnation and staid old political bosses who have no interest in change. Time will tell if this move gets me closer or further away from that goal, but at this point, today, for me, it’s Frost’s road less traveled and I’m going to see where it leads.
Cisco Modeling Labs (CML)
The product formerly known as VIRL has been rebranded and is slated for release in the first half of 2014. My money is on it being released just prior to, or at, Cisco Live in May. It is an intriguing product that I have had the opportunity to play with for a few months now. If you haven’t read my TechTarget write-up, take a look at it here:
Network Field Day Calendar
For those of you who understand what Tech Field Day is, and want to follow this week’s events, feel free to use this calendar to track the events.
Lately I have been struggling with career burnout. Or maybe it’s existential grief, or bad burritos, gas, and too many reality television marathon binges. Whatever it is, however, I noted with some interest this article by Matthew Mengel (@mengelm) over on the Packet Pushers website. Matthew is pushing aside his career in the networking industry to pursue his true passion in astronomy, after winning a scholarship to complete a PhD program in the subject.
It is fair to say that I read his article with a fair bit of jealousy. After 22 years in the computer industry, I nurse nightly dreams (or delusions) of moving on to other things. I said as much on Twitter, and found a surprising number of other folks in my cohort who felt the same. Long careers and hours had taken a toll.
More surprising, however, was what happened when the discussion turned to just what exactly we would all do, given the chance. There were a few outliers, but far and away the answers were all in the fine arts or generically creative space: art, film, writing, and woodworking were mentioned. And the number one reason why was that these were all pursuits that were started during the naïveté of youth, before we all realized that the money was no good.
I know that I never dreamed of a career in computers when I was a child. My dreams were all rooted in writing, art, and music. I fully expected to be a musician, famous artist, or reclusive, well-read writer. Obviously, that didn’t happen.
I don’t know when I realized the impracticality of the arts as a career, but at some point in my later high school years I decided that the law would be a more practical profession. Luckily, my uncle (a very successful attorney) talked me out of that, and I accidentally happened into the world of professional computer-wrangling.
I had been programming and hacking since the age of eight, so when someone offered me a job at what seemed like incredible pay back in 1992, I didn’t think twice. In retrospect, it’s amazing how low the asking price for a person’s soul turns out to be. Fast forward to the present, and we’re back to the conversation about burnout and choices.
In talking to the good folks on Twitter, and friends and coworkers, it seems as if there are a tremendous number of people who would do something else, if the money was left out of the equation. One of my best friends and I were talking over the holidays on this very topic, and it seems as if we’re all victims of our own success. “I’d move and change careers, “ he said, “but I can’t afford to start over.”
And there’s the problem. The same problem everything always boils down to: money, or, more realistically, food and shelter. In all of human history, we’re still slaves to our own ability to survive. It used to be a climate, or food-source, or shelter that drove us to wherever we ended up in life. All we’ve done in the whole of our species is manage to abstract that concept in the form of money.
Maybe I’m reading too much in to all of this, or being too dramatic, I don’t know. All I do know is there are a hell of a lot of us out there, it seems, doing things for money that we wish we didn’t have to do any more. I don’t know what that means, and I’m hesitant to project my own anxieties on the rest of you, but I think it at least begs a couple of questions:
(1) If the money was equal to what you do now, or what your career will ultimately bring you in terms of earning potential, would you do something different?
(2) When were you the happiest in your life? What were you doing? Was it what you do now?
Feel free to send me answers and feedback via my twitter handle (@someclown) or here in the comments.
Ruminations on Software Programming
Software programming is a challenging endeavor. I know, because it’s how I started my career, and it’s still something I do for fun and to keep my network engineering skills sharp. Writing software is also very tedious, which is why I quickly moved on to other things and now haven’t written code professionally for over 18 years or so. It takes a particular kind of person who wants to really learn the syntax and thought process needed to be truly skilled at coding.
It is also a particular type of person who wants to know the level of detail in how a large-scale network operates. Most IT professionals are content to know the basics of networking—enough to do their day jobs—and leave the hard-core network knowledge to that special sort of masochist breed known as network engineers. The hardcore network folks who are obsessed with performance tuning even the smallest details of how packets move around and between datacenters, the intricate differences between routing protocols, tunnels, underlays and overlays, and bit-twiddling for fun and profit.
In the past, those two sides of what I’ll loosely call the IT world have typically been different functions. The software types write the code for the systems, the systems people deliver the services, and the network folks tie it all together. From the outsiders’ point of view looking in, we’re all “computer nerds” and any differences between us are largely semantic at best. But peel back the vale and you’ll see that we’ve all decamped to our respective corners of the playroom and started our own little fiefdoms.
To hear some tell the tale the loose alliances and unsteady truces that have kept us functioning for so long are about to collapse under the weight of a new technology paradigm: Software Defined Networking. While I hope the current crop of shrill screeds about network engineers dying off if they don’t learn to program will slowly start to fade away as the reality of things sets in, I’m not holding my breath. SDN brings changes to the playroom of IT, for sure, but as I’ve written many times before, it is incremental, not wholly disruptive, change that’s coming on the back of SDN.
We only have to look to the changes that have happened in the systems space over the last 8–10 years or so to see what the future looks like. When the first wave of system virtualization started to make inroads, there was a tremendous amount of pushback from all corners of the IT establishment. Vendors refusing to support anything installed on a virtualized OS was the norm, and there were all sorts of opined pieces floating around the trade magazine circuit, bemoaning the death of the systems and applications folks.
In this brave new virtualized world, so went the reasoning, there would be no need for systems administrators. They would all go away in favor of this new specialty. In reality what happened was that the systems people kept right on doing what they’d always done, which was to learn the new technology… incremental change prevailed. Now any self-respecting systems admin knows and understands at least one hypervisor system at a pretty solid level. The tools changed, the paradigm shifted, and the systems administrators changed in parallel.
Did everyone suddenly become software programmers? Nope. They just kept on adapting with the times and instead of using the tools they had been using, or perhaps in addition to those tools, they started using new tools like Microsoft’s PowerShell. Now most big appliances in the systems world are accessible via PowerShell commands and the systems people can do more than ever. In fact, they can do it more quickly and accurately than in years past.
The same thing is going to happen on the network side. Instead of being confined to a pre-built OS, purpose built for one device, we’ll be able to access all of our devices using various new methods. Some of us will use off-the shelf solutions wrapped up as management packages—does anyone doubt that the big-boys of the network world will come out with software for SDN controllers that is pre-built, pre-packaged, and ready to use with no programming knowledge required? Others will use more advanced techniques and script our own tools to do specialized tasks as we need.
Given the changes coming in the next few years, I will say that any network engineers out there who haven’t been exposed to basic programming precepts; things like loops and basic logic flow, algorithms, and generalized problem solving using a programming-like syntax, should probably pick up a book and start playing around a little. PowerShell is a good place to start, as would Unix shell scripting (start with bash), but if you really want to learn a programming language, and you want something that will be useful in the networking world over the next few years, I’d highly recommend starting with Python. It’s easy to learn, easy to use, easy to get things done, and you get some immediate gratification. Also, outside of pure scripting languages, Python really seems to be where everyone seems to be coalescing when it comes to SDN controllers and APIs for network programming. Jennifer Rexford writes about the Frenetic Project and Pyretic in this article at Tech Target and it is well worth a read.
At the end of the day, the IT game is one where the rules are always changing, the skillsets always evolving, and quite honestly if you’re still doing the same thing you learned 5 years ago you’re already behind the curve. SDN may shake up the world of network engineering in a way we haven’t seen in a while, but it is nothing more than the continued march of progress. If you’re not reading at least one whitepaper or book on a new technology at all times, I personally don’t see how you’ve stayed in the game this long. SDN is just more of the same. Adapt or quit now.
Software programming is always going to be a specialized skillset, as is network engineering—at least at the highest levels. That doesn’t mean that you shouldn’t embrace the coming change and learn to play with the kids on the other side of the playroom a bit, though. If you venture over to the other side, you might find that some of the toys they have are the missing pieces from your play set, and that you have more in common with one another than you originally thought.