• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Standard Disclaimers
  • Resume/Curriculum Vitae
  • Why Blog?
  • About
  • (Somewhat Recent) Publication List

packetqueue.net

Musings on computer stuff, and things... and other stuff.

September 13, 2013 Uncategorized

The API Obsession

Read­ing Time: 4 min­utes

Edi­tor’s Note: Any resem­blance to per­sons liv­ing or dead, known or unknown, read about, heard about, talked about, dreamt about (just once, don’t ask) not intend­ed.  Any offense prob­a­bly intend­ed.  Stan­dard dis­claimers apply.

With all of the recent talk in the net­work­ing com­mu­ni­ty about soft­ware defined this or that, it can be hard to sep­a­rate the mar­ket­ing and spin from the sub­stan­tial and sub­stan­tive. Beyond that, how­ev­er, it can be even hard­er to pull out the tru­ly use­ful ideas from among those that are real­ly, real­ly cool, and prob­a­bly should be done, but aren’t the shiny panacea every­one builds them up to be. Case in point: APIs.

Appli­ca­tion Pro­gram­ming Inter­faces can seem like mag­ic to the unini­ti­at­ed. They are the secret sauce, the keys to the nir­vana inside the shiny box­es in your data cen­ter, and the solu­tion to every prob­lem you imag­ine you have. The prob­lem is, while emi­nent­ly use­ful, APIs are not new, rad­i­cal, or par­tic­u­lar­ly inter­est­ing on their own.

So, in the spir­it of some of my recent “get off my lawn” posts, let’s run through a few points on APIs that I think some­times get missed in the breath­less dis­cus­sions of the data cen­ters in this Brave New World (with apolo­gies to Aldous Hux­ley).

An API is not magic, secret sauce

There. I said it. I think a lot of folks with a non-pro­gram­ming back­ground tend to inflate the poten­tial mag­ic-bean com­po­nent of what exact­ly an API is. So, let’s clear this up first: an API is a file. Well, usu­al­ly it’s a bunch of files, but noth­ing more. These files are a mix of types and usu­al­ly come as part of a soft­ware devel­op­ment library or kit (SDK) from the man­u­fac­tur­er of a prod­uct.

At a very basic lev­el, the files in an SDK con­tain descrip­tions of func­tions or objects that do things. Say you’re writ­ing a pro­gram to cal­cu­late the area of a square. You can write that all your­self, or you can use a func­tion that does this already and might be in a library some­where. Just pass on some infor­ma­tion to the func­tion; it does the cal­cu­la­tion and gives you back some infor­ma­tion.

An API for a device like a stor­age array works the same way. I want to con­nect to the array and retrieve a list of LUNs. So, I have my pro­gram use some pre-built soft­ware code from the man­u­fac­tur­er, and now my lit­tle soft­ware pro­gram is con­nect­ing to the stor­age array and get­ting me a list of LUNs.

That is quite obvi­ous­ly a triv­ial exam­ple, but at a fun­da­men­tal lev­el that is all an API is: a bunch of soft­ware from some­one that allows your soft­ware to talk to their device. The API by itself con­veys noth­ing mag­i­cal or com­plete- remem­ber, you still have to write the code to do some­thing. It just gives you the abil­i­ty to access that device at a low­er lev­el (more direct) than you tend to get with com­mand line inter­faces, script­ing, and oth­er high­er-lev­el and more abstract­ed meth­ods.

An API does not mean the product is “open”

I’ve seen this idea float­ing around out there in some cir­cles. Some folks are con­flat­ing the idea of open source, or oth­er “open” ter­mi­nol­o­gy with the exis­tence of an API. The mere exis­tence of an API does­n’t con­fer any more open­ness than does a com­mand line inter­face.

A com­mand line inter­face allows you to con­trol the device in some way, using pre-built com­mands that do cer­tain things. An API allows you to do the same thing, but with your own soft­ware. So now you can build your own “CLI” off-box. Or you can auto­mate some activities–much like you can today with script­ing. An API is much more ele­gant, to be sure, but more open? No.

As a man­u­fac­tur­er, I can expose a lot of func­tions, meth­ods, 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 con­nect you to the box. How I con­nect you to the box, how­ev­er, might still be com­plete­ly hid­den away from you.

If you trust wizards, you’ll love you some API

