[Info-vax] Where to locate software

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 10-Jun-16 3:50 PM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Where to locate software
> 
> On 2016-06-10 16:13:32 +0000, Kerry Main said:
> 
> > No. App stacking is not only possible, but it is has been part of the
> > culture of OpenVMS Customer environments for decades.
> 
> Sure.   If by "app stacking" you mean the 1970s through the 2000s, at
> least in terms of features, capabilities, isolation and ease of
> automation.
> 
> What you keep pointing to as "app stacking" is increasingly
> problematic, at best.
> 

On the contrary, I view App Stacking as the way of the future in order to 
address both VM sprawl and significantly reduce server-server latency.

Hint - do you think the latency associated App server to DB server network
communications (think those with persistence updates) would not be
exponentially smaller if the App Server(s) and the DB server were on the 
same OS instance sharing 32/64 cores and 768GB/1.5TB physical memory?

Hint - the distributed model of the 90's is functionally still ok, but the
deployment model is broke because the network inter-node latency has 
become one of the biggest inhibitors to scalability.

> If Stark gets traction and starts scaling and starts having to do
> faster deployments and redeployments and upgrades — certainly a good
> thing — then you're going to start encountering these limits in
> OpenVMS.
> 

Nope - even today a brand new blade server can be brought online using
custom gold images and common system disks in less than an hour. 

> Or you're going to end up rolling out piles of custom code, or porting
> existing devops and deployment tools.
> 
> For end-users, rolling out custom code and custom automation for
> devops
> is a cost, not a benefit.
> 

Devops is like cloud computing or SOA or so many other hype filled 
concepts today.  Still does not replace good old fashioned planning
between the OPS and Dev groups along with something else which is
not sexy, but still works - something called capacity planning.

> > The challenge with commodity OS's
> 
> I'm rather less interested in how things were and how things are now,
> as — from a software development perspective — that's history.
> 
> It's how things will be — not how they are or were — that matters to
> Stark and to other current and potential customers of OpenVMS, and to
> VSI.
> 
Knowing why commodity OS's became popular is critical to understanding 
why the shared nothing compute model they both share is heading for some 
big challenges in the future.

> If your experience is limited to HPE and Windows and OpenVMS, and I'd
> recommend spending some time further afield, too.
> 

Issue with Linux is that while they have some capabilities that OpenVMS 
does not yet have (and vice versa), many of the HA capabilities Linux are 
done at the App level. This means a distributed systems programmer needs 
to embed code in their application to take care of things if a server should 
fail, or how to take advantage of a new node added (or deleted), or how to 
address site issues e.g. dynamic config files, using replication to save data.

Perhaps I am crazy, but imho, that model is the one that is broken. An App
programmer should focus on optimizing and enhancing their code and not
have to worry about numbers of nodes or where the code runs. That is
the responsibility of the OS / infrastructure group.

This is the way (or should be)  a next gen model should be designed.

Rather than simply taking the view of "the grass is greener on the other
side", take a look at the following presentation for a real world look at
how the typical group handles failures in a Linux shared nothing world:

Posted Feb 27, 2016: Architecting Distributed Databases for Failure

https://www.infoq.com/presentations/data-integrity-distributed-systems?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=presentations_link&utm_content=link_text
(click on InfoQ video)

Think about replication (over the network), network queries (over the 
network), & how to ensure data is protected when DB is split across many
many nodes with each node having unique data i.e. how shared nothing
model works)

imho, the grass on the other side is not looking very good.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com