[Info-vax] OpenVMS servers and clusters as a cloud service

[Stephen Hoffman]

On 2018-01-01 15:45:53 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
>> Stephen Hoffman via Info-vax
>> Sent: December 31, 2017 2:47 PM
>> To: info-vax at rbnsn.com
>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] OpenVMS servers and clusters as a cloud service
>> 
>> On 2017-12-31 15:44:26 +0000, Kerry Main said:
>> 
>>> My point is that I know Amazon and Google etc.
>> 
>> Neither of which is relevant to getting OpenVMS into a hosted 
>> configuration, as neither of those providers are likely to adopt and 
>> use OpenVMS any time soon.
> 
> I never stated OpenVMS was something I thought should be hosted by 
> Amazon or Google (at least not in the transition years of 2017-2020). 
> Not sure where you got that idea from.
> Never said it was.
> Lots of different views on what is a "hosted" environment.
> Never said it was.
> Never stated OpenVMS was going to compete with Google or Amazon.
> Define the term "hosted".

Please re-read the original posting here.   Of getting OpenVMS running 
hosted.  Of whether VSI is aware of that part of the market.  VSI is.  
And OpenVMS needs work for even small-scale deployments, which VSI will 
likely be working toward after the x86-64 port becomes available and 
stabilizes.

> Different culture as well

These are products and services that we acquire to solve specific 
problems, at levels of effort and investment and expenses that are 
deemed acceptable and feasible.

>  - lets not forget that Windows and Linux typically deploy one bus app 
> or one App service per OS instance.

Ah, Kerry standard post number 5.   Hoffman standard response to Kerry 
post number 5: Let us not forget that OpenVMS is awful at any sort of 
similar app deployments, redeployments, re-imaging or reloading, too.   
Worse than Windows and Linux, and harder to configure.  It's all 
manual, or it's bespoke tools, or it's (if you can find them) 
third-party tools to orchestrate your servers.  Most of us end up with 
our own deployment frameworks.  Reimplementing what is often widely 
available on other platforms.  Which means more expenses and more 
effort and usually for less results, on average.

>  That drives much higher server numbers, but usually at the pain of VM 
> servers that run at 10-15% busy most of the day.

I routinely see OpenVMS servers running at those load levels, too.    
The bottom-end Itanium systems are rather far from entry-level or 
bottom-end performance.

But then what's a large OpenVMS site?  A hundred servers?  A thousand 
servers?   Compared with many common Windows and Linux deployments in 
medium- and larger-organizations, those numbers are pretty small.

For more than a few medium- and large-sized businesses, the numbers of 
OpenVMS systems present can be counted on your fingers.

> With OpenVMS, it is very common to run many Apps on one OpenVMS instance.

Continuing Hoffman standard response to Kerry number 5: Common?  Sure.  
Classic, too.  But that's not necessarily a Good Thing.   Go and try to 
automate that configuration, and particularly go keep those apps from 
stomping on each other either accidentally or due to an exploit of a 
vulnerability, and automate keeping a herd of those apps and services 
current, and call me back.   Cooperation and cohabitation is entirely 
by ill-documented and unenforced convention, and by manual 
troubleshooting when some DECC$ or file lock or system parameter 
requirement or other setting "escapes captivity".   There's no 
enforcement of the conventions, no verification, no provisioning, no 
cryptographic checksums, no pledging, nothing.  If you control all apps 
and if there are no vulnerabilities and no malicious code on the server 
and on the internal network and no vulnerable frameworks or libraries 
or servers lurk within the configurations, hand-configuring and 
hand-tuning these configurations can work.  That's before getting to 
some spectacularly bad documentation in parts of the OpenVMS product 
set, too.  Having had several tussles with even the standard network 
server tools in recent weeks, I wish you well with all of this.

OpenVMS needs related app-stacking and hosting work as it is, even for 
small installations.   Which is most of the OpenVMS installs, BTW.   
Comparatively few systems.   It's also work that'll help traditional 
installs, hosted installs running on local hardware or on remote 
hardware, and that'll help maintain and secure the platform.

If hosted servers won't and don't work for Stark — something that I 
seriously doubt given your target market, BTW — then don't use them.   
Folks running their own data centers aren't fond of hand-rolling 
deployments and different servers, too.  But please don't assume that 
other folks using OpenVMS aren't interested in or can't benefit from 
using hosted services and far better isolation and better automation 
and the rest that support eventually entails; of any of the various 
whatever-as-a-service offerings also apply to the folks running their 
own shared internal shared hosting.





-- 
Pure Personal Opinion | HoffmanLabs LLC