How many of us have used the wiz­ards built in to the GUI of a device. Want a VPN from Seat­tle to New York? Here, I’ll ask you a ques­tion or two and then build it. Now, how many times has that actu­al­ly worked, and how many of us use the wiz­ards in most devices at all beyond the ini­tial curi­ous look-see. That’s the fun­da­men­tal prob­lem with this idea that an API allows all sorts of auto-mag­i­cal, auto­mat­ed, secret-sauce, fairy-dust­ed solu­tions to all of our prob­lems.

The man­u­fac­tur­er of a device has, the­o­ret­i­cal­ly, unlim­it­ed access to that device as they’re build­ing and devel­op­ing it. They can build the GUI, the CLI, and the wiz­ards to do any­thing they think the cus­tomer 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 glo­ri­ous. The lev­el of effort involved is dra­mat­i­cal­ly and con­sis­tent­ly under­es­ti­mat­ed by neo­phyte devel­op­ers.

In fact, when I’ve had this con­ver­sa­tion with expe­ri­enced devel­op­ers, this very idea always comes up. APIs, they say, are incred­i­bly use­ful and would be a nice-to-have or must-haves in most cas­es. No pro­gram­mer is going to turn down pro­gram­mat­ic access to a device. But, and there’s always a but in these con­ver­sa­tions, the incred­i­ble amount of effort it takes to get from hav­ing an API and a box to hav­ing a ful­ly inte­grat­ed, auto­mat­ed, reli­able and work­ing sys­tem is dra­mat­i­cal­ly under­es­ti­mat­ed almost uni­ver­sal­ly by non-developers–including most engi­neers and sys­tems folks in IT.

Final thoughts

There is a rea­son why the large-scale sys­tems of the past (the HP Open­views of the world) cost as much as a heli­copter to buy, con­fig­ure, install and actu­al­ly use. There’s a rea­son why both closed and open source projects in this space have hun­dreds and thou­sands of con­trib­u­tors work­ing on source code. It is incred­i­bly dif­fi­cult to devel­op sys­tems of dis­parate sys­tems that can reli­ably man­age any lev­el of automa­tion.

H.L. Menck­en once said, “Expla­na­tions exist; they have exist­ed for all time; there is always a well-known solu­tion to every human prob­lem — neat, plau­si­ble, and wrong.” I don’t think that the desire for an API in every pot is wrong or non-use­ful at all. As a long-time pro­gram­mer myself, I always pre­fer to have a pro­gram­mat­ic way to talk to any device I own- the more the mer­ri­er. How­ev­er, think­ing that just hav­ing every device in your net­work pro­gram­mat­i­cal­ly acces­si­ble some­how solves your automa­tion prob­lems, or reduces com­plex­i­ty, or stitch­es every­thing togeth­er for you is com­plete­ly, unequiv­o­cal­ly, and total­ly wrong.

It actu­al­ly sounds like the stuff of night­mares.

Share

August 27, 2013 Career Advice

Interview Questions I Hate — Part I

Read­ing Time: 2 min­utes

“So, why do you want to work here?”

If you’ve worked a day in your life, chances are you’ve been asked this ques­tion dur­ing an inter­view.  And, if you’re like the rest of us, you’ve said some­thing about how much you love the com­pa­ny, it’s your dream job, you’re look­ing to real­ly make your mark some­where, or some oth­er hack­neyed tripe that you hope sounds good to the per­son ask­ing the ques­tion.

I’ve spent a lot of time inter­view­ing peo­ple for my teams over the years, and I can tell you that your like­ly first instinct is right: the ques­tion is just about as worth­less as any­thing you could be asked in an inter­view. Every­one answers it the same way–with vac­u­ous gusto–and every inter­view­er hap­pi­ly ticks of a box as if you’ve passed some mag­i­cal “qual­i­fied to work here” test. But it’s crap and almost all of us know it.

I’ve per­son­al­ly nev­er used this ques­tion in any of my inter­views, but I always get asked this when I’m inter­viewed. I hate to say it, but I real­ly lose respect for folks when they use this ques­tion in an inter­view. I under­stand the osten­si­ble goal is to get to the heart of why this can­di­date picked your job post­ing to respond to, why they jumped through the hoops to get the inter­view, etc., but the fact is that in most cas­es it’s because you have a job open­ing and pay in actu­al dol­lars and not Monop­oly bills.

If you’re look­ing to get clos­er to what I assume the goal of this ques­tion is, you can change it up a bit and ask ques­tions like: “What about our com­pa­ny intrigues you?” or “How do you see your­self con­tribut­ing to the com­pa­ny?” or some­thing along those lines. At the end of the day, you’re look­ing to get beyond the point where you’re get­ting the same rote answer from every can­di­date.

