[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: February 22, 2018 11:23 AM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
> 
> On 2018-02-22 03:14:26 +0000, Kerry Main said:
> 
> >
> > Perhaps I am a dinosaur, but in the good ole days this was called
> > capacity planning combined with CoD.
> 
> Adding whole systems is a little different than licensing and
> unlicensing some cores.  iCAP / CoD was a way to transiently license
> and incrementally add cores into an SMP instance.  It probably would
> have been preferably for DEC and Compaq to have been able to use iCAP
> /
> CoD as a way to ship out fewer permutations of server systems and
> preferably with most or all of the server boxes shipped out configured
> fully populated with cores.  But that clearly didn't happen,
> particularly given the economics of adding cores back in that era was a
> whole lot different than multi-cores are today.
> 
> Wouldn't surprise me to see iCAP / CoD return for a few folks using
> OpenVMS, but it's still not particularly close to temporarily spinning
> up multiple guests and clustering them, as an example.   iCAP / CoD
> also doesn't help with apps that have conflicting system resource
> requirements (network ports, for instance), or that have conflicting
> system parameter requirements or conflicting username or software
> version requirements, etc.
> 

Somewhat agree, but VM sprawl is one of the biggest challenges facing many large companies today.  In a one bus app per OS instance culture, its also extremely tough to address.

Without proper governance, VM's propagate like rabbits - with all of the associated management and licensing costs. It’s the companies who allow internal resources to spin up new VM's in "minutes" (as stated here a few times), who are having the biggest challenges with VM sprawl.

Companies like Microsoft and Red Hat love VM sprawl because they still get their licensing and/or monthly support subscription $'s. They do not care if the OS is P or V.

On the positive side - VM sprawl is also going to be good for VSI once the virtualization and emulator capabilities kick in. 

> > Having stated this, I would far prefer VSI focus on solving issues for
> > traditional enterprise Customers and not that razor thin upper
> > stratosphere layer of Customers that need 1,000 servers for only an
> > hour.
> 
> Outside of the installed base, traditional enterprise customers aren't
> all that interested in OpenVMS.   Most server customers aren't
> interested, for that matter.  That's something VSI will be working on.
> 
> Making it (much) easier for new folks to spin up some new servers for
> prototypes or some testing servers for developers might get some new
> deployments, too.   Even from existing sites.
> 

That exists today with HP-UX Integrity VM's.
<http://h41379.www4.hpe.com/openvmsft/hpvm/integrityvm_cookbook.pdf>

> Thirty years ago, it would have been really handy to spin up a few
> MicroVAX systems as transient front ends or transient statistical
> quality control servers for testing parts of the factory network or to
> deal with transient loads, but that sort of ease and speed and
> flexibility just didn't exist back then.   And no, iCAP / CoD isn't a
> help here, because app-stacking different apps or multiple copies of
> the same apps onto the same boxes tends to disrupt things.
> 

Only if not well planned. The argument for "one bus app per OS instance" is common in the commodity OS world because of not only technical challenges, but also culture i.e. "no way I am running my bus App on the same OS as another Bus App".

See above regarding VM sprawl.

OpenVMS customers have been running the App stack model with OpenVMS standalone and cluster environments for decades.

Mission critical factory environments using OpenVMS do planning exceptionally well and often run multiple factory apps on the same OpenVMS OS.

Can there be improvements to the OpenVMS App stacking model (e.g. enhancements to the native class scheduler)?

Absolutely. 

Having stated this, imho, App stacking will be one of the future differentiators for OpenVMS.

What's old is new again.

😊


Regards,
 
Kerry Main
Chief Information Officer (CIO)
Stark Gaming Inc.
613-797-4937 (cell)
613-599-6261 (fax)
Kerry.Main at starkgaming.com
http://www.starkgaming.com