...
This data strategy will allow us to have all services running in parallel (both aws and azure), destroy the services in Azure and have AWS serve all traffic and keep data for trainee ui fresh
...
Warning: with this strategy, it's very important that users that have access to the AWS version of TIS while it's still running in Azure should NOT be allowed to modify data. This would cause a disjunct of what the correct data is. So only only Azure has been decommissioned, should users be able to change data in AWS
Developers and Services
During the migration, we’re not going to stop developers from doing their jobs. It won’t be feasible to tell the business that all features/bug fixes will need to stop until we’ve completed the migration. With this in mind, we are having to come up with ways to allow the building/deployments of services to continue with zero impact.
With this in mind, we’ve come up with initial plans to have builds run concurrently in both Azure and AWS. This will allow us to have both systems in sync in terms of maven artefacts and services.
This will involve creating additional webhooks for all of the github repositories that makes calls to the AWS jenkins instance at the time of merges, branches and PR’s. Additional changes to all of the pipelines will need to happen to push docker images straight to AWS’s ECR (docker container registry) - this will then save us from paying for 2 lots of storage for docker images.
An additional change to remove the DEV environment from the pipelines will also be required as it’s been decided that we will only have a PROD and PREPROD environments in AWS once this is done, we can destroy the DEV systems in Azure saving money early on.
...
Flexibility and Managed services
...