Last year, the SCEC.org website underwent a major overhaul in terms of technology and appearance. We went from a custom PHP solution to an open-source solution based on Drupal 7. Basing the site on Drupal meant that we could use an actively maintained open-source framework for the site. In addition, we could use all the community-developed open-source modules to handle everything from LDAP connections to file hosting on Amazon Web Services. When the new Drupal 7-based SCEC site was made live in September of 2015, we hosted the site on local servers at USC. However, we recognized a variety of challenges associated with hosting such a critical component of our business infrastructure locally, including earthquake resilience, backup infrastructure, power outages, and others scenarios, that could result in the SCEC web site being down.

To help us address these problems, we have begun migrating SCEC web infrastructure to the cloud. Unlike our previous self-hosted solution at USC, cloud hosting has cost and scalability considerations. We selected Amazon for our host as it is cost-effective, has a tremendous infrastructure for scalability, and has a robust suite of tools that enable us to create quality solutions for the SCEC web infrastructure.

To support SCEC broad and growing web development needs, we have created a web development environment that enables us to deploy the current scec.org web site (with or without content) to a local development machine, to a staging server, and to the live site. Cloud hosting enables us to trivially ensure that our staging server and live site have the exact same software stack. Because they are using the exact same version of Linux and the same backend infrastructure (S3 and RDS), we can ensure that there are no errors that arise from different PHP versions, different kernel versions, etc. when we transition new features from the staging server to the live server.

Cloud hosting also allows for better compartmentalization. For example, the database server need not be on the same server as the Apache host. This provides for incredible scalability. We used EC2 for the computing platform, RDS for the database, and S3 for the file hosting. This allows for backups to be made with regularity. Both our EC2 instance (which hosts all the code) and RDS instance are backed up nightly. S3 has a feature that tracks all changes made to a file. So if we accidentally overwrite a document or an image, we can revert back to an earlier version. This ensures that, for the most part, no matter what happens we can always trivially revert the site back to a last known good state.