Peo­ple have dif­fer­ent moti­va­tions for apply­ing to posi­tions.  Often they’re look­ing to move on because they don’t see any addi­tion­al oppor­tu­ni­ties where they’re at, they’re in a neg­a­tive work envi­ron­ment, or they’ve just topped out as far as the con­tri­bu­tion and val­ue they feel they can bring to the com­pa­ny they’re cur­rent­ly at.  Oth­er times it’s out of des­per­a­tion: they’ve just lost their job or feel they’re about to, they need more mon­ey for a vari­ety of rea­sons, etc.

Moti­va­tion is impor­tant, and I do under­stand the need to deter­mine the moti­va­tion of the per­son sit­ting in front of you. How­ev­er, I’ve always found it bet­ter to have a con­ver­sa­tion with the per­son rather than ask­ing the same ques­tions they get every­where else.  Just talk to them a bit, get to know where they’re at in their career and what they’re look­ing to do.

Oh yeah, and don’t ask any of those ques­tions like “How much wood would a wood­chuck chuck if he was on a train going 50mph in 0‑gravity, upside down?”  That moves you from hack­neyed to hack job.  Just say­ing.

Share

August 15, 2013 Career Advice

Coping with Difficult Bosses

Read­ing Time: 4 min­utes

Author Jan­ice Davies said, “dif­fi­cult peo­ple are your key to self empow­er­ment, you need to learn how to cope with them, not let them dom­i­nate and affect you.” But what if the dif­fi­cult per­son is your boss? What then?

In over 20 years of work­ing in my cho­sen career I have large­ly had what I can only sup­pose is the great­est luck in select­ing my boss­es. Most have been more than fair, have taught me along the way as true men­tors, and sev­er­al I still count as friends and advi­sors to this day. A cou­ple, how­ev­er, have tru­ly been night­mares.

Every­one has their own gauge for what makes a boss dif­fi­cult to work with, but mine comes down to more of a feel­ing than a set of con­crete habits. And when I say dif­fi­cult, I’m not refer­ring here to a demand­ing boss, or one who expects results and calls you out for not achiev­ing the results; that’s just the price of admis­sion in the cor­po­rate world. I’m talk­ing about when things reach a lev­el of dif­fi­cul­ty where you begin fear­ing for your job.

The prob­lems in deal­ing with dif­fi­cult peo­ple are, by nature, made even more dif­fi­cult when that per­son is large­ly in charge of your abil­i­ty to pro­vide for your fam­i­ly. Your stress lev­els can increase, you start tak­ing out your frus­tra­tions on the oth­er peo­ple in your life that you work with or care about, and your over­all health and out­look can become marked­ly more neg­a­tive, lead­ing to a decrease in pro­duc­tiv­i­ty.

Below are some strate­gies I have found that have helped me, and I hope that some or all can help you should you find your­self in the posi­tion of hav­ing to deal with a dif­fi­cult boss.

Adjust — As much as pos­si­ble, try to adjust to the new real­i­ty of the sit­u­a­tion. Some­times, as peo­ple are put in new posi­tions they can feel over­whelmed, under pres­sure, and are them­selves deal­ing with dif­fi­cult rela­tion­ships upstream. With any luck, this peri­od of dif­fi­cul­ty will pass and you’ll find that you’re able to cul­ti­vate a strong, trust­ed rela­tion­ship with your new boss.

Be Proac­tive — Try to antic­i­pate your boss­es needs before he or she knows they have a need. If they’re under pres­sure, and you can be the go-to-per­son that hands them reports, deliv­er­ables, etc., ahead of them ask­ing, you’ll have gone a long way towards eas­ing the rela­tion­ship into a bet­ter place.

A lot of times this comes from under­stand­ing your boss’s role in the com­pa­ny. For instance, I report to the CFO at my company–a role which is large­ly con­cerned with bud­get­ing, fore­cast­ing, and gen­er­al­ly deal­ing with the finan­cial health of the com­pa­ny. Every­thing that I do in the tech­ni­cal sphere is couched in terms of impact to the bot­tom line of the com­pa­ny. That’s a gross over-sim­pli­fi­ca­tion, of course, but the point is that you need to under­stand your boss, what their role in the com­pa­ny is, and how you can help to make them look good to their boss.

