[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 19-Jun-16 12:42 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Re; Spiralog, RMS Journaling (was Re:
> FREESPADRIFT)
> 
> On 2016-06-19 15:32:54 +0000, Kerry Main said:
> 
> > You keep trying to bring this back to what OpenVMS has or has not.
> 
> No, I keep bringing this back to dragging OpenVMS forward, and toward
> supporting competitive features.
> 

I was talking about generic asyn/replication/write back concepts that are 
platform agnostic.

> Because — with the much-vaunted features and benefits you keep
> pointing
> to, and various of which I quite agree with  — OpenVMS has ended up
> where it is now.
> 

Let's not forget that the primary reason why OpenVMS is not as advanced
In some areas (while leading in others), is not the lack of tech Engineering 
or strategies.

It is because OpenVMS funding has been slashed and cut back starting
with DEC, then Compaq and then HP.  With each acquisition, OpenVMS
became an even smaller fish in a rapidly growing ocean of products.
When I left in 2012, the number of companies that HP acquired since 
Compaq was something like 43.

Now, moving to the future, one can continue to look through the rear 
view mirror, or alternatively, keep looking through the front window.

OpenVMS now has a new owner 100% focused on OpenVMS. That’s
the good news. From a business perspective, you have to admit when
new owners take over an existing company, they would be crazy to
ignore the current installed base.

X86-64 with binary Alpha/IA64 translators, new file system, new 
TCPIP stack, Java8 w new compiler enhancements are all examples of 
things that will keep (delight) the installed base.

When the previous things are added to areas like galaxy, increased 
scalable clusters using RoCEv2 for low latency DLM, enhanced VM,
Enterprise Directory integration (LDAP, resource mgmt./control) 
capabilities are all examples which could (imho) start getting the 
attention of new Customers. 

Of course, marketing and pricing strategies are key to this as well.

System management features are also needed (e.g. SNMP V3), but
new customers do not buy an OS for how cool the mgmt. tools are.

With all of the above, one needs to remember that VSI does not need
to do everything themselves. As an example, Microsoft has a backup 
utility that few med-large shop use. These customers use alternative
commercial offerings from third parties. 

I expect there will be third parties that will jump on the OpenVMS 
wagon with their offerings as well once things start to get rolling again.

> Because OpenVMS is comparatively hard to use, hard to develop for,
> hard
> to configure, hard to install, and such.   In five years, tools on
> other platforms are only going to be better.   

Of course - just as I expect OpenVMS mgmt. tools (VSI, 3rd party) to 
Advance as well.

> Some of those vaunted
> features — that wonderfully cautious I/O and the record-oriented design
> for file access — makes applications slow.   That'll take some thought,
> quite possibly involving replicated servers and other
> wholly-new-to-OpenVMS approaches.  Some of those vaunted and
> valuable
> features — clustering, HBVS — need a configuration and management
> overhaul and a re-think — e.g. integrated distributed authentication
> client and server, a logical volume manager, vastly easier
> configurations, etc.   Some features — like the current PKE security
> "design" — should be copied wholesale into NLA0: and reimplemented
> and
> integrated into OpenVMS, rather than being ad-hoc and grafted on.  This
> also includes better tools for your app-stacking and for app isolation
> — sandboxes/jails — and better tools for local and hosted deployments
> —
> provisioning, etc. — and a whole host of other areas that are expected
> or will be expected over the next five or ten years.  Better patch
> support, DVCS support, integrated relational database support, etc.
> 
> You keep telling me OpenVMS is great.  For a number of apps, it is.
> But there is very little here that's presently going to gain the
> attention of new sites and wholly new applications, and the x86-64 port
> is just a down payment on the effort ahead of VSI here.   There's a
> tremendous amount of work involved here for VSI and also for end-
> users
> to start adopting current and new OpenVMS features, and the
> competitive
> and the comparative operating system platforms and tools are
> themselves
> always being updated.  Often substantially.
> 
> You keep telling everybody about "blue oceans".   Maybe VSI heads that
> way.   But that blue ocean will inherently have to be far different and
> far more advanced than what OpenVMS offers today.  Hopefully much
> simpler, faster, cheaper, too.
> 

As just one example - 
Server to Server network latencies (App-DB server, App-App, Server-
Server replication) are by far the biggest source of latency in most 
solutions today. While CPU, Memory, and cache technologies have all 
increased exponentially, the latency (not speed) associated with all of 
this inter node network activity has not.

Reference:
http://www.research.ed.ac.uk/portal/files/14176012/Novakovic_Daglis_et_al_2014_Scale_Out_NUMA.pdf 

Red ocean approach to problem - 
How can we reduce the latency with all this server App-App-DB 
network activity?

Blue ocean approach to problem -
How can we ELIMINATE the latency with all this server App-App-DB 
network activity?

Regards,

Kerry Main
Kerry dot main at starkgaming dot com