[Info-vax] VMware

[Kerry Main]

> -----Original Message-----
> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: December 10, 2019 8:10 PM
> To: info-vax at rbnsn.com
> Cc: Arne Vajhøj <arne at vajhoej.dk>
> Subject: Re: [Info-vax] VMware
> 
> On 12/10/2019 2:45 AM, IanD wrote:
> > Docker, another technology is making gains on VMware using a container
> > technology but this is a topic for another day, I think OpenVMS may
> > have to embrace contains at some point in time
> Yep.
> 
> Container technology are reducing the use of VM's.
> 
> Kubernetes is probably the greatest threat to VMWare's business (even
> though VMware of course try to get into that market as well).
> 
> Containers in VMS would be cool. But I also think it would require a lot
of
> work - a lot more work than what it takes to make VMS run in VM's.
> 
> Even though VMS actually have some building blocks that could be used to
> support containers.
> 
> Arne
> 

Most of what was stated in this thread is true i.e. virtualization has many
benefits over most physical server hardware - especially in a Dev/Test world
where spinning up the same baseline of an instance is important. 

Keep in mind that Microsoft and Red Hat love this model because they get
paid monthly support and OS licenses (MS) on a per instance basis. They
could not care less if the OS instance was P or V. 

The same will be true for OpenVMS. 

If a company is running OpenVMS in a VM instance on VMware/KVM/Xen/???, and
they decide to quickly spin up several OpenVMS Dev instances, then VSI will
require support and maybe license costs (depending on V9+ support model) on
a per instance basis. That is great for VSI as well.

Having stated this, there is a lot of practical reality though that unless
you are in a larger shop, most people may not realize are real challenges.

Yes, you can put a large number of VM's on a single server, but you also
need humungous amounts of physical memory on that server which adds huge
costs to each physical server. I have seen quotes for enterprise ProLiant's
with 1-2 TB's of memory in the $250,000 range - per server! And then the
VMware and any COTS application licenses costs are in addition to this.

Also, keep in mind that if using COTS products that are licensed per core,
then you definitely want to keep that COTS product on its own small VMware
cluster - just ask those who deploy Oracle on VMware.

Yes, VMware (and its equivalent competition) solved the issue of the wild
west of the 80's and 90's where every dept had their own local servers i.e.
server sprawl. 

Now, however, large companies have the problem of VM sprawl. Where they
might have managed 40-80 physical servers before, they now manage hundreds
of separate VM's. A common question from IT C levels is "how come our IT
costs keep going up even though we consolidated all the physical servers we
had before?"

In addition, being able to spin up VM's quickly is great if the application
is architected such that the workload can be spread across many servers.
While this may be true for new Apps written in the last 10-15 years, the
reality is that the vast majority of legacy and COTS apps in enterprise DC's
are not architected in such a way.

The other issue with VM sprawl is that of license costs for such things as
licensing backup agents, AV agents (do you really want to ignore AV
issues?), log file monitoring (for those who care about per instance
security monitoring), scheduler agents, service desk integration (smart
ticketing) and other host based management and monitoring (M&M) agents.

Sure, if the company wants its senior developers to spend a great deal of
their time developing freeware solutions to the M&M challenges above, then
these per instance M&M costs can be mitigated somewhat.

If the company would prefer to have its senior developers adding
functionality which adds value to its core applications, then that company
is more likely to be of the frame of mind to simply use commercial agents
(they still require integration, but typically less so than freeware
options) where they have a single throat to choke.

In terms of building new Apps which are heavily distributed to take
advantage of many, many VM's, these are not without its challenges as well
in terms of data caching, consistency, coherency, complexity etc. 

Certainly there are some ways to address these challenges (just ask google
and FB), but as others have stated here - it is not a slam dunk as to what
model is best suited to address any given set of requirements. 

A summary of building highly distributed app challenges can be seen in this
article from 2015:
"Making the Case for Building Scalable Stateful Services in the Modern Era"
<http://highscalability.com/blog/2015/10/12/making-the-case-for-building-sca
lable-stateful-services-in-t.html>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com