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

Kerry Main kemain.nospam at gmail.com
Sat Jan 6 10:29:36 EST 2018


> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: January 1, 2018 12:21 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 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.
> 

Have no idea of what point you ae trying to make here.

> >  - 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.
> 

Kerry's standard post to Hoff's std post about how the sky is falling with OpenVMS - 

Yes, the basic OpenVMS install and mgmt. tools need improvement. No one says otherwise.

However, regardless of the platform, (Windows, Linux, OpenVMS, Solaris etc), in large environments today, IT shops deploy "gold" images to new server deployments. These are pre-configured system images which contain latest patches, custom agents, server hardening, and custom support utilities. No one reloads the new OS by starting with the vendor provided brand new OS install disk.

With OpenVMS, these could be LD images, infoserver or even as simple as backup restore and then do a few server specific customized tweaks.  Check this out:
<http://h41379.www4.hpe.com/openvms/journal/v15/blade_servers_ovms.pdf> 

In the future, I expect large companies will also likely take advantage of provisioning HW provided by vendors like the following:
< https://www.youtube.com/watch?v=q08A1dZ4l94> 

> >  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.
> 

That’s not the point. How many OpenVMS Customers do you see deploying a multiple new servers (V/P) every time someone says we have something we need to run and I need it to have its own dedicated servers? The OpenVMS typical response is "why not run it on server X as we have lots of capacity?"

In the commodity OS world, this would be deemed crazy talk.

> 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.
> 

Market share is a different conversation. 

How many competing products are there in Microsoft for Windows or in Red Hat for Linux?

Everyone here knows that OpenVMS was just one of thousands (literally) of product lines (many competing for same market e.g. Non-Stop, HP-UX etc) in HP/Compaq/DEC, so you don't turn around 20+ years of neglect overnight. Yes, there are many other past issues as well.

> > 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 Customers have been doing this for decades. Windows and Linux Customers have their own configuration and mgmt. challenges as well. No platform is perfect.

Question - If you were responsible for security, would you rather manage one cluster environment under 1 security umbrella or 50 different Windows (Linux) environments that because they belong to different groups, may all be running different OS versions, different patch levels, have different backup products and mgmt. tools etc.?

> 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.

I never stated that OpenVMS Customers are not interested in hosted solutions. 

To the contrary, you cut out those references I made to hosted remote solutions that OpenVMS Customers can take advantage of today.

For some environments, hosted outsourcing solutions (whether you call it public cloud or selective outsourcing is the same) could be a good option for them.

Indeed, the new virtualization capabilities coming with OpenVMS X86-64 will be great for OpenVMS development environments as well.

However, when going external, they need to make these decisions with a full understanding of what they are getting into. All to many execs these days are falling into the trap of industry cloud washing hype (remember SOA washing?)

Forbes - 2016:
< https://www.forbes.com/sites/forbestechcouncil/2017/07/25/the-cloud-vs-in-house-infrastructure-deciding-which-is-best-for-your-organization/#34e1f5e320f6>

"However, the cloud is not always superior to building in-house IT infrastructure. Cloud providers’ slick marketing materials gloss over the technology’s numerous drawbacks, such as skyrocketing fees, poor performance and cybersecurity issues. The decision between using a public cloud and building your own IT infrastructure is not so different than deciding between renting a workspace for your business or buying your own building; both decisions boil down to having total control (and responsibility) over your own environment versus depending on a landlord to provide an adequate workspace and fix problems quickly and adequately."


Regards,

Kerry Main
Kerry dot main at starkgaming dot com







More information about the Info-vax mailing list