[Info-vax] Some questions on software for VMS 7.3 VAX (Stephen Hoffman)

[Stephen Hoffman]

On 2016-01-11 14:44:06 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> 
>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
>> 
>> Stephen Hoffman via Info-vax
>> 
>> Sent: 10-Jan-16 9:21 PM
>> 
>> To: info-vax at info-vax.com
>> 
>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>> 
>> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3
>> 
>> VAX (Stephen Hoffman)
>> 
>> 
>> 
>> On 2016-01-11 01:36:38 +0000, Kerry Main said:
>> 
>> 
>> 
>> 
>> 
>>> Case in point - HPE's new Server Mgmt product that replaces HP SIM and 
>>> other similar HP server HW mgmt. and monitoring utilities is called 
>>> "HPE  OneView". OneView ONLY supports specific ProLiant blade, rack 
>>> servers  running Windows or Linux and HPE storage and some network 
>>> switches.
>>> 
>> 
>> 
>> That's not new.   The HPE vendor monitoring tools and error-processing 
>> tools and related seem to get rebranded or replaced every three to five 
>> years or so.   Not that DEC and Compaq didn't also change out these and 
>> related tools, too.   Not that open-source tools also don't get 
>> shuffled around or abandoned, as well.      As for server monitoring, 
>> more than a few folks are using some combination of Nagios/Icinga, 
>> Cacti, Groundwork, Zabbix, Munin, OpenNMS, or otherwise.   There were 
>> Nagios NRPE bits for OpenVMS, and likely some others.
>> 
> 
> 
> And that is why the DC config mgmt. world is such a mess. Each group 
> thinks they know better than the other group what is best from a 
> systems and network mgmt. perspective. Tools tend to grow from each 
> group, not as part of an overall service management strategy.

So we shift from HPE's changes in tools and strategy to the changes in 
end-user tools and strategy.   Okay.  For the major hardware vendors, 
each one pushes their own tools.   That's their value-add.   The 
second-tier hardware vendors tend to push more of the de facto 
standards and open-source tools.

Bottom-up enterprises always get software weeds and software thickets, 
and divisions or groups can diverge from whatever corporate policies 
and tools are in use.  What some folks have called Shadow IT.   
Top-down enterprises always get generic tools that are almost 
inherently ill-suited for some particular local requirements and which 
then means the local requirements can get ignored, or expunged and 
standardized.   There's no right answer here, either.  Standardized 
responses and solutions have better costs at scale, but the migrations 
and the replacements are vastly larger projects and can be a budget 
killer.  (The budget-killing project weeds with distributed and Shadow 
IT tend to be a whole lot less visible, individually.)

> As an example - few groups understand that you need an Operations 
> Bridge function that takes events, alerts etc. from many tools, filters 
> them, correlates them and then does smart processing to determine if 
> events  are symptoms or causes of the issue.

Who isn't running something like syslog or syslog-ng or related for a 
production network, after all?   Other than smaller-scale OpenVMS users 
— who have to port and integrate those tools — that is.

The inability to easily integrate OpenVMS into networks makes new 
OpenVMS deployments into existing heterogeneous environments more 
effort.

This as somebody around here that has been grumbling about the lack of 
OpenVMS integration for a while, as well as the effort involved in 
managing installations, the difficulty of managing herds of OpenVMS 
servers, the limited usefulness of LDAP on OpenVMS, etc.   OpenVMS 
leaves you with a limited box of tools, and the end-user or the 
integrator then gets to build a workable system — without the installed 
base and without sorts of libraries and tools and add-ons and technical 
postings that were once what you'd find via DECUS — you get to do all 
the work, often as a one-off.   Or — has happens — you pick a different 
platform which already has these capabilities and where you don't need 
to do quite as many one-off projects, and retire the OpenVMS boxes.   
More than a little of this stuff is part of what's now marketed as 
"cloud management", after all.

> Once processed, notification should be sent to the right group to take 
> action and info only notification is sent to  those groups impacted, 
> but who need not take any action. Without this,  you get ticket bounce 
> i.e. event happens and all groups scramble to fix the event e.g. switch 
> dies and App, Storage, Server, Network groups all  scramble before 
> someone eventually determines it is a network issue.

ML is getting better but ain't there yet.   The folks providing coroner 
duty or triage will still guess wrong, too.

> The more mature IT groups will also integrate these processed alerts 
> with their service desk (smart ticketing), but that requires 
> communication & cooperation between groups and that unfortunately is in 
> short supply in many companies today.

It's often in short supply because the current messy solution works 
well enough that the more efficient and elegant and integrated solution 
isn't viewed as a benefit to justify the expenses.   Management gets 
paid to make trade-offs, and — for more than a few decisions — all the 
choices can be bad.

> What usually happens is companies spend a lot of $'s (prod's, resource  
> time) on products without really having a good overall and proactive 
> service management strategy in place. A year after spending big $'s on 
> tool projects, execs typically are frustrated because they do not see 
> the  returns or efficiencies they expected. They fail to understand 
> that the 
> 
> custom work required to do the smart event filtering and correlation is 
>  very customized and requires lots of time (internal or external 
> resources)

Ready-Fire-Aim has a very long history in business management.

> Note - part of a service management strategy involves tools 
> consolidation and that can be almost as politically sensitive as server 
> consolidation, but that’s a different discussion.

Ayup.   These quite commonly involves platform consolidation, too.   
Which is part of why OpenVMS is declining.   Beyond the insecurity and 
the logging, OpenVMS just doesn't play well with others.  Adding a 
third OS team to your existing Windows and Linux OS support teams isn't 
very popular, and that's before discussing the hardware or emulation 
requirements for OpenVMS.



-- 
Pure Personal Opinion | HoffmanLabs LLC