The Meeting of the Waters where the Amazon river starts. The darker Rio Negro waters and the sandy Solimões take 6km to fully merge due to different temperatures & pH levels.
Over the past few months we’ve been reconsidering DMPonline hosting – should we move to Amazon Web Services or remain with the University of Edinburgh. Brexit and ensuring we can meet our Service Level Agreements were two major concerns in this decision-making process. After investigating options, we have decided to remain with University of Edinburgh hosting. This blog post outlines our thoughts.
Keeping data within Europe
With all the uncertainties surrounding Brexit and a likely no-deal crash out, Amazon hosting was part of our contingency planning. Ironically it was after a week-long conference on the Amazon river that I sat in Sao Paolo airport and debated the issues with Edinburgh Legal. It transpired that hosting on Amazon Web Services wouldn’t solve any concerns. In contrast, the DCC would be considered as an external processor and any work we do via remote access would be deemed a data transfer. In the case of a no-deal-Brexit, the University has some model clauses which we will sign with overseas clients. These uphold us to European regulations such as GDPR to ensure the same protections are granted.
Another concern we had was ensuring the DCC team has full control over deployments. Over the past few years we have been contracting out technical support to EDINA, but with the growth of the developer team, we’re moving everything in-house. If the servers go down or any technical issues occur, we want to be able to liaise on fixes directly. Since we are containerising the application, it gives us more flexibility on deployment strategy. We’ve been investigating two main hosting routes – using Edinburgh University Information Services infrastructure and
Amazon Web Services
Investigating Edinburgh infrastructure and AWS
Ray and Sam met with the Edinburgh infrastructure team to understand what options are available for local hosting. There are several routes, varying the level of central and local control. We have opted for a centrally managed virtual machine to ensure all security updates are managed by the University and we can focus on maintaining the application. The University also has a forthcoming Docker Container service which may prove useful once out of test, as we use a dockerised setup.
As part of our planning process, we also took time to deploy a basic instance of the application to AWS. This helped us understand the technical options and anticipate workloads. AWS provides a large number of services which can be put together in a variety of ways. The options are changing rapidly, which adds to the complexity. We may end up needing to commit significant developer resource to continually monitor and maintain the deployment. Customers also raised several concerns about the implications of a move to AWS in terms of data access and permissions. Both the technical deployment and the legalities seem a bit of a rabbit warren which we’d rather avoid.
Permissions for AWS
Thanks to all the subscribers who gave permission for us to host on Amazon Web Services. The contract conditions required that we obtain explicit consent, hence initiating that process so we could keep all options open. While we are not going with AWS at the moment we will keep that in reserve as part of our disaster recovery planning.
As noted earlier, our final decision is to retain hosting at the University of Edinburgh but to redeploy on to IS infrastructure rather than work through EDINA. In the event of a no-deal-Brexit, the University has some model clauses which we will sign with overseas clients to uphold us to European regulations. We intend to change our local hosting arrangement in late 2019 / early 2020. There will be a small amount of downtime which we will announce in advance. Users will not notice any differences to the service.