Wandering Thoughts archives


Why we'll continue to have local compute servers in the future

On the surface and ignoring some issues, one of the easiest things to offload into cloud computing should be our compute servers. But in practice in our environment it isn't so; as a result I expect that we'll be running some degree of compute servers for years to come.

The great advantage that local compute servers have is that the incremental cost for a grad student to use them is zero. The grad student and/or their professor does not have to find some money (even spare change money) in the budget to buy N hours of compute time on the cloud of your choice; they just log in and start running things. This may not run anywhere near as fast as it could in a cloud but in a university environment this doesn't matter. What matters is that no one has to find any money, anywhere, to have their grad student do some computing.

(This has additional effects. For instance, you don't have to worry that one grad student in your group is going to accidentally run something unusually compute intensive and drain the group's computing budget. Of course a professor could get around that by setting individual computing budgets for their grad students, but then they have to spend time coming up with these budgets and then listening to grad students beg for more compute time. This is an instance of the general thing that money in universities always involves bureaucracy.)

In a university, it doesn't matter that the total cost of ownership for some compute servers might be higher than just getting the same computing in the cloud. What matters is that you can buy the compute servers with one-time money and then just run them for free (generally we can ignore the other ongoing costs for various reasons), whereas using cloud computing requires ongoing injections of money over time. One time money is much easier to get and once the department has spent it on a compute server, everyone in the department can use it regardless of their current funding levels.

(Varying funding levels is the other elephant in the woodpile. My sense is that it is politically much easier to buy a compute server for the department, even if it is funded out of someone's grant, than it would be to transfer money from flush people to lean people in order to fund the latter's cloud computing. The net monetary effect could be the same but the perception would likely be very different.)

sysadmin/WhyLocalComputeServers written at 21:49:34; Add Comment

Can we really use the cloud?

One of the things I think about every so often is whether we can make much use of cloud computing (by which I mean external cloud providers, not trying to set up some sort of large-scale university cloud or virtualization environment). Although I may be suffering from a lack of imagination, so far I keep coming up mostly empty.

The problem is that most of our services are internally facing; they're things we provide to our local users. I see the cloud as great for externally facing services (things like websites that the outside world uses) and things that sit behind them to support them, but this is mostly not what we have. Shipping local file storage and so on off to the cloud seems a little counter-productive and also bandwidth (and latency) limited. Something like IMAP email could in theory be hosted in the cloud instead of locally but currently it's entangled with our local file storage; detaching it would have various awkward consequences that would be annoying to the users.

(One argument is that people are already implicitly moving to the cloud as it is, by shifting email to GMail and storing stuff in Dropbox and so on. But even if they are, I don't think we can displace high quality services like GMail and Dropbox with our own efforts.)

One issue for remoting some services off into the cloud is how we deal with interactions with local fileservers and login services. Local fileservers are important for local heavy-duty computing, so how do we bridge them and either remote servers in the cloud using the local fileservice or even remote fileservice (for example if we pushed our web server into the cloud)? I suppose we could nail up IPSec tunnels and the like, but that feels both fragile and worrisome from a security perspective (assuming that NFS even works very well over WAN latencies).

(I'm assuming that issues of cost, network reliability, and any legal problems can all be magically dealt with. This is not necessarily realistic (and some of them definitely are concerns), but the general enthusiasm for clouds basically handwaves them all anyways.)

sysadmin/CanWeUseCloud written at 00:59:41; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.