Don’t React Emo­tion­al­ly — I can’t tell you how many times after read­ing an email I’ve want­ed to walk down the hall to my boss’s office, storm in, and start loud­ly expound­ing on my view of the world and my boss’s place in it. I have seen that hap­pen, and while I some­times get a lit­tle joy in the vic­ar­i­ous­ness of the thing, I nev­er indulge myself in the same behav­ior. I respond even­tu­al­ly, but not quick­ly or emo­tion­al­ly.

I’m not sug­gest­ing you ignore emails, phone calls, mem­os, or ran­dom edicts at all. In fact, I have a gen­er­al rule of try­ing to respond to any­thing that comes my way by the close of busi­ness the same day. If it comes from my boss, I respond with­in two hours even after-hours. That said, you can acknowl­edge some­thing sim­ply, direct­ly, and with­out emo­tion. If, a few hours lat­er you still feel the need to have a con­ver­sa­tion, you’ll have giv­en the heat-of-the-moment emo­tions a chance to sim­mer down.

I have sent some seri­ous flame-throw­er emails in my day–some to ven­dors, some to co-work­ers, and even some to peo­ple I’ve worked for. Do you know the one thing every one of those emails in the last 20 years has had in com­mon? With­in min­utes or hours I regret­ted send­ing them–each and every one. A lit­tle bit of time would go by and I’d increas­ing­ly start feel­ing like the petu­lant child I was act­ing like. Almost inevitably I’d trudge off some­where to make an apology–not because I had to, but because I felt I need­ed to.

Learn from the Expe­ri­ence — Many of us either lead teams today, or will lead teams in the future. Even if lead­er­ship roles aren’t what you per­son­al­ly aspire to, the time will prob­a­bly come where you will find your­self lead­ing a team of some size. The expe­ri­ences you have with your boss­es should be sug­ges­tive of the type of leader you want to be. We all love the good ones, but some­times it’s the bad boss­es that teach us more in the end.

Know When to Walk Away — The rela­tion­ship you have with your boss should nev­er feel per­son­al­ly neg­a­tive. By that I mean that you should nev­er feel as if your boss **hates** you, or wants you to fail, or has no con­fi­dence in you as a per­son. Good boss­es will let you know if you’re not meet­ing expec­ta­tions long before it becomes an issue. If your boss is mak­ing your life mis­er­able with­out any sort of use­ful feed­back, then it’s like­ly one of two things is going on:

  1. They’re a mis­er­able prick, and want every­one who works for them to feel the same way.
  2. They don’t have the self-con­fi­dence to sit down with you and tell you that they have no con­fi­dence in you. So, they walk around with a mas­sive grudge, hop­ing that you’ll leave and they won’t have to deal with the prob­lem any longer.

In either case, this is prob­a­bly the point where you have to con­sid­er that things may not get bet­ter, and per­haps walk away. Work rela­tion­ships should nev­er be per­son­al­ly neg­a­tive, but we’re all human beings and some­times things just don’t work out. It’s irri­tat­ing, often feels unfair, but it’s the way things some­times are and we just have to deal with it as best we can.

What­ev­er you do, don’t fol­low your first instinct, and freak out. Don’t write up a nasty let­ter, or tell the per­son what you real­ly think. Just fol­low the process pro­fes­sion­al­ly, and if you real­ly need to vent a bit, that’s what your Human Resources depart­ment is for. Even then, how­ev­er, nobody likes a whin­er so try to keep your crit­i­cism as con­struc­tive, pro­fes­sion­al, and imper­son­al as pos­si­ble.

Then, do what I do: go home, kick off your shoes, pour a nice drink, and cel­e­brate your unbe­liev­able good for­tune to not have to deal with that boss ever again. Just don’t make a habit of it… after a string of bad boss­es, you might have to con­sid­er that the prob­lem was­n’t with them.

Share

August 11, 2013 SDN

SDN Myths

Read­ing Time: 6 min­utes

In 1876, an inter­nal memo at West­ern Union is report­ed to have read: “This ‘tele­phone’ has too many short­com­ings to be seri­ous­ly con­sid­ered as a means of com­mu­ni­ca­tion. The device is inher­ent­ly of no val­ue to us.” At the time, West­ern Union was the Microsoft of its day–a behe­moth com­pa­ny that touched every­one’s lives. While the verac­i­ty of that quote is ques­tion­able, the fact remains that after los­ing a patent law­suit to Bell Tele­phone in 1879, the West­ern Union shift­ed its focus to mon­ey trans­fers. To put it anoth­er way, the entire busi­ness mod­el upon which West­ern Union was pred­i­cat­ed, col­lapsed to a new, dis­rup­tive tech­nol­o­gy that the lead­ers of the busi­ness failed to cap­i­tal­ize on.

