A few people you might recognize, including yours truly, are featured here in a video for Cisco Live. This was shot at Cisco Live in Orlando back in June. I’ll see you all next year in San Francisco!
Editor’s Note: Any resemblance to persons living or dead, known or unknown, read about, heard about, talked about, dreamt about (just once, don’t ask) not intended. Any offense probably intended. Standard disclaimers apply.
With all of the recent talk in the networking community about software defined this or that, it can be hard to separate the marketing and spin from the substantial and substantive. Beyond that, however, it can be even harder to pull out the truly useful ideas from among those that are really, really cool, and probably should be done, but aren’t the shiny panacea everyone builds them up to be. Case in point: APIs.
Application Programming Interfaces can seem like magic to the uninitiated. They are the secret sauce, the keys to the nirvana inside the shiny boxes in your data center, and the solution to every problem you imagine you have. The problem is, while eminently useful, APIs are not new, radical, or particularly interesting on their own.
So, in the spirit of some of my recent “get off my lawn” posts, let’s run through a few points on APIs that I think sometimes get missed in the breathless discussions of the data centers in this Brave New World (with apologies to Aldous Huxley).
There. I said it. I think a lot of folks with a non-programming background tend to inflate the potential magic-bean component of what exactly an API is. So, let’s clear this up first: an API is a file. Well, usually it’s a bunch of files, but nothing more. These files are a mix of types and usually come as part of a software development library or kit (SDK) from the manufacturer of a product.
At a very basic level, the files in an SDK contain descriptions of functions or objects that do things. Say you’re writing a program to calculate the area of a square. You can write that all yourself, or you can use a function that does this already and might be in a library somewhere. Just pass on some information to the function; it does the calculation and gives you back some information.
An API for a device like a storage array works the same way. I want to connect to the array and retrieve a list of LUNs. So, I have my program use some pre-built software code from the manufacturer, and now my little software program is connecting to the storage array and getting me a list of LUNs.
That is quite obviously a trivial example, but at a fundamental level that is all an API is: a bunch of software from someone that allows your software to talk to their device. The API by itself conveys nothing magical or complete- remember, you still have to write the code to do something. It just gives you the ability to access that device at a lower level (more direct) than you tend to get with command line interfaces, scripting, and other higher-level and more abstracted methods.
I’ve seen this idea floating around out there in some circles. Some folks are conflating the idea of open source, or other “open” terminology with the existence of an API. The mere existence of an API doesn’t confer any more openness than does a command line interface.
A command line interface allows you to control the device in some way, using pre-built commands that do certain things. An API allows you to do the same thing, but with your own software. So now you can build your own “CLI” off-box. Or you can automate some activities–much like you can today with scripting. An API is much more elegant, to be sure, but more open? No.
As a manufacturer, I can expose a lot of functions, methods, etc. to you in an API, but still hide the details of what’s going on. I can say, for instance, you give me a name and IP address, and I’ll connect you to the box. How I connect you to the box, however, might still be completely hidden away from you.
How many of us have used the wizards built in to the GUI of a device. Want a VPN from Seattle to New York? Here, I’ll ask you a question or two and then build it. Now, how many times has that actually worked, and how many of us use the wizards in most devices at all beyond the initial curious look-see. That’s the fundamental problem with this idea that an API allows all sorts of auto-magical, automated, secret-sauce, fairy-dusted solutions to all of our problems.
The manufacturer of a device has, theoretically, unlimited access to that device as they’re building and developing it. They can build the GUI, the CLI, and the wizards to do anything they think the customer might want. Now you come along and say, no, don’t build me any of that because I’ll just do it myself and it will be glorious. The level of effort involved is dramatically and consistently underestimated by neophyte developers.
In fact, when I’ve had this conversation with experienced developers, this very idea always comes up. APIs, they say, are incredibly useful and would be a nice-to-have or must-haves in most cases. No programmer is going to turn down programmatic access to a device. But, and there’s always a but in these conversations, the incredible amount of effort it takes to get from having an API and a box to having a fully integrated, automated, reliable and working system is dramatically underestimated almost universally by non-developers–including most engineers and systems folks in IT.
There is a reason why the large-scale systems of the past (the HP Openviews of the world) cost as much as a helicopter to buy, configure, install and actually use. There’s a reason why both closed and open source projects in this space have hundreds and thousands of contributors working on source code. It is incredibly difficult to develop systems of disparate systems that can reliably manage any level of automation.
H.L. Mencken once said, “Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong.” I don’t think that the desire for an API in every pot is wrong or non-useful at all. As a long-time programmer myself, I always prefer to have a programmatic way to talk to any device I own- the more the merrier. However, thinking that just having every device in your network programmatically accessible somehow solves your automation problems, or reduces complexity, or stitches everything together for you is completely, unequivocally, and totally wrong.
It actually sounds like the stuff of nightmares.
“So, why do you want to work here?”
If you’ve worked a day in your life, chances are you’ve been asked this question during an interview. And, if you’re like the rest of us, you’ve said something about how much you love the company, it’s your dream job, you’re looking to really make your mark somewhere, or some other hackneyed tripe that you hope sounds good to the person asking the question.
I’ve spent a lot of time interviewing people for my teams over the years, and I can tell you that your likely first instinct is right: the question is just about as worthless as anything you could be asked in an interview. Everyone answers it the same way–with vacuous gusto–and every interviewer happily ticks of a box as if you’ve passed some magical “qualified to work here” test. But it’s crap and almost all of us know it.
I’ve personally never used this question in any of my interviews, but I always get asked this when I’m interviewed. I hate to say it, but I really lose respect for folks when they use this question in an interview. I understand the ostensible goal is to get to the heart of why this candidate picked your job posting to respond to, why they jumped through the hoops to get the interview, etc., but the fact is that in most cases it’s because you have a job opening and pay in actual dollars and not Monopoly bills.
If you’re looking to get closer to what I assume the goal of this question is, you can change it up a bit and ask questions like: “What about our company intrigues you?” or “How do you see yourself contributing to the company?” or something along those lines. At the end of the day, you’re looking to get beyond the point where you’re getting the same rote answer from every candidate.
People have different motivations for applying to positions. Often they’re looking to move on because they don’t see any additional opportunities where they’re at, they’re in a negative work environment, or they’ve just topped out as far as the contribution and value they feel they can bring to the company they’re currently at. Other times it’s out of desperation: they’ve just lost their job or feel they’re about to, they need more money for a variety of reasons, etc.
Motivation is important, and I do understand the need to determine the motivation of the person sitting in front of you. However, I’ve always found it better to have a conversation with the person rather than asking the same questions they get everywhere else. Just talk to them a bit, get to know where they’re at in their career and what they’re looking to do.
Oh yeah, and don’t ask any of those questions like “How much wood would a woodchuck chuck if he was on a train going 50mph in 0-gravity, upside down?” That moves you from hackneyed to hack job. Just saying.
Author Janice Davies said, “difficult people are your key to self empowerment, you need to learn how to cope with them, not let them dominate and affect you.” But what if the difficult person is your boss? What then?
In over 20 years of working in my chosen career I have largely had what I can only suppose is the greatest luck in selecting my bosses. Most have been more than fair, have taught me along the way as true mentors, and several I still count as friends and advisors to this day. A couple, however, have truly been nightmares.
Everyone has their own gauge for what makes a boss difficult to work with, but mine comes down to more of a feeling than a set of concrete habits. And when I say difficult, I’m not referring here to a demanding boss, or one who expects results and calls you out for not achieving the results; that’s just the price of admission in the corporate world. I’m talking about when things reach a level of difficulty where you begin fearing for your job.
The problems in dealing with difficult people are, by nature, made even more difficult when that person is largely in charge of your ability to provide for your family. Your stress levels can increase, you start taking out your frustrations on the other people in your life that you work with or care about, and your overall health and outlook can become markedly more negative, leading to a decrease in productivity.
Below are some strategies I have found that have helped me, and I hope that some or all can help you should you find yourself in the position of having to deal with a difficult boss.
Adjust – As much as possible, try to adjust to the new reality of the situation. Sometimes, as people are put in new positions they can feel overwhelmed, under pressure, and are themselves dealing with difficult relationships upstream. With any luck, this period of difficulty will pass and you’ll find that you’re able to cultivate a strong, trusted relationship with your new boss.
Be Proactive – Try to anticipate your bosses needs before he or she knows they have a need. If they’re under pressure, and you can be the go-to-person that hands them reports, deliverables, etc., ahead of them asking, you’ll have gone a long way towards easing the relationship into a better place.
A lot of times this comes from understanding your boss’s role in the company. For instance, I report to the CFO at my company–a role which is largely concerned with budgeting, forecasting, and generally dealing with the financial health of the company. Everything that I do in the technical sphere is couched in terms of impact to the bottom line of the company. That’s a gross over-simplification, of course, but the point is that you need to understand your boss, what their role in the company is, and how you can help to make them look good to their boss.
Don’t React Emotionally – I can’t tell you how many times after reading an email I’ve wanted to walk down the hall to my boss’s office, storm in, and start loudly expounding on my view of the world and my boss’s place in it. I have seen that happen, and while I sometimes get a little joy in the vicariousness of the thing, I never indulge myself in the same behavior. I respond eventually, but not quickly or emotionally.
I’m not suggesting you ignore emails, phone calls, memos, or random edicts at all. In fact, I have a general rule of trying to respond to anything that comes my way by the close of business the same day. If it comes from my boss, I respond within two hours even after-hours. That said, you can acknowledge something simply, directly, and without emotion. If, a few hours later you still feel the need to have a conversation, you’ll have given the heat-of-the-moment emotions a chance to simmer down.
I have sent some serious flame-thrower emails in my day–some to vendors, some to co-workers, and even some to people I’ve worked for. Do you know the one thing every one of those emails in the last 20 years has had in common? Within minutes or hours I regretted sending them–each and every one. A little bit of time would go by and I’d increasingly start feeling like the petulant child I was acting like. Almost inevitably I’d trudge off somewhere to make an apology–not because I had to, but because I felt I needed to.
Learn from the Experience – Many of us either lead teams today, or will lead teams in the future. Even if leadership roles aren’t what you personally aspire to, the time will probably come where you will find yourself leading a team of some size. The experiences you have with your bosses should be suggestive of the type of leader you want to be. We all love the good ones, but sometimes it’s the bad bosses that teach us more in the end.
Know When to Walk Away – The relationship you have with your boss should never feel personally negative. By that I mean that you should never feel as if your boss **hates** you, or wants you to fail, or has no confidence in you as a person. Good bosses will let you know if you’re not meeting expectations long before it becomes an issue. If your boss is making your life miserable without any sort of useful feedback, then it’s likely one of two things is going on:
In either case, this is probably the point where you have to consider that things may not get better, and perhaps walk away. Work relationships should never be personally negative, but we’re all human beings and sometimes things just don’t work out. It’s irritating, often feels unfair, but it’s the way things sometimes are and we just have to deal with it as best we can.
Whatever you do, don’t follow your first instinct, and freak out. Don’t write up a nasty letter, or tell the person what you really think. Just follow the process professionally, and if you really need to vent a bit, that’s what your Human Resources department is for. Even then, however, nobody likes a whiner so try to keep your criticism as constructive, professional, and impersonal as possible.
Then, do what I do: go home, kick off your shoes, pour a nice drink, and celebrate your unbelievable good fortune to not have to deal with that boss ever again. Just don’t make a habit of it… after a string of bad bosses, you might have to consider that the problem wasn’t with them.
In 1876, an internal memo at Western Union is reported to have read: “This ‘telephone’ has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us.” At the time, Western Union was the Microsoft of its day–a behemoth company that touched everyone’s lives. While the veracity of that quote is questionable, the fact remains that after losing a patent lawsuit to Bell Telephone in 1879, the Western Union shifted its focus to money transfers. To put it another way, the entire business model upon which Western Union was predicated, collapsed to a new, disruptive technology that the leaders of the business failed to capitalize on.
While this has important lessons for business leaders today, we often see an almost reflexive reaction to new technologies in the other direction. We get in such a bother trying to divine the “next big thing” that we almost entirely fail to qualify the claims that are being made and end up betting the bank on unproven or half-baked concepts.
I’m certainly not saying that SDN is any of these things, but rather that there are a lot of myths and marketing fogging up the landscape. I actually believe that SDN–in at least some of its purported definitions–will most definitely make it into the networks of tomorrow, and further that several things will change as a result. I don’t, however, buy into a lot of the myths that seem to have developed suddenly, out of the ether, around the technology.
I should also point out that the myths below are some of the more common ones I hear, but taken in totality don’t necessarily represent any one company’s vision of SDN. There are many competing technologies and companies claiming the mantle of SDN which, in many cases, are completely at odds with one another. Is SDN the abstraction of the forwarding plane from the control plane? Is it programmatic access to network devices? Is it automagical definition of policy across abstracted forwarding planes–boxes of dumb pipes manipulated by controllers? The answer is, it depends on who you ask and what they’re selling. Myths abound, no matter from which perspective you look, and we’re going to debunk a few now.
SDN is a Useful Term – I don’t think so, no. I think the term is “marketecture” and is largely meaningless beyond very high-level discussions. There are so many competing visions of not only how to “do” SDN, but of what it even means that largely the catch-all term has lost its usefulness for an engineering-level discussion. Established companies are competing with start-ups, with one another, and in some cases internally to define what SDN is and what it is not. A lot of these ideas will end up in products and technology that will eventually be for sale, while many will fade or become nothing more than slight business differentiators in incrementally improved hardware. As it stands today, SDN as a term is nothing more than the cloud of this year–the thing-du-jour that every company can’t wait to shoe-horn into every marketing slide and product-line they have. It is itself devoid of meaning or usefulness. That’s not to say that the component pieces of any of the amalgamations of definitions aren’t themselves extremely useful–they are–but rather that the term is not useful.
SDN reduces complexity – For those preaching the “less complexity” variant of SDN, I’d say that you need to look at history. Did the advent of virtualization increase or decrease overall complexity in the compute space? It increased it, of course, by several orders of magnitude. The same goes for storage abstraction, and the same will happen with SDN. We may or may not gain efficiencies and flexibility, but we most assuredly will not gain simplicity.
SDN eliminates Network Engineers – This is patently silly on multiple fronts, but let’s just go with the easily picked and obvious nit to begin with: SDN is predicated on having a robust network architecture underpinning it. In other words, you can’t have software-defined anything until you have an infrastructure in place to build on. That infrastructure is going to be complex, highly specialized, and not at all simple to design, build, or maintain. Day-to-day change management will likely be done by less qualified folks, but you’ll still have a place for skilled engineers in the same place where they operate today: design, build-out, and troubleshooting complex environments.
SDN lowers costs – Based on past experience, I don’t think this will ever be true either. People will conflate the downward pressure on pricing and the further commoditization of all aspects of hardware with a lowering of costs directly because of SDN, but this is incorrect. It is incorrect in the same way it would be wrong to say that the abstraction of compute and storage in any way lowered overall costs.
To make sense of this you really have to start looking at 5 and 10 year historical costs (or even 15) to see what has happened. And what that looks like is a similar cost profile as a component of operating profit, but with a large increase in efficiency. I’ll say that another way, you’re not lowering your true IT costs over time… you’re increasing your efficiencies.
Why does increasing efficiency not lower overall costs? Because you rapidly fill the gap with new capabilities. Anyone who has seen a transition from bare-metal servers and storage to virtualized workloads, servers, and SANs has also seen the corollary of server sprawl. How many of us have collapsed thousands of bare-metal servers only to see the total number of VMs increase eventually?
Oh, and now you have a team of storage engineers, and a team of virtualization engineers, and you still have the server, network, DBA, ERP, help-desk, etc. from before you virtualized.
There are a lot of ways to frame or quantify the cost-savings claims in SDN, but I think a better and more accurate description might be that SDN will likely increase efficiencies. You’ll be able to do more with less, but you’ll fill the gap so quickly that any cost savings you think you’ll get will get eaten before one budget cycle is up. Likely you’ll have a large CapEx spend to do a fork-lift upgrade, and that will take 3 years to balance out and come off the books. In the mean time, you’re going to increase OpEx because of training, initial development, network redesign, etc. By the time your feet are firmly planted, you’re comfortable with the new look of things, and you’re ready to start counting the pennies “sprawl” of a new type (development costs most likely) will eat any savings. That’s a 3 to 5-year cycle just there.
SDN mitigates change management risk – This one is only partially a myth. For the bulk of change management, I’d say that this is quite likely completely true. Day-to-day port changes, routing changes, and provisioning (to name a few) are easily screwed up by the less experienced folks likely making those changes today. Having a system that can make the changes with less manual input is going to probably save a lot of the little ticky-tack problems that crop up from someone fat-fingering a configuration command.
Larger changes to a network are likely going to fall outside of the scope of what SDN brings to the table, especially in multi-tenant or highly complex environments. These are the types of changes you still are going to need a highly skilled team to implement, and I don’t see a point coming soon where I’d really feel comfortable trusting large-scale changes to an automagical, largely self-driven system. Even today, how many of us trust the software “wizards” built into any commercially available product? How many of us make wholesale, system-wide network changes using a wizard? Simply changing the name to SDN doesn’t change anything.
SDN is disruptive technology – IT is, almost by definition, filled with people who take a “down in the weeds” view of everything. It has to be. But sometimes this leads to a kind of unique myopia in viewing changes in technology. When Multi-protocol Label Switching (MPLS) was introduced, it was as disruptive to the status quo as anything, but it was adopted slowly, people adapted, nobody lost their jobs and whole industries weren’t eradicated. Why? Because from the business point of view it was just a more efficient way of solving the same old problems. It was better than what it replaced, but it was incrementally better. In other words, it wasn’t the telephone to Western Union’s telegraph.
SDN in all its myriad visions, and as evangelized by all of its newly christened champions, is fascinating, eminently useful on some levels, and maddeningly silly in others. At the end of the day, however, it’s critical that we don’t get so involved in the excitement, promise, and religious fervor of new technology that we lose sight of what is real, what is useful, and what is “marketecture”. Magic beans may have worked for Jack, but I’m not buying any for my network. Yet.
I have decided to take a quick break from my more business-oriented writing of late to focus on something that people seem to have an interest in: how I have my computer set up and configured. This post will necessarily be in more of a catalog format than article, but hopefully no less useful.
I switched to a Mac a few years ago, completing the circle of computing life as I did, as I started with an Apple IIc around 1981. In between I fell in love with various computers from the Amiga, Atari ST, early IBM machines, to Linux and finally to the pinnacle of all things computing: the NeXT. Ever since then I think I have been subconsciously trying to get my desktops to look as fluid and work as well as the NeXT machines did, with varying levels of success. Some of my choices reflect that impulse.
I will preface this by saying that this is how I have my computer set up and configured, and is by no means the right way–it just works for me. The software I use is what I find interesting or useful to my workflow and style, but I am always looking for improvements. This catalog, then, will probably be out of date five minutes after I’m done writing it all down.
Microsoft Outlook. I have installed and used Postbox, Thunderbird, and a couple of others, but I keep falling back to Outlook. Perhaps it is a little bit of the Stockholm Syndrome (though not IPv6 Stockholm Syndrome), but I can’t seem to find anything else that matches everything feature-for-feature that I need. It’s all a compromise somewhere, somehow. With Outlook I have to put up with the usual Microsoft Bloat, but I compensate with a lot of memory and processing power.
Google Chrome. I’m sure someone will castigate me for this (as if the last section wasn’t bad enough) but I just find that it works well, is lightweight, and does everything that I want reasonably well.
Cord is my go-to for connecting to remote Windows servers, though this is always in flux. I do much more via PowerShell than ever before, so pure Remote Desktop Protocol just doesn’t get used as much as it used to in my environment.
Evernote is my main tool in the “remembering stuff” category of tools. I use it to grab and catalog things that I find interesting or useful. I use tags and different notebooks and such within the tool, and it suits me nicely. I did switch to the premium edition quite a while back, and it’s well worth it as far as I’m concerned.
Tweetbot and sometimes my own command-line client (written in Python as a learning exercise) if I’m feeling plucky.
A lot of these tools revolve around specific tasks. For instance, I use Markdown Pro to compose all of my blog posts, this one included. It gives a nice appearance to things without a lot of the fuss and extra baggage of full-weight word-processors, and I can export the completed work in HTML or PDF format. Not particularly fancy, but it gets the job done. My only complaint here is that the formatted portion of the screen (split-screen composing window) doesn’t keep up with the raw-text side. Minor annoyance, but if I could find something that solved this I’d probably switch products.
I also use BBEdit for some things, though I’m finding I use it less these days than a couple of years ago. It’s definitely one of those tools you either learn and love, or hate. There’s a fairly steep barrier to entry in both price and learning, but you may find it useful for its syntax highlighting, scripting, etc. More useful for raw code editing (HTML, XML, C, etc.) than for articles and such.
LaTeX has been my go-to for any kind of serious document creation (resumes, manuals, scholarly papers, etc.) for years now. I will warn you that it is absolutely not for the feint of heart as it is basically an old programming language for document markup. Most Masters and PhD theses are written in this language, as are most scholarly research papers. It is well worth learning, and once you do you’ll never use anything else as it creates the most hands-down beautiful documents you’ll ever find. A lot of people will be turned off by the steep learning curve (you have a lot of code to learn, and a lot of compiling to even get a viewable document) but if you have the patience, go for it.
The link above is to an OSX-specific set of packages, and I recommend you start there. You can also look at The LaTeX Project and a nice Document Guide/Wiki to get started. The CTAN Archive is a great place to browse for packages and whatnot. Happy hunting!
I use iTerm2 instead of the built-in terminal program shipped with OSX. It has many nice features (too many to list), is more customizable, and is just better. Go get it. You’ll thank me. While you’re at it, get the Solarized package and install it for everything you have. In addition to a uniform color palette, it helps across the board with aesthetics when working in any of the supported applications.
I use two primary tools for coding on my Mac: XCode when I’m doing something using the Cocoa Frameworks (not often) and Komodo IDE 8 for everything else (mostly Python these days). Your choices here are likely to be highly personal depending on how much programming experience you have or are likely to do, and in what environments. You can do any kind of programming or scripting in any kind of text editor, of course, but I find a nice IDE to be a comforting thing to have around. I also have my VIM install configured with syntax highlighting for the languages I use.
I use a ton of other programs from WireShark to DropBox to get my work done; VPN clients, various photography suites (another hobby of mine), to things like 1password for password storage. Unfortunately, this post is longer than I expected already so I’m stopping it here. I’ll come back with a part II soon, and hopefully there I can include all relevant portions of my actual configurations (.vimrc, screenrc, tmux_conf, .bashrc, .profile) as well as all of the OSX-specific hacks I’ve made over the years to get my Mac to behave like I want it to.
In the spirit of giving back, I’d love to hear from anyone else as to what nifty software, configurations, or hacks you use to get things done on your Mac and why you like them. As I said at the top, many of these things are just what I’ve done, but I’m always open to suggestions and better ways of accomplishing things.