[Info-vax] OpenVMS app stacking (was: Re: OpenVMS servers and clusters as a cloud service)

[Stephen Hoffman]

On 2018-01-01 18:03:47 +0000, Arne Vajhj said:

> On 1/1/2018 10:45 AM, Kerry Main wrote:
>> With OpenVMS, it is very common to run many Apps on one OpenVMS instance.
> 
> It certainly was 30 years ago.
> 
> But I am not so sure today.

We aren't always in thirty-year-old environments, either.

Try getting a dozen apps that all need to run TCP 443 HTTPS playing 
nice together, some with their own in-built web servers and some using 
Apache, and with a mix of Tomcat apps all expecting to accept client 
connections into TCP 8080 and with the clients not using DNS SRV 
records or PortMunger.   The cherry on top are some apps that are 
mis-coded to have mismatched DECC$* default settings requirements, but 
the libraries are old and the third-party dependencies are hard-coded.  
Oh, and two of the dozen require the same hardcoded username and 
conflicting UIC values for entirely different implementations, because 
of a now-ancient shared dependency, and which means they're all in the 
same group table.   And one app has an un-prefixed logical name that it 
needs and that unfortunately conflicts with the filename of a data file 
in an unrelated app.   Several of the dozen have differing ideas of 
what the OPENSSL logical name should be referencing, too.  Etc.

No.  I won't ask you to get the apps among that dozen that are 
currently also using TCP 80 HTTP moved over to TCP 443 HTTPS, because 
the audit folks just flagged the against-policy use of HTTP.

And I definitely won't ask you to get the certificates and certificate 
management de-conflicted.

Nor to get TLSv1.3 working, because auditing is asking for that in the 
near future and that's not something you need to deal with to get the 
dozen apps stacked and "working" together.

Go ahead.  App-stack that.   Make my day.   Automatically, of course, 
because we're not hand-managing these bespoke boxes and these 
deployments if we can avoid it.

Yeah, with a managed switch, it'd be possible to remap parts of the 
network side of this app-stacking nightmare, but the OpenVMS apps 
themselves aren't always fond of allowing ports to be changed short of 
patching code, and OpenVMS has no generic mechanisms for establishing 
profiles for apps for these sorts of tasks, and multiple web servers 
really don't play well on the same ports short of some reverse proxy... 
fun.

Most of the OpenVMS boxes I'm dealing with are now running one related 
set of apps per box, too.  That's both because there aren't all that 
many OpenVMS apps and installations around in most organizations, and — 
when there are multiple unrelated apps in use within an organization — 
it's easier to not cross the streams when there are.   The folks with 
those more complex configurations do routinely ask for x86-64 guest 
support, too; they want more guests and fewer boxes, and they want more 
consistency among their servers which means fewer not-x86-64 boxes 
around.

We are NOT operating with the same sorts of apps we had in the last 
millennium.   Arbitrary apps just don't stack all that well, not within 
the existing by-convention, un-enforced, laissez-faire, "coordination" 
schemes used by and among the apps written classic OpenVMS app 
developers.

BTW: has VSI acquired and re-opened the product prefix registry from 
the folks at HPE?  That registry contains (contained?) the facility 
prefixes for DEC/Compaq/HP/HPE and third-party products that are 
intended to be used across organizations.   (For those with source 
listings access, that was part of what was included in the $FACDEF 
module, but not everything made it into $FACDEF.)   And those 
cross-organization apps are the same sorts of apps that we're hoping to 
be stacking, eh?


-- 
Pure Personal Opinion | HoffmanLabs LLC