[VoiceOps] [LIKELY JUNK] Acme: EMS or CLI?

[Alex Balashov]

David Hiers wrote:

> Acme is a victim of their own success on this one.  It's so easy to
> manage the SDs over the CLI for a handful of boxes, and it plugs into
> our overall monitoring strategy so well that I've never thought of
> what I'm missing with the EMS.  Size matters, so if we had a oodles of
> them it might be a different story.

Aside from that, there is a generally pointless and misguided 
preoccupation throughout all departments of IT and communications with 
GUI administration tools and abstraction layers for everything.

GUI tools are appropriate if - and only if - (1) they simplify a task so 
that lower-skilled people can be hired to do it as part of business 
processes replicated at decreasing marginal cost, or (2) if they make a 
task more efficient to perform.  The latter is usually predicated on 
there being some level of unnecessarily granular detail that can be 
encapsulated in most common use cases.

Anything truly complicated and granular at once will require a GUI that 
is equally complicated and granular, which is a waste of time and 
resources for both the vendor in producing it (and keeping it 
synchronised with the core product) and for the user in having to attain 
proficiency in learning the roundabout ways of the GUI.  At that point, 
it's simpler to just use the CLI or other some-such allegedly "crude" 
interface.

This obsessive fixation with GUIs, GUIs, GUIs for everything reminds me 
of many a misguided, disastrous "business process language" undertaking 
in the enterprise world, where an obsessive methodological preoccupation 
with divesting "programming" from "business logic" and/or the "business 
layer" leads to complicated domain-specific input with fat 
specifications, all in the name of supposedly protecting "business 
people" from having to write any actual code, per se.

The end-result ends up being more obfuscated, conceptually elaborate, 
and intellectually demanding than just sitting down and writing code, 
and, in fact, the skills required turn out to be suspiciously similar to 
programming.  The sort of thing that is BPEL and 
business-XML-such-and-such are good examples, and by far not the worst. 
Only now, it operates through an obese, lumbering interpreted mediation 
layer, requires expensive and time-consuming care and feeding 
(maintenance), and creates a hard bound on flexibility limited by that 
subset of the original programmatic options that are exposed by the new
"interface."

> Along these lines, has anyone ever cooked up a decent perl module to
> work with the selecting and such needed to modify the config?  It'd be
> pretty sweet to can some module that can work with their CLI paradigm
> as well as expect or net::telnet.

I've written a number of such Perl scripts in the past to accomplish 
specific goals, but nothing in the way of a generic interface or 
general-purpose interaction layer.

-- Alex

-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671