2011-08-29
Devirtualization
Not quite a year ago, I wrote about our use of virtualization here in OurVirtualizationUse. That entry is now what we call 'inoperable', because we have just finished de-virtualizing; reverting back from virtual machines to running those machines directly on real hardware. We did this ultimately because we think that it's less of a hassle to run machines on real hardware than virtualized.
In retrospect, I think that part of the problem is that our virtual host machine was underconfigured in terms of RAM and disk space. It had what seemed like a decent amount of both, but virtual machines add up surprisingly fast (especially once you start worrying about backups of them and so on). And certainly it's a factor that we have plenty of spare hardware that's large enough to easily run stuff on, even a single Windows server.
But a significant issue was that managing the host environment was a hassle and managing the virtual machines on top of the host environment was another hassle. Because we only had one host machine, doing any significant maintenance on the host machine meant taking down all virtual machines and then starting them again. And while making the host machine an Ubuntu LTS server was useful because we already had a bunch of infrastructure for managing those, it meant that we did have to manage it and in particular we had to apply kernel updates. Every kernel update was a hassle, and it didn't help that we were using a third-party virtualization system that needed special magic hand-holding after a kernel update. Even beyond the host updates, managing the virtual machines always took remembering the special steps needed to do things get 'console' access to them and force power cycle them. The whole experience was just annoying.
In the end, the person who built the next generation of our Windows terminal server decided that he would rather build it on real hardware, partly because it would be less of a hassle and partly so that he could easily give it a lot of disk space and memory; that decommissioned two of our three virtual machines. Keeping a virtual host machine running just to host a single virtual machine that forwards some low-priority email seemed, well, kind of stupid.
(I'm thinking of this because today was the migration from the old virtualized Windows terminal servers to the new non-virtualized one. Normally we might keep the old virtualization server running in the corner just in case, but there's an overnight building wide power shutdown tonight so we powered it off along with everything else and we don't plan to turn it back on.)
I definitely don't think that this makes virtualization a bad idea in general. It didn't work out for us, but I think it would in a different sort of environment and certainly it works for other people. (I have some thoughts on what sort of environment it would probably work well in, but that's for another entry.)
Designing services for disengagement
A while back I wrote about how I had realized that a lot of my syndication feeds were only for casual reading and how I thus wanted to reduce their impact on my time. I suspect that I'm not alone in this pattern of having periods of initial enchantment with services and then winding up less interested in them, which leads me to a corollary for designers of services.
There are a lot of services where it's easy to move from just starting out to really immersing yourself in the service; sometimes this just happens, and sometimes this is deliberately designed into the service. However, some amount of your users (perhaps many of them) will wind up getting in too deep and want to scale back their involvement in your service.
If you want these people to stick around at all, what I think you need is something that automatically ramps down their involvement for them. When your system notices that someone's interacting with you less, you should intelligently trim down the number of things that they have to deal with. You don't want to leave this to the person to do for themselves by hand, because that takes work which means that the easiest thing for the person to do is to abandon your service entirely.
Or in short, you want to design for disengagement as well as engagement.
Note that this is not the same thing as designing for beginning users or casual users. Disengaging users will wind up as more and more casual users, but they get there by a different path. To try to summarize it, casual users have simply stopped moving forward; disengaging users need to move backwards. Disengaging users may not even be able to use the same interface as casual users, because they're working in different environments.
(To give an actual example, consider syndication feed reading. A casual feed reader has probably never added very many feeds, and so has a low article volume. A disengaging user (such as me) has added a bunch of feeds but can no longer keep up with the resulting high article volume. You can't reduce the disengaging user to a casual user except by removing most of their feeds, and that may not at all be what they want and what serves them. A similar thing holds on a social website like Facebook; a casual user generally has few 'friends', while a disengaging user has lots of 'friends' that they can no longer keep up with.)