[Info-vax] IBM nearing deal to acquire Red Hat

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Stephen
> Hoffman via Info-vax
> Sent: April 29, 2019 12:53 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] IBM nearing deal to acquire Red Hat
> 
> On 2019-04-27 13:38:15 +0000, Kerry Main said:
> 
> > While the technology is improving, the concepts of what you are
> > talking about has not changed - its only the improved GUI's and level
> > of automation that has improved.
> > What you are talking about is capacity on demand (COD) i.e. pay as
> > required when additional resources are required.
> > Outsourcers, vendors and many platforms, including OpenVMS and
> > Alpha's, have had an early version of COD or iCOD (instant capacity on
> > demand) decades ago.
> 
> The capacity-on-demand scheme in OpenVMS (iCAP, etc) was as much about
> mitigating the software licensing costs than about adding hardware
capacity.
> 

Capacity on Demand was an industry wide scheme to address peak demands in
Customer workloads while not requiring Cust's to pay for resources in low
demand periods. Solaris, AIX, z/OS, HP-UX all had this capability. 

Reference:
<https://docs.oracle.com/cd/E21659_01/html/E21660/z40000071004137274.html>

But you knew this.

> iCAP throttled the existing and usually-over-provisioned hardware
capacity,
> allowing the customer to choose when to pay for that capacity and for how
> long.
> 
> The whole scheme exists solely because of OpenVMS licensing costs.
> 
> A modern form of filling the backplane with epoxy.
> 
> It's a form of arbitrage, built upon a pricing-related product
differentiation.
> 
> For iCAP to even work, the folks must have already installed hardware with
> the necessary capacity.
> 
> Hopefully with the necessary peak capacity.
> 
> Purchasing excess hardware capacity and never using it gets expensive,
too.
> 

You did not pay for resources not used.

> Pooling that excess hardware capacity across users and app environments is
> far more interesting, and OpenVMS itself has little (no) concept of what's
> involved with that.
> 

OpenVMS Galaxy (albeit some Alpha's only) certainly was a leader at the time
in load sharing across multiple OS's, sharing memory and dynamically moving
pooled CPU's across different systems based on business rules or manual
drag-n-drop.

But you know this.

> How to shed load too, for those cases when priority processing needs more
> capacity than is available in the pool.
> 
> And this capacity-acquisition and load-balancing and load-shedding is all
part
> of higher-end distributed process scheduling and as is being discussed
else-
> thread, too.
> 

See Galaxy note above.

While no longer supported on new HW, and currently not in the plans, it
certainly would be nice to see some future version of OpenVMS resurrect
these Galaxy features - perhaps using some of the new X86-64 built in
virtualization features. But, yes, its not on the radar right now.

> Profiles, a complete replacement for the installer, app bundles,
isolation,
> self-configuration, etc.
> 
> iCAP or otherwise don't even approach what's necessary to make this work
> well for an end-user.
> 
> iCAP is about as relevant as is LMF to what's involved with easily and
quickly
> booting as a guest in a private or in public shared data center.
> 
> This whole mess is right in the Stark Gaming wheelhouse and as I keep
> coming back to, too.
> 

Who said anything about COD in terms of todays capabilities? Again, albeit
historical in terms of todays capabilities, COD is an industry feature that
was never unique to OpenVMS.

The earlier note was a historical reference that showed the "cloud"
provisioning hype is nothing more than an evolution of what was in place 20
years ago. The traditional ITSM Service Catalogue is now replaced with a GUI
based user provisioning interface. 

Regards,

Kerry Main
Kerry dot main at starkgaming dot com