Before
The product did not have one place it ran. Part of it was on Google Cloud and part of it was on AWS. A change had to cross that gap. The path across was not a pipeline the team owned. It was a set of generated steps that had been asked to glue two clouds together, and those steps failed when either side moved. Shipping then looked the same from week to week. Start the pipeline. Watch it fail partway. Patch the step that broke. Run it again. Then check Google Cloud and AWS separately to see whether the thing that claimed to have deployed was actually the thing that was running. Monitoring was not a view of the service. It was the second half of the same weekly chore. That work added up to more than 10 hours a week, spent on deployments and on watching them.Two clouds
The same product was split between Google Cloud and AWS.
A makeshift pipeline
Deploys depended on a pipeline assembled with AI, and it did not stay working.
More than 10 hours a week
That time went to deployments and to watching whether they had worked.
No single view
After every attempt, someone still had to check both clouds.
What was breaking
A pipeline stretched across two providers has two consoles, two sets of credentials, and two places a deploy can look finished while the other side is not. When the glue is generated rather than kept as a real build, the next change in either cloud is another afternoon of repair. Virify was paying that cost every week. The hours were not a one-time migration. They were the ongoing price of getting code out and then confirming it was up.What changed
Virify connected an AWS account and deploys from GitHub through Springwinter. Connect AWS gives a CloudFormation link. They launch that stack in the account. Springwinter does not create the stack. The web server, workers, and the rest of the project are created in that account, on one network, under the role they chose. A deploy is a build in the account, started from the repository. It is not a script that has to succeed on Google Cloud and then succeed again on AWS. The GitHub token used for the clone is minted when the build starts and is not stored. A branch can run as a preview with its own URL before it replaces the live service. That is a second copy of the resource, not a second handmade pipeline.Monitoring without a second system
Logs are the build output and what the process printed, read from CloudWatch in the account. Metrics are CPU, memory, requests, and errors once the service is running. Cost is an estimate from the account, not a spreadsheet kept beside two consoles. The weekly question used to be whether the makeshift pipeline had survived. The question now is whether this deploy in this account succeeded, and the logs are on that deploy.1
Leave the two-cloud glue
Stop treating a generated script between Google Cloud and AWS as the release process.
2
Connect one account
Launch the CloudFormation stack in the AWS account. The role is theirs. Springwinter assumes it for a call and does not keep the temporary keys.
3
Deploy from GitHub
The build runs in the account when the repository changes. Production stays on the live resource. A branch can have a preview URL first.
4
Read the service where it runs
Logs, metrics, and cost come from the resources in the account, so monitoring is not a second project.
Connect AWS
The account owner launches the role. Springwinter does not create the stack.
Deploy from GitHub
The build runs in the account when the repository changes.
Logs
Build output and process output, read from the account.
Metrics
CPU, memory, requests, and errors once the service is running.