[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Craig
> A. Berry via Info-vax
> Sent: February 24, 2018 4:33 PM
> To: info-vax at rbnsn.com
> Cc: Craig A. Berry <craigberry at nospam.mac.com>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph,
Automation
> 
> On 2/24/18 2:52 PM, Kerry Main wrote:
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Craig
> >> A. Berry via Info-vax
> >> Sent: February 24, 2018 2:17 PM
> >> To: info-vax at rbnsn.com
> >> Cc: Craig A. Berry <craigberry at nospam.mac.com>
> >> Subject: Re: [Info-vax] Distributed Applications, Hashgraph,
> > Automation
> >>
> >> On 2/24/18 12:33 PM, Kerry Main wrote:
> >>
> >>> In OpenVMS, you could also build master LD containers to image
> >> backup to
> >>> new OS, customize and reboot. Maybe 15-30 minutes start to finish?
> 
> When you're paying for every minute the instance exists, that's a long
> time fussing around before you're ready to do any computing.
> 
> >> Then another month of tinkering to figure out how to change the
> node
> >> name without breaking anything.
> >>
> >
> > Never been much of an issue if its just the OS (modparams) and TCPIP
> > (tcpip$config).
> 
> There is quite a bit more to it than that:
> 
> <http://h41379.www4.hpe.com/faq/vmsfaq_007.html#mgmt9>
> 

There are best practices when building a homogeneous environment.

Node names - Assume no DECnet and start-up files which use logicals and
lexical functions to determine node names. 

Also, Unless required, assume node names not used in things like disk
logicals and batch names. Not the best strategy when one wants a
homogeneous environment anyway.

Same thing for rights identifiers based on node name - not the best
strategy in a homogeneous environment.

Licenses - not sure if this will be an issue with the new subscription
model.

Yes, one does need to ensure script files and dcl files are not node
name unique, but OpenVMS cluster Customers are familiar with this
anyway.

> > If Apps involved, then it does get a bit more tricky, but that is
the
> > same on *NIX and Windows as well.
> >
> > Its certainly not a show stopper.
> 
> Of course it can be done with enough time and expertise. There was a
> partial solution for certain HP blades, but it was never made into a
> general and generally-available solution. There's a long ways to go
> before VMS could be ready to spin up an instance in a few seconds,
work
> on some compute problem for a few seconds or minutes, and then go
> away.
> As is quite commonly done on other platforms.

I still see this as marketing hype for the majority of real world
production IT environments. 

Spinning up VM's - what about the data partitioning model and/or perhaps
even replication (assuming data is important) associated with these
VM's?

What about AV on these VM's - should they do data processing with zero
fear of being compromised?

What about firewalls and the detailed rules between App-DB and web VM
layers?

Imho, for most large environments, I would rather see a galaxy like
private cloud environment at some point in the future (yes, there are
challenges in bringing this functionality forward), where larger servers
have numerous spare core's in a "pool" or even spare vm's that can be
brought in as required dynamically based on capacity based rules. 

Build out with lots of little VM's is the most common compute model
today, but in the future, I would rather see a model that says build up
first (higher cores, larger memory), then build out as required.

It will be interesting to see how the new virtualization functionality
in OpenVMS V9+ will evolve.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com