[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of IanD
> via Info-vax
> Sent: February 20, 2018 2:56 PM
> To: info-vax at rbnsn.com
> Cc: IanD <iloveopenvms at gmail.com>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph,
Automation
> 
> On Saturday, February 17, 2018 at 1:30:10 PM UTC+11, Kerry Main wrote:
> 
> <snip>
> 
> >
> > Last 10 years was all about reducing HW costs.
> >
> > Next 10 years will be all about reducing SW costs.
> >
> 
> ...and the removal of any specific hardware awareness from the
> application so that you interface with virtual layers only. Virtual
IP's,
> Virtual devices, virtual everything
> 

This has been a best programming practice for a long time i.e. using
logicals, fqdns (not IP's), alias's

Concept is often called "service transparency".

> No hardware dependencies at the application level is wanted.

This has been around for a long time.

> Automated deployments, DevOPS, firewalls / networks all managed
> from generic interfaces with the hard work done by software
> underneath so humans don't need to learn the complexities of what is
> underneath (except when it all blows up of course!).
> 

Support of virtual worlds like software defined DC's is also risky
because it is so easy. Any FW's are now virtual, so FW person
inadvertently clicking on a wrong rule can expose all sorts of data very
easily.

> Hardware lock-in begone, software lock-in begone, humans to tend
> things, begone
> 
> Business want the ability to deploy over both private, public cloud or
> physical servers and mix n match components at will without the need
> for tear down and/or to specifically reconfigure
> 

Be careful here - a lot of this is cool-aid provided by media, cloud
(aka outsourcing) vendors and consulting org's.

Yes, there are pro's and con's with public and private clouds. One needs
to carefully understand these before drinking the cool-aid.

> VMS clusters have got a long way to go before they can adhere to this
> dynamic  model
> 

I would argue that OpenVMS clusters have supported "location independent
services" for a long time. Multi-site cluster logicals, alias's, HBVS,
and shared disk active-active strategy where one does not need to know
what server or what site you are on to have a program run on or submit a
job to batch on any server and have it run with no node specific logic
embedded.

Is there room for improvement? 

Sure, but the same can be stated for Windows, Linux where the concept of
multi-site data is usually based on replication technologies and data
partitioning (read lots of complexity at App/data level).

> > Oracle, SAP and similar App / DB players with ridiculous pricing are
in for
> some very tough years ahead.
> >
> 
> They are being exited out the door as simply too expensive, especially
> when they push their own barrow. They no longer hold the exclusive
> ability to unite the disparate parts of the business together
> 
> > History - Windows/Linux X86-64 servers were never really considered
> technically "better" than Solaris/SPARC, OpenVMS/Tru64 Alpha etc in
> their prime.
> >
> > However, Customers viewed Windows/Linux X86-64 as "good
> enough".
> >
> > Same thing is coming for the big SW companies.
> >
> 
> This is the same argument I've said about VMS Clusters
> 
> Linux clusters, no matter how crippled or fickle compared to VMS
> clusters, are considered 'good enough', because other layers have
> stepped in, be it application of some other like Hadoop etc

See earlier discussions regarding pro's and con's of shared disk vs.
shared nothing clusters.

Linux/GFS is shared disk like OpenVMS (locking via DLM, no data
partitioning required, but can be optimized by doing this). Regular
Linux is shared nothing (locking handled at App / DB layer with data
partitioning required).

OpenVMS can be deployed in either model.

Bottom line - there is no guarantee any one technology will be
successful in the future. Its wide open.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com