== Seriously using virtualization clashes with our funding model

In a comment on [[my entry on us needing to get experience with
Ubuntu 20.04 ../linux/Ubuntu2004GettingExperience]], Miksa pointed
out the advantages of investing heavily in virtualization. These
definitely exist, but among other practical issues, heavy investment
in virtualization clashes with our funding model, which you could
describe as 'erratic' or 'nonexistent'. Our equipment funding is
quite erratic and as a result [[we have to buy stuff mostly in
bursts ../tech/UniversitiesBuyWhenYouCan]].

A significant commitment to and investment in virtualization really
calls for big servers, ones that have a lot of memory and CPUs to
support a lot of virtual machines at once (and possibly a lot of
storage, or a very fast storage network). Big servers are expensive
and you have to spend that money all at once, both the initial
purchase and their replacement when they reach their (finite)
sensible operating lifetime. Periodic big investments on big VM
host servers may well cost less overall than a series of smaller
but more spread out investments on physical servers, but they require
you to have large sums of money available at predictable times.
Unfortunately, we don't.

(There's [[an alternate model of lots of smaller virtualization
hosts with fewer VMs on each host VirtualizationHostLargeVsSmall]],
but it's not what people talk about or recommend.)

This is the same effect I've seen before with network routers and
switches, where [[buying a highly capable but expensive router doesn't
make sense for us FundingAndHardwareSize]]. With routers and switches
we're better off with a bunch of smaller switches than trying to do
everything in a few big units, because we can buy and replace them
piece by piece. The same is true for us with virtualization servers, at
least in the conventional model of them. Our funding model is mostly
incompatible with periodic big purchases.

(We've been surprisingly good at turning over [[our fileserver
infrastructure ../linux/ZFSFileserverSetupIII]] more or less on
schedule, but that has traditionally had a natural forcing function
because hard drives wear out. Even then we pushed one fileserver
generation alarmingly far, to the point where [[we saw significant
drive failure rates ../tech/DisksWearOut]].)

PS: This funding issue isn't solved by using someone else's host
infrastructure so that we pay this as an ongoing smaller operating
cost instead of a periodic hardware purchase cost. [[We don't have
reliable money for cloud operating costs either, and that can be a
worse problem ../tech/CloudPaymentsProblem]].