-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #193 from nationalarchives/sharepoint-host-integra…
…tion-endpoints-adr ADR for hosting service integration endpoints
- Loading branch information
Showing
1 changed file
with
57 additions
and
0 deletions.
There are no files selected for viewing
57 changes: 57 additions & 0 deletions
57
architecture-decision-records/0032-hosting-service-integrations.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,57 @@ | ||
# 32. Hosting Service Integrations | ||
|
||
**Date:** 2024-06-07 | ||
|
||
## Context | ||
|
||
TDR needs to support transfers from additional sources other than network drives, for example SharePoint, Google Drive, hard drives etc. | ||
|
||
This will require the exposure of endpoints so other services can integrate with TDR to allow the transfers from such sources, along with additional processing of metadata and records. | ||
|
||
The additional processing and endpoints will need to be hosted by the TDR infrastructure. | ||
|
||
Such transfers are likely to involve much larger volume transfers in terms of number of records and overall size. In addition bespoke processing of the data is likely to be needed. | ||
|
||
## Decision | ||
|
||
Decision to host the necessary code for supporting transfer from additional sources on a new AWS ECS Task within existing TDR's VPC. | ||
|
||
This provides the following advantages: | ||
* Service integrations always available | ||
* Flexibility to extend with future requirements | ||
* Potential to handle higher volume transfers | ||
* Less burden on existing TDR infrastructure used to support network transfers | ||
* Take advantage of TDR's existing access controls to the VPC (for example WAF rules) | ||
|
||
### Disadvantages to hosting on new ECS Task | ||
|
||
* Higher maintenance burden as less code re-use - potential mitigation with abstracting existing TDR frontend code to re-use | ||
* Potential higher AWS cost running additional ECS task - potential mitigation with closing down service over weekends etc | ||
|
||
## Other Options Considered | ||
|
||
### Hosting on existing TDR Frontend ECS Task | ||
|
||
#### Advantages | ||
|
||
* Re-use existing code, such as authorisation and authentication, connections with other TDR services | ||
* Lower maintenance burden | ||
* Lower potential AWS cost burden | ||
|
||
#### Disadvantages | ||
|
||
* Code was not designed for supporting endpoints externally exposed | ||
* Capacity issues with larger transfers, ECS task already at capacity at peak usage supporting the TDR frontend | ||
|
||
### Hosting on AWS API Gateway and Lambda | ||
|
||
#### Advantages | ||
|
||
* Serverless architecture with potential cost savings | ||
* Use AWS API Gateway features | ||
|
||
#### Disadvantages | ||
|
||
* Large amount of additional AWS infrastructure to create and maintain | ||
* Lambda "cold start" causing lag on transfers | ||
* Securing endpoints whilst allowing external access will be difficult |