[Info-vax] OpenVMS servers and clusters as a cloud service

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: December 31, 2017 2:47 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] OpenVMS servers and clusters as a cloud service
> 
> On 2017-12-31 15:44:26 +0000, Kerry Main said:
> 
> > My point is that I know Amazon and Google etc.
> 
> Neither of which is relevant to getting OpenVMS into a hosted
> configuration, as neither of those providers are likely to adopt and
> use OpenVMS any time soon.
> 

I never stated OpenVMS was something I thought should be hosted by Amazon or Google (at least not in the transition years of 2017-2020). Not sure where you got that idea from.

> OpenVMS is not now at Amazon scale, nor Google / GCE scale, nor
> Microsoft Azure or any of the other providers, nor is it feasible to
> operate OpenVMS at the same scale at comparable costs.
> 

Never said it was.

> This thread also started with just getting OpenVMS going, in a hosted
> configuration.  

Lots of different views on what is a "hosted" environment.

Customers can get out of the DC facilities business and have their exiting and/or new OpenVMS environments hosted elsewhere TODAY and have been able to do so for decades. Every DC collocation provider rents typically by rack space/power, so could not care less what you put in those racks since it is the Customer (or their designated server mgmt. partner) who will be maintaining what's in the racks remotely. The collocation provider provides AC/pwr, physical security, underlying network (optional) etc. That collocation provider also will provide (for a fee) "smart hands" to do any physical activities required.

There are companies like Software Concepts International  that will provide hosting services today as well.  See earlier response I posted for other providers.
< http://www.sciinc.com/>

Now, having stated this, I think there is a whole new level of capability coming with the new virtualization (KVM based as I recall Clair stating) features in the roadmap. This will allow Customers to spin up new "gold images" (preconfigured images or LD images) much quicker than today.

> Not with competing in server counts and scale with
> Amazon or Google / GCE or Azure or elsewhere, but.... just...
> getting... OpenVMS... hosted.
> 

Never said it was.

> Also of using some of the capabilities that those and other providers
> already offer their customers, certainly.  Bigger providers can
> inherently provide DNS, better spam filtering and other nice-to-have
> capabilities, too.
> 

Most collocation providers typically have agreements with large DNS/DDOS service offerings.

> > have very high numbers of servers (phys or VM really does not really
> > matter from admin perspective), but their Sysadmin ratio is not 28,000
> > servers for a single admin. Hung services, hung/crashed servers, log
> > monitoring, backup failures, password mgmt., hardware failures,
> > firewall rules integration are all examples of Sysadmin activities
> > where tools and custom automation can certainly help.
> > Large companies like this have large Engineering and Operations teams
> > doing nothing but custom NOC / ECC monitoring, backup management,
> event
> > log and security management and workflow automation of the IT
> > infrastructure.
> > Do these teams count as part of their "server" SysAdmin ratio's?
> 
> OpenVMS deployments are comparatively difficult and manual efforts
> starting at deployments of one host and of one cluster, and it's
> exceptionally rare to encounter an organization that's using automated
> deployments of OpenVMS itself, nor organizations that are using
> deployment tools much past PCSI kits for layered products and local app
> deployments.   System management, app deployments and crash
> uploads,
> software updates, local and connection security, error monitoring,
> backup management, password management, are all add-on or bespoke
> code.
>  There are some third-party folks that have developed various of these
> tools, mostly for their own internal use and for serving their own
> customers; folks that have outsourced OpenVMS and/or that have
> outsourced some or all of their OpenVMS management.   Little of that
> has been open-sourced.   Little operations and open source exists for
> OpenVMS in this area, as well; tie-ins with K8s or otherwise.  Yes,
> there is some open source here, such as Jensen.  But then I'm also
> presently having a tussle with current versions of some very common
> open source tools on OpenVMS, too; it's just not building.
> 

The vendors that will support OpenVMS in a virtualized environment will develop the tools and /or adopt whatever technologies that make it easier for them to support that environment. The Customer will not care how their provider does it. 

One option for that OpenVMS provider might be to customize and/or integrate the new OpenVMS virtualization capabilities with emerging server technologies like what HPE has recently released with their Synergy Image Streamer features:
< https://www.youtube.com/watch?v=q08A1dZ4l94>

> > There are basic things which have to happen for every server instance
> > and yes, smart tools and custom automation absolutely do help, but
> > there is a limit on what tools can do without some level of experience
> > at the controls.  That is why large companies like Google have L1, L2
> > and L3 escalation support models for each level of their IT dept.
> >
> > Do these escalation teams count as part of their "server" SysAdmin
> ratio's?
> >
> > Make no mistake - there is lots to learn about scalability from the
> > Googles and Amazons of the world, but we also need to keep open
> minds
> > and not blindly accept whatever their marketing depts. pump out
> about
> > how good they are.
> 
> OpenVMS has installation, deployment, patch management, remote
> management, app deployments, recovery and system re-installation,
> and
> troubleshooting and related comparative-competitive difficulties at
> deployments of scale one.
> 
> As for the scale of deployments, what passes for a very large OpenVMS
> installation is smaller than what many of us have seen of Microsoft
> Windows clients in use on one floor of one building in one office park,
> too.
> 

