{"id":318,"date":"2016-08-01T17:27:48","date_gmt":"2016-08-01T17:27:48","guid":{"rendered":"https:\/\/www.education.uw.edu\/coeir\/?p=318"},"modified":"2018-04-30T23:32:02","modified_gmt":"2018-04-30T23:32:02","slug":"cycle-40","status":"publish","type":"post","link":"https:\/\/coedev.education.uw.edu\/technologycenter\/workplans\/cycle-40\/","title":{"rendered":"Cycle 40"},"content":{"rendered":"

\n\t7\/18\/2016 – 7\/29\/2016\n<\/p>\n

\n\tWork Complete
\n<\/h2>\n

\n\tWe were able to dig into our UW institutional Amazon Web Services (AWS) account this cycle. AWS offers basic machine virtualization (EC2), but its more exciting features are the specialized services: object storage (S3), container hosting, specialized database services, etc. To make good use of AWS application should be architected to use services that support its components.\n<\/p>\n

\n\tOur immediate need is development and staging environments for our production web server. Staging especially needs to be a close functional replacement for production. Getting AWS to closely emulate our UW production server means additional time and expense.\n<\/p>\n

\n\tAWS is competitively priced, but it is not cheap. Our largely idle EC2 instance used for early testing was ringing up about $1.25 a day. Comparing that to UW-IT lowered rate on Hosted Virtual Machines and we are not saving much with AWS.\n<\/p>\n

\n\tSo seeing extra administrative effort, poor replication of production environment, and comparable costs we have decided to put our staging environment on a UW-IT Hosted VM. This process will also move internal facing Institutional Research information systems to a separate server from the public facing college websites.\n<\/p>\n

\n\tAppreview
\n<\/h3>\n