While this has impor­tant lessons for busi­ness lead­ers today, we often see an almost reflex­ive reac­tion to new tech­nolo­gies in the oth­er direc­tion. We get in such a both­er try­ing to divine the “next big thing” that we almost entire­ly fail to qual­i­fy the claims that are being made and end up bet­ting the bank on unproven or half-baked con­cepts.

I’m cer­tain­ly not say­ing that SDN is any of these things, but rather that there are a lot of myths and mar­ket­ing fog­ging up the land­scape. I actu­al­ly believe that SDN–in at least some of its pur­port­ed definitions–will most def­i­nite­ly make it into the net­works of tomor­row, and fur­ther that sev­er­al things will change as a result. I don’t, how­ev­er, buy into a lot of the myths that seem to have devel­oped sud­den­ly, out of the ether, around the tech­nol­o­gy.

I should also point out that the myths below are some of the more com­mon ones I hear, but tak­en in total­i­ty don’t nec­es­sar­i­ly rep­re­sent any one com­pa­ny’s vision of SDN. There are many com­pet­ing tech­nolo­gies and com­pa­nies claim­ing the man­tle of SDN which, in many cas­es, are com­plete­ly at odds with one anoth­er. Is SDN the abstrac­tion of the for­ward­ing plane from the con­trol plane? Is it pro­gram­mat­ic access to net­work devices? Is it automag­i­cal def­i­n­i­tion of pol­i­cy across abstract­ed for­ward­ing planes–boxes of dumb pipes manip­u­lat­ed by con­trollers? The answer is, it depends on who you ask and what they’re sell­ing. Myths abound, no mat­ter from which per­spec­tive you look, and we’re going to debunk a few now.

SDN is a Use­ful Term — I don’t think so, no. I think the term is “mar­ke­tec­ture” and is large­ly mean­ing­less beyond very high-lev­el dis­cus­sions. There are so many com­pet­ing visions of not only how to “do” SDN, but of what it even means that large­ly the catch-all term has lost its use­ful­ness for an engi­neer­ing-lev­el dis­cus­sion. Estab­lished com­pa­nies are com­pet­ing with start-ups, with one anoth­er, and in some cas­es inter­nal­ly to define what SDN is and what it is not. A lot of these ideas will end up in prod­ucts and tech­nol­o­gy that will even­tu­al­ly be for sale, while many will fade or become noth­ing more than slight busi­ness dif­fer­en­tia­tors in incre­men­tal­ly improved hard­ware. As it stands today, SDN as a term is noth­ing more than the cloud of this year–the thing-du-jour that every com­pa­ny can’t wait to shoe-horn into every mar­ket­ing slide and prod­uct-line they have. It is itself devoid of mean­ing or use­ful­ness. That’s not to say that the com­po­nent pieces of any of the amal­ga­ma­tions of def­i­n­i­tions aren’t them­selves extreme­ly useful–they are–but rather that the term is not use­ful.

SDN reduces com­plex­i­ty — For those preach­ing the “less com­plex­i­ty” vari­ant of SDN, I’d say that you need to look at his­to­ry. Did the advent of vir­tu­al­iza­tion increase or decrease over­all com­plex­i­ty in the com­pute space? It increased it, of course, by sev­er­al orders of mag­ni­tude. The same goes for stor­age abstrac­tion, and the same will hap­pen with SDN. We may or may not gain effi­cien­cies and flex­i­bil­i­ty, but we most assured­ly will not gain sim­plic­i­ty.

SDN elim­i­nates Net­work Engi­neers - This is patent­ly sil­ly on mul­ti­ple fronts, but let’s just go with the eas­i­ly picked and obvi­ous nit to begin with: SDN is pred­i­cat­ed on hav­ing a robust net­work archi­tec­ture under­pin­ning it. In oth­er words, you can’t have soft­ware-defined any­thing until you have an infra­struc­ture in place to build on. That infra­struc­ture is going to be com­plex, high­ly spe­cial­ized, and not at all sim­ple to design, build, or main­tain. Day-to-day change man­age­ment will like­ly be done by less qual­i­fied folks, but you’ll still have a place for skilled engi­neers in the same place where they oper­ate today: design, build-out, and trou­bleshoot­ing com­plex envi­ron­ments.

