Re: Single point of failure
> A 4-year uni has to deal with a 25% user turnover rate every single year.
Another poster already pointed out that the existence of staff means that it isn't 25% - but regardless, the problem with this argument is that if you have that turnover, you already have to have tooling suitable for handling it (and you have auth for other systems too, which would still exist). The benefit comes when you have a much lower turnover and thus cannot justify the effort of making the tools for yourself, but can benefit from sharing the cloud-y ones.
> Planning out an in-house server farm that accounts for all that, plus paying the, say minimum 2 technicians, paid at say £45,000+ each? Now you're talking real money over the life span of the server farm.
But PPSW at least isn't going anywhere - so you aren't saving the staff costs, the scope of the job is just somewhat smaller.
>So unlimited bandwidth
Hermes is on the CUDN - so the local users have no WAN bandwidth impact anyway. Moving it away *creates* a bandwidth burden that did not exist, it certainly doesn't solve it.
> low to no initial investment
Given it already exists, there is no initial investment either way
> no continuing upgrade fees...
Maybe I misunderstand what upgrades you are referring to, but since it is an OSS stack, there aren't any software licence upgrade fees.
> For static requirements, static loads or at least foreseeable, in-house has benefits. But for a public system where things can change, and change into the unknown, is them choosing cloud really such a massively bad idea?
Actually I mostly agree with you, except that this seems like a pretty stable, predictable load, so it fits the former category rather than the latter.