Different culture as well - lets not forget that Windows and Linux typically deploy one bus app or one App service per OS instance. That drives much higher server numbers, but usually at the pain of VM servers that run at 10-15% busy most of the day.

With OpenVMS, it is very common to run many Apps on one OpenVMS instance.

> Many of us can benefit from hosting OpenVMS "elsewhere", whether
> for
> spinning up some servers to contend with transient spikes among those
> of us that have transient loads (such as Stark will likely have), the
> costs of a local data center or any data center at all, testing patches
> and testing app deployments, replication or redundancy, or otherwise;
> not having hardware around to deal with and to manage, and lowering
> fixed costs for that matter, has value.   Not everybody wants or needs
> or has the staff or the skills to run a data center, and — if OpenVMS
> is to provide solutions for these folks — it has to be better at being
> hosted.   VSI knows this, and is working toward the goal.   But it's
> several years before production OpenVMS on x86-64 and guest support
> and
> all that entails and requires, beyond the OpenVMS-traditional
> local-hardware hard-wired console or DRAC/iLO console environment.
> 
> So sure, point to Amazon or Google / GCE or Azure or otherwise.  Ponder
> what time and effort and tools and skills it takes to deploy and patch
> and maintain OpenVMS at scale one, scale ten, or scale one hundred,
> and
> compare that with what Amazon or Google / GCE or Azure are doing for
> themselves internally and are also selling to others.
> 
> Pointing to Google or Amazon is a whole lot like comparing CVE counts
> as a metric.  Seems reasonable, until the reader ponders what's being
> compared and whether the comparisons even make any sense.
> 

Never stated OpenVMS was going to compete with Google or Amazon.

> Hosting OpenVMS "in the cloud"?  That deployment approach does
> make
> sense for a number of folks.   But we're too early to start to learn
> about OpenVMS deployments with the x86-64 port, and all of us — VSI,
> ISVs, end-users — will be learning.
> 

See above - I expect new offerings from existing OpenVMS hosting providers as the new OpenVMS virtualization features are released.

> Most of the cloud vendors are offering a free shared instance;
> continuous access to a Microsoft Windows, Linux or BSD system.  Similar
> VSI and OpenVMS availability?  Not so much.   This is where many new
> apps and new deployments and new experiments with platforms and
> apps
> start, among those folks outside of the installed base.  Among those
> folks that aren't inclined to follow the traditional
> buy-and-license-and-install-and-manage the box approach, for whatever
> personal or business or accounting or tax or financial or other reasons
> that that choice might be made.
> 

In a subscription model, this becomes much easier to do.

> Some related reading:
> https://cloud.google.com/products/
> https://cloud.google.com/security/security-design/
> https://azure.microsoft.com/en-us/
> Etc.
> 
> ps: Assuming VSI and OpenVMS are still being actively developed and
> assuming that VSI doesn't seek to prevent this with their licensing
> prices and practices, I'd expect that at least a third of the
> then-active VSI OpenVMS customer base will be running at least some
> hosted OpenVMS systems within five years of the availability of the
> production version of the x86-64 port, and a sizable chunk of those
> folks will be running all of their OpenVMS servers hosted.   These
> systems for occasional or ongoing testing or development purposes or
> disaster tolerance or backups, or whatever.   Many of the existing VSI
> OpenVMS customers will certainly keep their core OpenVMS processing
> internal for any of various reasons.  Newer OpenVMS customers will be a
> mix.
> 

Define the term "hosted".  There are likely as many versions of the definition of the term hosted as there are for what does the term cloud mean.

A private cloud is where an internal BU provides IaaS, PaaS and SaaS services for the companies internal IT workloads. This may be done using a DC collocation provider so the company no longer needs to be in the DC facilities business, but still maintains control of their IT Infrastructure and Apps. Today, that is typically done with VMware, Hyper-V and KVM hypervisors, but private cloud SLAs will also support non-Windows/Linux environments as well. 

Public Cloud is simply outsourcing all or parts of your Windows/Linux (ONLY) IT to large vendors like Amazon, Google or on a smaller scale, Systems Concepts and other providers of remote OpenVMS hosting. See link above.

Fwiw, I expect most future company IT environments to be maintained in hybrid (mix of public/private) clouds while many will simply stay as they are today with dedicated support staff and local IT equipment. 

Some of the new, non-critical workloads will slowly move to external Public Clouds so companies can get a feel for what the issues and benefits are. The more critical services will stay internal (private or dedicated resources).

A good example of a major company moving back to providing internal IT services with internal staff is General Motors (GM)
<http://www.autonews.com/article/20171002/OEM06/171009988/randy-mott-gm-it-architect> 
<http://www.autonews.com/article/20170918/OEM06/170919754/gm-it-randy-mott> 
- Sept 18, 2017
"Ten times more productivity. One thousand percent more data. Nearly 10,000 more employees.

That's the result — so far — of an information technology transformation that General Motors began in 2012, a massive effort to undo years of outsourcing those increasingly critical functions and rebuild them in-house from virtually nothing."

Regards,

Kerry Main
Kerry dot main at starkgaming dot com