SDN low­ers costs — Based on past expe­ri­ence, I don’t think this will ever be true either. Peo­ple will con­flate the down­ward pres­sure on pric­ing and the fur­ther com­modi­ti­za­tion of all aspects of hard­ware with a low­er­ing of costs direct­ly because of SDN, but this is incor­rect. It is incor­rect in the same way it would be wrong to say that the abstrac­tion of com­pute and stor­age in any way low­ered over­all costs.

To make sense of this you real­ly have to start look­ing at 5 and 10 year his­tor­i­cal costs (or even 15) to see what has hap­pened. And what that looks like is a sim­i­lar cost pro­file as a com­po­nent of oper­at­ing prof­it, but with a large increase in effi­cien­cy. I’ll say that anoth­er way, you’re not low­er­ing your true IT costs over time… you’re increas­ing your effi­cien­cies.

Why does increas­ing effi­cien­cy not low­er over­all costs? Because you rapid­ly fill the gap with new capa­bil­i­ties. Any­one who has seen a tran­si­tion from bare-met­al servers and stor­age to vir­tu­al­ized work­loads, servers, and SANs has also seen the corol­lary of serv­er sprawl. How many of us have col­lapsed thou­sands of bare-met­al servers only to see the total num­ber of VMs increase even­tu­al­ly?

Oh, and now you have a team of stor­age engi­neers, and a team of vir­tu­al­iza­tion engi­neers, and you still have the serv­er, net­work, DBA, ERP, help-desk, etc. from before you vir­tu­al­ized.

There are a lot of ways to frame or quan­ti­fy the cost-sav­ings claims in SDN, but I think a bet­ter and more accu­rate descrip­tion might be that SDN will like­ly increase effi­cien­cies. You’ll be able to do more with less, but you’ll fill the gap so quick­ly that any cost sav­ings you think you’ll get will get eat­en before one bud­get cycle is up. Like­ly you’ll have a large CapEx spend to do a fork-lift upgrade, and that will take 3 years to bal­ance out and come off the books. In the mean time, you’re going to increase OpEx because of train­ing, ini­tial devel­op­ment, net­work redesign, etc. By the time your feet are firm­ly plant­ed, you’re com­fort­able with the new look of things, and you’re ready to start count­ing the pen­nies “sprawl” of a new type (devel­op­ment costs most like­ly) will eat any sav­ings. That’s a 3 to 5‑year cycle just there.

SDN mit­i­gates change man­age­ment risk - This one is only par­tial­ly a myth. For the bulk of change man­age­ment, I’d say that this is quite like­ly com­plete­ly true. Day-to-day port changes, rout­ing changes, and pro­vi­sion­ing (to name a few) are eas­i­ly screwed up by the less expe­ri­enced folks like­ly mak­ing those changes today. Hav­ing a sys­tem that can make the changes with less man­u­al input is going to prob­a­bly save a lot of the lit­tle ticky-tack prob­lems that crop up from some­one fat-fin­ger­ing a con­fig­u­ra­tion com­mand.

Larg­er changes to a net­work are like­ly going to fall out­side of the scope of what SDN brings to the table, espe­cial­ly in mul­ti-ten­ant or high­ly com­plex envi­ron­ments. These are the types of changes you still are going to need a high­ly skilled team to imple­ment, and I don’t see a point com­ing soon where I’d real­ly feel com­fort­able trust­ing large-scale changes to an automag­i­cal, large­ly self-dri­ven sys­tem. Even today, how many of us trust the soft­ware “wiz­ards” built into any com­mer­cial­ly avail­able prod­uct? How many of us make whole­sale, sys­tem-wide net­work changes using a wiz­ard? Sim­ply chang­ing the name to SDN does­n’t change any­thing.

SDN is dis­rup­tive tech­nol­o­gy — IT is, almost by def­i­n­i­tion, filled with peo­ple who take a “down in the weeds” view of every­thing. It has to be. But some­times this leads to a kind of unique myopia in view­ing changes in tech­nol­o­gy. When Mul­ti-pro­to­col Label Switch­ing (MPLS) was intro­duced, it was as dis­rup­tive to the sta­tus quo as any­thing, but it was adopt­ed slow­ly, peo­ple adapt­ed, nobody lost their jobs and whole indus­tries weren’t erad­i­cat­ed. Why? Because from the busi­ness point of view it was just a more effi­cient way of solv­ing the same old prob­lems. It was bet­ter than what it replaced, but it was incre­men­tal­ly bet­ter. In oth­er words, it was­n’t the tele­phone to West­ern Union’s tele­graph.

