Skip to end of metadata
Go to start of metadata


Reduce the number of supported machines, software, Sysadmin, and DBA time.  Move some services to managed services.

Principles and Opportunities

  • Standardizing our approaches to software development and projects will also help here (e.g., Subversion for version control, separate environments for Dev-QA-Prod).
  • Yes, this kind of consolidation takes time, so it might make sense to backfill some support duties with temporary staff.
  • We should consider segregating applications appropriately.  For example, apps developed by others might be deployed to different environments (other hosted IST offerings, dreamhost, or slicehost).  Informatics Services can provide the role of brokering these and even environment setup.
  • Moving to managed services, whether in IST or elsewhere, is a good thing but has its own set of challenges.


  • Accounts set up for developers outside Informatics Services (whether consultants, other museum staff, or students) are an ongoing issue.
  • Software installed across our portfolio might look the same but have different version or library dependencies, making consolidation impossible or difficult without further work.
  • Some of the components in our inventory are not under our control and provide a fixed point of reference, e.g., the web farm. We do not have control over versions and libraries installed there.

Scenarios and musings

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 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. 

  • No labels