Reduce the number of supported machines, software, Sysadmin, and DBA time. Move some services to managed services.
John: Here are some situations
1) replicate the darwin environment exactly so we can test software without breaking things. Using a 2nd port number works OK such as we have on darwin but often the 2nd port still points to the live installation of the database and software installations. Its very difficult, for example, to test the functioning of a new Apache without just going ahead and installing it.
2) With an eye towards the future, i would imagine we have a protocol for setting up a server environment that we can perform automatically.. say, there is a template that we maintain in the cloud. I'm thinking (and maybe i'm wrong about the process here) that we have the template and we can create x instances of a particular server which would allow us to deploy and test much more easily. I would think that we move our production server to the cloud as well when darwin comes to the end of its life.
3) It would be much easier to support projects such as hosting the old DiGIR, or hosting a service from an outside provider that we want to work with. For example, Biomatters wanted to host a Tomcat service on darwin to run some of their scripts to help import data into the Biocode LIMS system. In this case, it would be problematic hosting on darwin for several reasons: 1) darwin does not currently run Tomcat, 2) how do we know how much use this service is consuming and charge accordingly, and 3) how do we know such a service is secure. Hosting on a replicated cloud server would isolate the cost, CPU cycles, and security implications.
4) With global field projects going on and alot of server-based software we may find it easier to deploy on a local cloud instance, such as hosting a Moorea Biocode instance in French Polynesia. This is mostly a hypothetical situation given that i'm not sure if hosting companies can locate cloud based computers in different regions or even if it would make much of a difference in performance, but certainly the challenges of hosting hardware in a fieldstation, plus crappy bandwidth to the outside world, makes this something to look at for the future.
Chris: The CollectionSpace project is using several instances on slicehost http://www.slicehost.com/ and are quite happy with it. You can resize the slice, automate payments, choose whether to backup and so on, select your linux flavor... The only thing is that it's a blank slate beyond the OS. You have to install and manage all software, user accounts, and so on. But it's pretty clean otherwise. I wouldn't say it's a bulletproof environment that you'd want to use for your most precious social security numbers, but especially for a dev environment it might be OK. Still thinking here though... If the goal is to build a proper Dev-QA-Prod chain, then something like the webfarm/appfarm is attractive due to the environment support across the chain.