SDN in all its myr­i­ad visions, and as evan­ge­lized by all of its new­ly chris­tened cham­pi­ons, is fas­ci­nat­ing, emi­nent­ly use­ful on some lev­els, and mad­den­ing­ly sil­ly in oth­ers. At the end of the day, how­ev­er, it’s crit­i­cal that we don’t get so involved in the excite­ment, promise, and reli­gious fer­vor of new tech­nol­o­gy that we lose sight of what is real, what is use­ful, and what is “mar­ke­tec­ture”. Mag­ic beans may have worked for Jack, but I’m not buy­ing any for my net­work. Yet.

Share

August 6, 2013 Apple

My OSX

Read­ing Time: 5 min­utes

I have decid­ed to take a quick break from my more busi­ness-ori­ent­ed writ­ing of late to focus on some­thing that peo­ple seem to have an inter­est in: how I have my com­put­er set up and con­fig­ured. This post will nec­es­sar­i­ly be in more of a cat­a­log for­mat than arti­cle, but hope­ful­ly no less use­ful.

I switched to a Mac a few years ago, com­plet­ing the cir­cle of com­put­ing life as I did, as I start­ed with an Apple IIc around 1981. In between I fell in love with var­i­ous com­put­ers from the Ami­ga, Atari ST, ear­ly IBM machines, to Lin­ux and final­ly to the pin­na­cle of all things com­put­ing: the NeXT. Ever since then I think I have been sub­con­scious­ly try­ing to get my desk­tops to look as flu­id and work as well as the NeXT machines did, with vary­ing lev­els of suc­cess. Some of my choic­es reflect that impulse.

I will pref­ace this by say­ing that this is how I have my com­put­er set up and con­fig­ured, and is by no means the right way–it just works for me. The soft­ware I use is what I find inter­est­ing or use­ful to my work­flow and style, but I am always look­ing for improve­ments. This cat­a­log, then, will prob­a­bly be out of date five min­utes after I’m done writ­ing it all down.

Mail

Microsoft Out­look. I have installed and used Post­box, Thun­der­bird, and a cou­ple of oth­ers, but I keep falling back to Out­look. Per­haps it is a lit­tle bit of the Stock­holm Syn­drome (though not IPv6 Stock­holm Syn­drome), but I can’t seem to find any­thing else that match­es every­thing fea­ture-for-fea­ture that I need. It’s all a com­pro­mise some­where, some­how. With Out­look I have to put up with the usu­al Microsoft Bloat, but I com­pen­sate with a lot of mem­o­ry and pro­cess­ing pow­er.

Web Browser

Google Chrome. I’m sure some­one will cas­ti­gate me for this (as if the last sec­tion was­n’t bad enough) but I just find that it works well, is light­weight, and does every­thing that I want rea­son­ably well.

Remote Desktop

Cord is my go-to for con­nect­ing to remote Win­dows servers, though this is always in flux. I do much more via Pow­er­Shell than ever before, so pure Remote Desk­top Pro­to­col just does­n’t get used as much as it used to in my envi­ron­ment.

Organization

Ever­note is my main tool in the “remem­ber­ing stuff” cat­e­go­ry of tools. I use it to grab and cat­a­log things that I find inter­est­ing or use­ful. I use tags and dif­fer­ent note­books and such with­in the tool, and it suits me nice­ly. I did switch to the pre­mi­um edi­tion quite a while back, and it’s well worth it as far as I’m con­cerned.

Twitter

Tweet­bot and some­times my own com­mand-line client (writ­ten in Python as a learn­ing exer­cise) if I’m feel­ing plucky.

Text Editors

TextE­d­it, VIM (though I use a fair­ly cus­tomized ver­sion and con­fig­u­ra­tion, more on that lat­er).

Markup Tools

A lot of these tools revolve around spe­cif­ic tasks. For instance, I use Mark­down Pro to com­pose all of my blog posts, this one includ­ed. It gives a nice appear­ance to things with­out a lot of the fuss and extra bag­gage of full-weight word-proces­sors, and I can export the com­plet­ed work in HTML or PDF for­mat. Not par­tic­u­lar­ly fan­cy, but it gets the job done. My only com­plaint here is that the for­mat­ted por­tion of the screen (split-screen com­pos­ing win­dow) does­n’t keep up with the raw-text side. Minor annoy­ance, but if I could find some­thing that solved this I’d prob­a­bly switch prod­ucts.

