Server Architecture

to be added -- things that will need to be documented include:

• Virtual machines: separation of subsystems for database, front-end, web proxy, maybe even analysis?
• Development vs. Production: ensuring we can experiment with changes without breaking the live system
  • Travis CI for testing?
  • DevOps approach for pushing changes live?
• Cloud vs. internal: something tells me we should keep things internal, while also being "cloud ready"
  • Which probably means supporting Docker
• Backup & Recovery - probably bump this to be its own separate page
  • Recovering entire servers after break-ins
  • Nightly backup of datasets
  • Restore procedures after oopses and break-ins

I'm really concerned about over-engineering a system that is too complex to be managed and maintained after my departure. So, while best practices say to separate things into a bunch of individual pieces, is that best for SFCTA?