response 4 of 56:

Dec 2 20:59 UTC 2008

Actually, I think the "high end" package is slightly *more* than
what we currently pay at Provide.net (we pay $100/mo for colo).

Going virtual would mean porting the OpenBSD specific parts of
Grex's software investment to FreeBSD.  I'm fine with that (I think
we should have gone with FreeBSD instead of OpenBSD to begin with,
but lost that battle), but some other folks might not be.  Steve,
for instance, is a really big fan of OpenBSD and might not want to
switch.  It would not be *nearly* as big a deal as the move from
SunOS to OpenBSD was, but it is something to bear in mind.  It also
likely means giving up our dialin lines.  Again, I'm fine with that,
but I think it's likely going to meet stiff opposition from a few
diehard users of that service.

On the other hand, these things aren't insurmountable; after all,
most of the software we use is open source, meaning we can move it
around very easily (the only exception is Picospan, which we're
going to have to bite the bullet and say goodbye to sometime over
the next year anyway).  And it may be possible to rig up something
for a dialin solution (maybe a terminal server in somebody's house
configured to host modems and automagically SSH into Grex or
something.  Then you have to factor in the risk that this hosting
company might go out of business or change its pricing structure
or something of the like.  In these economic times, that's a
non-trivial amount of risk to assume.  Not a show-stopper, but
again, something to think about.  Finally, is what Grex does, with
providing access to a lot of services to nearly complete strangers,
really something that is going to be inline with this hosting
company's AUP?  That needs to be researched and settled; we've had
some problems with unruly Grex users causing problems for Provide,
and I can imagine that the problem would be worse in a virtual
context where our workload is competing for resources with those
of other paying customers.

The reason I'm guessing that Remmers believes this would be cheaper
is because, as I understand it, our *total* outlay per month is
about $150.  That includes $100 for colocation and another $50 or
so for the two phone lines.  If we went with this hosted solution,
and kept dialin access, costs would increase to around $170.00 plus
electricity and hosting for the modems and a terminal server.  I'm
guessing we'd end up spending around $200/mo, when you factor in
the cost of getting and maintaining a terminal server locally.

There are certain advantages with going with a virtualized solution,
but I'm not sure the problems we've had with Grex in the past are
among them.  The hardware problems we've had have largely worked
themselves out, and now that we've figured out the dance with calling
provide and getting them to reboot the machine if it crashes,
physical access is much less of a problem.  Before, we were much
more hesitant to do that since we thought we might be able to get
good information from the console about *why* Grex was down.  Almost
universally, we didn't do that, or what information we *did* get
was just the soft of thing that enabled us to say, "yup, there's a
bug in OpenBSD.  It's known and they're working on it."  It wasn't
very *useful* information, so now we've more or less given up on
that and just say, "screw it; reboot it and if there's anything
useful it'll be in the logs or the crash dump anyway."  Further,
recent security problems with virtualization servers make me wary
of wanting to host a service like Grex somewhere where other
organizations can have root on the same *physical* hardware.

On the other hand, it's getting about time that we got a new machine.
That's going to cost about $2500 or so.  That's equivalent to the
extra money we'd spend over a little over four years of virtual
hosting, and that's about how long we could expect to have that
machine before it was time to upgrade again.  So I'd guess that
financially, we'd about break even.

I do think there's a place for virtualization on Grex, but it has
a lot more to do with partitioning services and seemless upgrades
than cutting cost or boosting reliability.  For instance, we may
want to push email *processing* to a different "host", and it would
make upgrades really, really nice if we could "clone" Grex, upgrade
the clone, *test it*, and then "shift" the references to user data
directories in a virtual machine and bring up a new, fully tested,
upgraded Grex with a single reboot.  But that is *not* what I gather
this service is offering.