I also use BBE­d­it for some things, though I’m find­ing I use it less these days than a cou­ple of years ago. It’s def­i­nite­ly one of those tools you either learn and love, or hate. There’s a fair­ly steep bar­ri­er to entry in both price and learn­ing, but you may find it use­ful for its syn­tax high­light­ing, script­ing, etc. More use­ful for raw code edit­ing (HTML, XML, C, etc.) than for arti­cles and such.

LaTeX has been my go-to for any kind of seri­ous doc­u­ment cre­ation (resumes, man­u­als, schol­ar­ly papers, etc.) for years now. I will warn you that it is absolute­ly not for the feint of heart as it is basi­cal­ly an old pro­gram­ming lan­guage for doc­u­ment markup. Most Mas­ters and PhD the­ses are writ­ten in this lan­guage, as are most schol­ar­ly research papers. It is well worth learn­ing, and once you do you’ll nev­er use any­thing else as it cre­ates the most hands-down beau­ti­ful doc­u­ments you’ll ever find. A lot of peo­ple will be turned off by the steep learn­ing curve (you have a lot of code to learn, and a lot of com­pil­ing to even get a view­able doc­u­ment) but if you have the patience, go for it.

The link above is to an OSX-spe­cif­ic set of pack­ages, and I rec­om­mend you start there. You can also look at The LaTeX Project and a nice Doc­u­ment Guide/Wiki to get start­ed. The CTAN Archive is a great place to browse for pack­ages and what­not. Hap­py hunt­ing!

Terminal Emulators

iTerm2 Solarized

iTerm2 Solar­ized

I use iTerm2 instead of the built-in ter­mi­nal pro­gram shipped with OSX. It has many nice fea­tures (too many to list), is more cus­tomiz­able, and is just bet­ter. Go get it. You’ll thank me. While you’re at it, get the Solar­ized pack­age and install it for every­thing you have. In addi­tion to a uni­form col­or palette, it helps across the board with aes­thet­ics when work­ing in any of the sup­port­ed appli­ca­tions.

 

Integrated Development Environments (IDEs)

I use two pri­ma­ry tools for cod­ing on my Mac: XCode when I’m doing some­thing using the Cocoa Frame­works (not often) and Komo­do IDE 8 for every­thing else (most­ly Python these days). Your choic­es here are like­ly to be high­ly per­son­al depend­ing on how much pro­gram­ming expe­ri­ence you have or are like­ly to do, and in what envi­ron­ments. You can do any kind of pro­gram­ming or script­ing in any kind of text edi­tor, of course, but I find a nice IDE to be a com­fort­ing thing to have around. I also have my VIM install con­fig­ured with syn­tax high­light­ing for the lan­guages I use.

Sundries

I use a ton of oth­er pro­grams from Wire­Shark to Drop­Box to get my work done; VPN clients, var­i­ous pho­tog­ra­phy suites (anoth­er hob­by of mine), to things like 1password for pass­word stor­age. Unfor­tu­nate­ly, this post is longer than I expect­ed already so I’m stop­ping it here. I’ll come back with a part II soon, and hope­ful­ly there I can include all rel­e­vant por­tions of my actu­al con­fig­u­ra­tions (.vim­rc, screen­rc, tmux_conf, .bashrc, .pro­file) as well as all of the OSX-spe­cif­ic hacks I’ve made over the years to get my Mac to behave like I want it to.

In the spir­it of giv­ing back, I’d love to hear from any­one else as to what nifty soft­ware, con­fig­u­ra­tions, 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 sug­ges­tions and bet­ter ways of accom­plish­ing things.

Share

August 1, 2013 Uncategorized

SDN in the Enterprise

Read­ing Time: 1 minute

I recent­ly wrote a mul­ti-part blog series for Cis­co and, as we know, while it may seem like the writ­ing is all of the work, get­ting the word out is at least as hard. So, for those of you who have already seen this, I apol­o­gize. For the rest of you, I have includ­ed a link below.

This first part large­ly sets the stage, while the sec­ond part (com­ing on August 14t) will draw more con­clu­sions. Com­ments are wel­come, as is word-of-mouth adver­tis­ing. 🙂

Thanks, every­one!

SDN in the Enter­prise

Share
  • « Previous Page
  • Page 1
  • …
  • Page 4
  • Page 5
  • Page 6
  • Page 7
  • Page 8
  • …
  • Page 14
  • Next Page »

Copyright© 2022 · by Shay Bocks