This is the BBC, not some startup in a garage with a couple of EC2 instances. It's the busiest website in europe, and it's publicly funded. If they just threw up external node services whenever they felt like it there would be chaos.
For example, whenever there's a major news story they see traffic spikes that would make you weep.
Internally on the other hand, where the stakes aren't so high, they make heavy use of rails, node, go and all that cool stuff. They know what they're doing.
Check out this list of some of their machines, from part of their monitoring system which is for some reason left open: http://support.bbc.co.uk/support/rrd
EDIT: you're right that they could probably implement this quite easily, but the point is they can't just throw up an agile solution at the scale of the BBC, even if it seems safe.
The point is that this could be solved by a solution that is completely external to their current infrastructure, meaning they don't even have to mess with any integration or legacy code. Agile in this case seems perfectly suitable because they can easily have a fallback when the server doesn't respond to a "time"-request, that falls back to the current state (i.e. use client-side time). So we've got the perfect storm of no integration with current systems, tiny overhead on requests (it's basically an ECHO server), unimportant feature and easy fallback.
In fact I have an enterprise plan to sell them that does exactly this if they would like to externalise this problem.
Comments
This is the BBC, not some startup in a garage with a couple of EC2 instances. It's the busiest website in europe, and it's publicly funded. If they just threw up external node services whenever they felt like it there would be chaos.
For example, whenever there's a major news story they see traffic spikes that would make you weep.
Internally on the other hand, where the stakes aren't so high, they make heavy use of rails, node, go and all that cool stuff. They know what they're doing.
Check out this list of some of their machines, from part of their monitoring system which is for some reason left open: http://support.bbc.co.uk/support/rrd
Here's is some data about their peering: http://support.bbc.co.uk/support/peering/
Yeah that's right. Peering.
EDIT: you're right that they could probably implement this quite easily, but the point is they can't just throw up an agile solution at the scale of the BBC, even if it seems safe.
The point is that this could be solved by a solution that is completely external to their current infrastructure, meaning they don't even have to mess with any integration or legacy code. Agile in this case seems perfectly suitable because they can easily have a fallback when the server doesn't respond to a "time"-request, that falls back to the current state (i.e. use client-side time). So we've got the perfect storm of no integration with current systems, tiny overhead on requests (it's basically an ECHO server), unimportant feature and easy fallback.
In fact I have an enterprise plan to sell them that does exactly this if they would like to externalise this problem.