[Info-vax] Where to locate software

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 10-Jun-16 5:48 PM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Where to locate software
> 
> On 2016-06-10 20:54:52 +0000, Kerry Main said:
> 
> >
> >
> > On the contrary, I view App Stacking as the way of the future in order
> > to  address both VM sprawl and significantly reduce server-server
> > latency.
> 
> Yes, it is.  No question.    At least until you're undercut by changes
> to the underlying license prices.   Which will kick the pins out from
> underneath more than a few of these discussions.   The difference being
> that your approach to app stacking — what's out there now, on
> OpenVMS —
> is an increasing to massive hassle to deal with beyond even a couple of
> OpenVMS hosts.    As currently "implemented", OpenVMS "app
> stacking" is
> a festering carbuncle of grief.   But I'm being polite, having chased
> around more than a few of the interactions among disparate apps over
> the years, ranging from the DECC$ logical names to differences of
> opinions around the required system parameter settings across
> disparate
> applications to finding that reinstalling an an app was the easiest way
> to deal with a host name change to dealing with conflicts around
> different patch requirements, and that's before discussing dangling
> files and settings and the remainder of app cleanups, and the utter
> morass of manually-maintained startup files.   You can keep telling me
> that this current septic tank is acceptable and even the wave of the
> future, and I'll keep my hip waders on when dealing with it and will
> keep asking for a hazmat suit and air supply.   At least until the
> septic tank gets drained and the OpenVMS version of "app stacking" gets
> rethought and redeployed.
> 

Well,  I have been on support calls and project engagements for mission
critical OpenVMS customers (stock exchanges, banks, power utilities, 
manufacturing sites, government sites (like ones where you are escorted
to the washroom) all over the globe for over 30 years. They are usually 
rock solid, well planned solutions and they typically all run more than one 
business application on the same OS/cluster - often using a common 
system disk because it is just so much easier from a config management
perspective.

Yes, proper resource naming and application planning Is part of this. 

Yes, you need experienced folks to do this planning. 

Course, you do not design new buildings with rookies either. You do it
with experienced resources who often have different ideas of how to
adapt previous best practices to the requirements of the current project.

However, I would argue shared nothing architectures (Windows, Linux, 
UNIX) in distributed db's require much more up front planning because 
how you split up your Apps servers and especially data is critical. If hot 
spots occur due to unexpected loads in a few areas, then it becomes very 
difficult to address because you either increase that specific server size 
(and its designated backup) or re-partition the data or provide error 
messages to the client - the proverbial "server busy - please try later".

This is the same reason btw where NonStop solutions run into major 
issues because it is also a shared nothing architecture. Course, in their
environment, they are very good at estimating target workloads in one
of their typical financial workload scenarios.

Re: pricing- agree that current pricing strategies is an issue that needs to 
be addressed at some future point.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com