Wandering Thoughts archives

What applications are actually crucial at a university

Like most organizations, the university has what I call administrative management systems, the computers that handle core business record keeping like payroll, accounts payable and receivable, HR, and (this being a university) crucial student information like enrollment and marks. This is serious stuff, run using expensive software on expensive databases on expensive hardware (and behind paranoid firewalls), and, like most places, is considered a pretty crucial thing.

But it turns out that it has quietly become not the most crucial system the university runs. As people have been realizing recently, that honor now goes to our campus wide learning management system, which has slowly been gaining in popularity and usage over the past few years.

If the administrative systems are down, the university administration might have a rocky time but other things would go on, and most people might not even notice. But as the LMS became a success it has become pervasive in teaching, which means that if the LMS is down a lot of courses grind to more or less a dead halt. Assignments can't be turned in, course materials aren't readable, the secure messaging that students and professors have been encouraged to use is unavailable and so on. Everyone would notice, and fast.

This is probably not much different from a company with a crucial website or other system that's central to their business. It's just that it's a new and novel thing for a university, and feels a little peculiar.

A thought about Amazon's S3 and EC2

It amuses me how Amazon's EC2 and S3 services are a clever return to the era of timeshared mainframe computing. Not in what is being directly supplied, but in its economics. Rather than the fixed monthly price common these days, EC2 and S3 charge you a usage based fee for both storage and CPU, just as timesharing computing used to.

(Of course, some segments of timesharing computing used to charge you for anything that moved and they could measure. And did so with rates much higher than Amazon's.)

Amazon's EC2 rates have the advantage that they are still 'flat price' in one sense: you pay a flat fee per time period that your virtual machine is on, regardless of its actual usage level. This is much more predictable and controllable than the timesharing era (unless you were actually saturating the CPU), and also simplifies Amazon's accounting systems.

(I suspect that Amazon does track real CPU and memory usage internally, if only for capacity planning purposes.)

One of the interesting things about the S3 and EC2 rate schemes is what they say about Amazon's costs to provide these services. For example, network bandwidth is clearly expensive enough that Amazon feels the need to charge for it in detail, unlike detailed CPU usage.

(The other way to look at this is reusable versus non-reusable expenses for Amazon. EC2's capacity is reusable for Amazon's internal needs, but they have less use for bigger Internet pipes, so users have to pay for that directly.)

What you don't know about other peers in BitTorrent

While BitTorrent doesn't hide, it also doesn't go out of its way to give you information. One of the interesting questions, at least from the perspective of some organizations and the people who dislike them, is how much you know about the peers in a given BitTorrent swarm beyond their IP address. It turns out that the general answer is 'not much'.

Without talking to a peer, all you know is that the peer has registered with the tracker. You don't know if they're actually participating in the torrent swarm or if they're just a passive observer, how much of the torrent data they have, or how much data they claim to have transfered in and out.

(If you control the tracker you know more; the peers tell you how much of the data they have and how much they've downloaded and uploaded. However, it's hard to catch peers that lie, especially a group of collaborating peers.)

If you talk to an honest peer you can find out how much of the data it has and observe it downloading data, but you can't tell whether or not it's uploading anything, nor can you find out what other peers it is downloading from.

If you suspect that you're talking to a dishonest peer, about all you can do is request portions of the torrent data and see if you actually get valid chunks. (Specialized bandwidth efficient seeding clients are often partially dishonest.)

Both sides are probably most interested in proving that another peer is a full participant in the swarm, and in both cases the only really good way to do this is try to download from it. This demonstrates that it has the data and is willing to share it, which is about all you can ask.