# Monolith migration ## Context We have decided to migrate the existing `submit`, `data-frontend` and `data-store` into a single service in order to simplify our architecture and speed up development ## Challenges The existing data-store is modelled as a 'backend' service and therefore not exposed on the public internet. Copilot does not let you change an existing 'backend' service to a 'Load-balanced web service' therefore we need to create a new service as part of the migration (ref: https://github.com/aws/copilot-cli/issues/5833) Furthermore, as the backing-services (S3 and Postgres) are tightly coupled to the existing service, they will be destroyed when the existing data-store service is deleted Therefore in effect we need to do a full migration to a new service. In addition as the DNS is controlled by IT we don't have a way currently to simultaneously expose the existing and new service (on the public internet) ## Production migration Migrating to production has additional challenges: * Post-Award on Production currently sits in a different VPC than Pre-Award, we want to take the opportunity to re-create it in a shared VPC with pre-award to enable networking between them in future * If we tear down the existing Copilot environment we will lose the existing Cloudfront distribution which is referenced in DNS, so we would need to co-ordinate with IT to update this * If we have downtime on production, we will need to co-ordinate this with stakeholders ### Prod migration options #### Deploy post-award service in existing pre-award app ##### Pros * Straightforward to deploy * Resolves inter-app networking issues without further configuration ###### Cons * Moving to pre-award app will switch to its Cloudfront distribution which will require a DNS change (Unless we can figure out a way to retain the existing cloudfront distribution and re-point it to the pre-award load balancer?) * Potentially two tightly coupled, e.g. a break in the pre-award environment would affect post-award services * Different than current setup in pre-prod envs #### Deploy post-award app in new app in existing VPC ##### Pros * Replicates existing setup on dev and test * Possible to connect to pre-award services by adjusting security groups (using Service Discovery endpoint) ##### Cons * Additional config needed for networking * Service Discovery is less robust than Service Connect for networking #### Deploy post-award app in separate VPC ##### Pros * Clean separation between environments * Possible to connect to pre-award services using VPC Peering (in theory) ##### Cons * Additional config needed for networking * Different than current setup on dev and test