[Info-vax] VMware

[Dave Froble]

On 12/10/2019 9:15 PM, Kerry Main wrote:
>> -----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.

You bet, a rather good thing.

> 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.

I may have mentioned before that I'm hoping VSI gets their revenue from 
support, not licenses.  Needing to purchase a license most likely will 
have a negative effect on "spinning up" more VMS instances.  I'm 
guessing the current VM users are already to cough up support fees. 
Let's not confuse them.  Keep it simple, and what they are used to.

> 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?"

Because you're doing more ???

> 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.

Works for me.

> 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.

Good software architects will design apps to avoid the pitfalls.

> 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.

That's for damn sure.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486