Re: Network device command line interfaces

[Steve Gibbard <scg () gibbard org>]

What this really comes down to, I think, is figuring out how your "gut level" concerns fit into the big picture, and to 
then put that into terms that the people responsible for the big picture can use to make a good decision.

Finances do matter.  Getting your employer to spend money it doesn't have to on network equipment generally means 
there's less money available to spend on other things that might matter, like making your network bigger, hiring people 
to help you, or even keeping you employed.  If you want to spend more on equipment than the bare minimum, you ought to 
have a reason.  To get anybody else to come to the same conclusion, you ought to be able to explain that reason.

That said, I think it's valid to buy something because you're comfortable with it, and valid to not buy something 
because you're not comfortable with it.  "I don't want to buy new device X because I don't want to have to learn how to 
use it" sounds lazy, but most of us are busy, and if the device you're comfortable with will do the job for an 
affordable price, it's generally good not to create extra work for yourself.

Saying "we shouldn't do that because I don't know how" is hard.  It may be because something is new and complicated, 
and nobody has experience with it.  Or it may be because you're not familiar with it when lots of other people are.  
You may have a different specialty, or it may be because you're less experienced than the people they could have hired 
if they'd paid or shopped around more.  But, your expertise or lack thereof is a legitimate thing to take into account 
when making decisions, as is the likely expertise of people who will have to manage the system in the future.

Unfamiliar network equipment is expensive to manage, whether the CLI is well done or not.  Even in a one person shop, 
you won't yet have encountered the device's pitfalls -- its easily circumventable bugs, the configurations that seem 
intuitive but aren't, etc.  It's going to take you longer to design and configure your networks, and you're going to 
create problems by doing the wrong thing more often.  You're probably going cause some outages, or even buy equipment 
and then find that you missed something and need to buy something else.  If you work with a large team, and maybe even 
have NOC people working the night shift in another location supporting the thing, it gets worse.  All those people have 
to be trained on the new device, and come up to speed on it.  

It's also good to understand the reliability requirements for something you're building.  We don't have licensing 
requirements for Network Engineers, but some other more established engineering professions do.  If a structural 
engineer signs off on a building despite being unfamiliar with some aspect of the construction technology and the 
building collapses, that can be career ending.

Internet networks that have become pretty important too.  If you're building a network where a failure will cause a 
heart attack victim to not be able to call 911 from their VOIP phone, it isn't good enough to say "I've never seen this 
piece of equipment but I don't have any reason to think it won't work."  If you're building a network to connect some 
office PCs, the stakes are probably lower.

And, of course, there's also the option of learning about unfamiliar technology. Play with it in your lab.  Put it in a 
peripheral site that can fail without causing too many problems.  Get your NOC staff familiar with it.  And maybe, in 
the end, you'll find that you actually like it.  That it does something your old hardware doesn't.  That cheap hardware 
lets you afford a level of redundancy, and thus reliability, that was simply unaffordable with you're previously 
preferred equipment.

But that testing and familiarity has a cost, just as buying expensive equipment does, and just as running unfamiliar 
equipment does.  It's a matter of balancing it all out, and coming to an agreement with your management on what the 
best strategy is.

-Steve

On Nov 25, 2011, at 8:15 AM, Joel Maslak wrote:

> On Fri, Nov 25, 2011 at 12:01 AM, Robert Bonomi <bonomi () mail r-bonomi com>wrote:
>
>
> > The trick to deailing with this as a propellorhead[sic] is to include a
> > *monetized* estimate of the increased manpower OPEX of using the 'dog to
> > work with' box.  And a TCOS figure over the projected lifetime of the
> > units.   No need to 'fight' with management about it, just understand
> > 'how'  they make the decisions, and give them the informatin they need
> > to make the decision come out 'your way'.
>
> I'd say that the ethical thing to do is to give them the information they
> need to make a decision, not to get it your way.  I see, for instance,
> people buying local closet switches from brand A when brand B is much, much
> cheaper (but lacks the prestige of brand A), had a perfectly workable
> management interface, and will perform identically, with similar support
> offered by both vendors.  But they are an ACNA or whatever, or they've just
> heard of (insert brand here), so they buy it.  Because it's easy and
> familiar.
>
> It's also possible that a web managed switch (which I despise) might
> actually be the right choice for a business - because factors other than a
> technologist's distaste might be important.
>
> Part of being ethical (and NOT like the business people we might all
> despise!) is to be honest.  So we don't compare brand A to brand B
> unfairly.  We don't inflate the cost of brand B by adding brand B's
> management infrastructure to the cost when we darn well know we just will
> need a minor tweak to our scripts that can already manage brand A.  That
> sort of thing.
>
> I generally agree with what Robert said: It's about what makes sense to the
> business.  If operating expenses will increase ("Well have to grow
> headcount by 3 to support this"), then bring that up.  A caution though:
> "Takes less effort to run" doesn't equate to dollars (the question a former
> manager would ask me when I tried that line was, "So who do you think we
> should lay off then to get the dollar savings?"  Fortunately he was a good
> manager who wasn't serious, but was rather trying to get me to think about
> what I'm saying).  I like paychecks, which is why I work for a living -
> it's about the dollars.  So it's not unreasonable for my management to also
> care about the money (since it's a key motivation for myself, after all!).
> Yes, I'm fortunate to do a job I love and get paid for it at the same time.
>
> I can say, for a CUI interface, operations over low-speed links (wireless
> VPN when I'm away from the office and in a bad cell zone, for instance) is
> likely important.  So is ability to script common tasks to allow people
> like the help desk to do their jobs at low risk.  Flexibility is also
> important - when I'm stuck with this piece of gear (which is shiny today)
> in 5-7 years, when it's not so shiny, is it going to have flexibility to
> last a bit longer if the business needs to conserve cash - or will a minor
> change in how we do business make this thing functionally obsolete?
>
> Relating to the discussion on the tier 1 mentor thread, someone who wants
> to go far in networking won't be married to a particular vendor or way of
> doing things.  They'll excel and find ways to overcome challenges,
> including less than perfect equipment, that they might have to deal with.
> They'll do so in a way that makes the customer and their own management
> happy.  A highly paid network engineer who complains about work being
> difficult probably won't do that.  One that finds a $500 replacement for a
> $5000 router probably will stick around, provided they can actually deliver
> what they promised (the guy that puts the $500 replacement in only to have
> to replace it in a year with a $5000 router again won't go far, so be
> careful! And you better have figured in the real costs of running a network
> with $500 routers, not just the cost of the router).